Apktool源码-重新打包
Apktool源码-重新打包
熊猫不是猫接着上一篇 Apktool 源码-反编译 来说，这次接着说重新打包apk的流程。
1、重新打包
private static void cmdBuild(CommandLine cli)
1. new了一个Androlib类，将apkOptions传入，调用build方法时将反编译的目录appDir传进去。
2. 常见的日志输出
3. 解析apktool.yml文件
yml文件里，是apktool进行反编译时存储的相关信息。重新打包要完全还原apk，必须要使用到这个文件。特别是里面的 doNotCompress 内容，对于游戏包体来说，十分重要。
MetaInfo类的字段内容
4. 准备相关目录，开始进行打包
5. buildSources(appDir)
打包代码，分为两种情况，一种是反编译的时候就没有反编译源代码的。那么就是处理classes.dex文件，直接拷贝即可。
另一种是反编译了代码的，处理的是smali目录下的smali文件。
6. buildNonDefaultSources
处理多个dex的情况下的smali文件，以smali_开头的文件夹，以及.dex结尾的dex文件，处理方式同第5步.
7. buildManifestFile
处理AndroidManifest.xml，包括原始AndroidManifest.xml文件。若存在resources.arsc说明没有反编译资源，则无需处理AndroidManifest.xml文件，直接返回。否则，删除原始AndroidManifest.xml，并开始处理AndroidManifest.xml文件。
其中fixingPublicAttrsInProviderAttributes方法，是修复provider节点中的@string字符串引用bug，这是AOSP中的一个bug。会导致应用安装失败，apktool使用具体的字符串值替换引用来避免此bug。
8. buildResources(appDir, meta.usesFramework)
方法中包含对资源和manifest的处理，其中都判断了资源是否进行过修改，如果进行过修改，就会重新打包资源。其中manifest中的debug标记也是在这里设置的。当然，如果设置了进行强制全编译，无论资源是否进行过修改，都会重新打包。
在buildManifest方法中可以看到，apktool使用aapt打包资源，而其中又分为appt1和aapt2打包两种方式。此处其实有蛮多坑的，个人对于appt1和aapt2打包方式也有许多不甚解的地方，后续还要再研究，开帖详述。
9. buildLibs
处理libs，此处的libs中只有so库等资源了，jar这些早已在smali文件夹中了。简单的拷贝即可，当然也包括了一些kotlin的东西。
10. buildCopyOriginalFiles
拷贝原始文件，如果original目录存在，就拷贝其中的META-INF文件夹以及AndroidManifest.xml到apk中去。这个主要是看反编译的时候的配置，是否存在original目录来决定。
11. buildApk
最后打包apk，做Android的应该都知道，apk文件其实就是一个压缩包，改个后缀为zip或者直接压缩工具就能打开apk文件，这个操作就不多说了。
12. buildUnknownFiles
处理未知文件，即不属于Android定义的部分文件。之所以用这种方式来处理，是因为aapt不能处理非Android定义的文件，因为aapt它不认这些文件。
13. 再次处理AndroidManifest
前面的步骤把AndroidManifest.xml拷贝到了AndroidManifest.xml.orig，然后AndroidManifest.xml用来appt处理资源，现在再把AndroidManifest.xml.orig拷贝回来。
至此，打包结束。
最近在忙着处理一些自己的私活，时间变得不再充裕，写文章的速度慢了好多。本篇文章的深度也是不够的，个人完全能感觉出来，只能说后续看有没有时间再深入分析吧。不过也理了个大概的流程，如果在使用apktool的过程中，遇到一些问题，倒也能进行一些修改，重新编译，订制自己的一个apktool了。勉强够用吧。
