Android反編譯odex然后重新打包
最近不知道怎么回事，突然把我那刷了氧OS的root了，然后就開始好奇起來氫OS所帶有的那些本地化的東西，比如通話錄音就是典型的一個之一。其中也做了很多的嘗試，XDA上有人說把/system/build.prop里面的"persist.sys.oem.region"的值改成“CN”，我嘗試了一下確實可以，但是有的APP出現了崩潰卡死的問題，我發現改了后設置里面系統版本變成了氫OS，然后三大金剛鍵都變成了又返回在右邊了，短信默認的都出現了氫的卡片效果，電話設置里面也有了通話錄音，一切都成了氫OS的樣子，但是副作用是好多的第三方APP出新了不能運行崩潰等各種問題。
於是又把build.prop改成了原本的樣子，然后開始了反編譯的探索之旅，於是就有了這篇博客，好多中文的博客寫的都過時了，真的是好幾天各種挖坑填坑爬坑的結果。本文的反編譯是在Android7.1.1環境下在mac操作系統下操作的
好了廢話說完了，一些概念諸如為什么有odex，odex之於apk里面的dex，下面開始正文
修改這種系統預裝的app然后再打包理論上需要經過以下步驟
odex -> smali files -> dex -> jar -> modify smali files -> dex -> apk(包括class.dex的apk)
一開始我就是按照這個步驟來的，因為odex依賴的系統版本比較高，好多中文博客介紹的都是過時的工具，導致中間遇到了太多太多的坑。因為我弄的這個apk是控制電話接通后的童話的那個邏輯的，所以每次弄好了還要把apk復制到手機里面，然后再復制到/system/priv-app里面，然后改權限，還要保存之前的備份等的東西然后再重啟手機，再撥打電話嘗試，所以操作步驟極其繁瑣。應該有更好的方法，只不過目前還懶的去發現。
- odex -> smali files: 這一步是使用的smali工具，我用的是baksmali-2.2.1.jar，其基本的命令為
java -jar baksmali-2.2.1.jar deodex OPInCallUI.odex -b ./framework/arm64/boot.oat -o OPInCallUI deodex參數，指定要操作的文件名為“OPInCallUI.odex” -b參數，指定bootclasspath，也就是要把手機rom的/system/framework里面的文件直接拷貝到電腦上的當前工作目錄 -o參數，指定輸出的smali文件的目錄
- smali files -> dex: 這一步用的還是smali工具，不過jar文件變了，為smali-2.2.1.jar，使用的基本命令為
java -jar smali-2.2.1.jar assemble OPInCallUI -o classes_o.dex assemble參數，指定smali files的文件夾所在 -o參數，指定輸出的文件名為“classes_o.dex”
- dex -> jar: 這一步用的是dex2jar工具，使用的基本命令為
./dex2jar-2.0/d2j-dex2jar.sh classes_o.dex -o classes_o.jar 意思是把“classes_o.dex”轉成“classes_o.jar”
- modify smali files: 這一步使用的工具主要會有不同，但是JD-GUI是少不了的，它能直接查看jar里面的class文件所對應的源代碼，有了源碼，看一些邏輯就方便了太多了啊。
jclasslib是查看java字節碼的一個工具。其實這個地方基本用不到看java的字節碼，而主要看smali（即Dalvik opcodes）文件 。
smali文件用普通的文本編輯器查看修改就可以了，但是需要先了解一下基本的語句，這是對照表。其實第2和第3步的主要目的就是看java的源碼，幫助更好的理解，如果你感覺看smali跟看java是一樣的，那就可以省略2和3步了 - modify smali files -> dex: 這一步是使用的還是smali工具，不過要用smali-2.2.1.jar，其基本的命令為
java -jar smali-2.2.1.jar assemble OPInCallUI -o classes.dex
- dex -> apk(包括class.dex的apk): 把第五步生成的classes.dex用壓縮工具放在在手機"/system/priv-app/OPIncallUI"提取的OPInCallUI.apk里。這里我比較推薦BetterZip，可以去編輯壓縮文件，制作壓縮文件的時候還可以排除.DS_Store的影響。
- 把修改后的apk放回到"/system/priv-app/"里面，重啟手機測試一下吧
注意:
- boot.oat依賴的時候要拷貝全面，要不然就會報錯
Error occurred while loading class path files. Aborting.
org.jf.dexlib2.analysis.ClassPathResolver$ResolveException: Error while loading oat file ./boot.oat
具體的有篇文章，介紹了boot.oat和boot.art等的關系。初探boot.art與boot.oat
- 減少中間環節，我查過各種資料后總結出來流程應該是這個樣子的
odex -> smali files -> dex -> jar -> modify jar -> dex -> apk(包括class.dex的apk)
后來發現這個坑實在是太深了，有的時候用低版本的baksmali的時候就會報大量的錯誤
org.jf.dexlib2.analysis.AnalysisException: Could not resolve the method in class Ljava/lang/reflect/Method;
以此順延下去，肯定打包的程序不能運行了。
然后步驟多了出錯的地方就更多了，定位起問題來就更麻煩了。
- 安利一個Google的工具吧android-classyshark，用來查看apk的包資源，類方法名等的工具，簡直利器。再加一個插件intellij-java2smali，很方便的把java轉成smali查看
其實這次反編譯的初衷來源於想讓我的一加3T手機的氧OS能夠像氫一樣擁有通話錄音的功能。然后經歷的種種，還受oos-call-recording項目的影響，還問了厚臉皮的問了作者原理。現在我也自建了一個項目，會上傳我微改的系統的APP，使氧OS的系統APP擁有氫OS的功能，而又不失去氧OS更新快的特點。項目的地址為https://github.com/ysk666666/OxygenOS-SystemAppModified