上一次我们反编译了手q，并遇到了apktool反编译直接crash的问题，虽然笔者很想在这次解决这个问题，但在解决途中，发现该保护依赖于很多知识，所以本次先插入一下，正所谓知其然知其所以然，授之鱼不如授之以渔，只有知道一些基本原理，才能让我们以后能自行解决更多问题。
那么，你知道么？从我们在android studio中，点击run，到app运行在手机上，之间究竟发生了什么，代码和资源是怎么变成apk的，而apk又是怎么安装上去，并能执行的呢。
build-simple-overview
希望看完下文，大家能对整个过程有一定了解。
源码：资源部分为android 4.4，后半段改为了6.0_r2
apk是android package的缩写，实际上apk就是一个zip压缩包，使用zip解压软件直接就能对其进行解压，解压后会发现就是由各种资源文件、一或多个dex文件（odex过的apk除外）、androidmanifest.xml、resources.arsc以及其他一些文件组成的。
apk-build
从该图来看，整个打包过程可以分为以下七个步骤：
打包资源文件，生成r.java和编译后的资源。aapt的可执行文件位于sdk的build-tools下，而源码则在frameworks\base\tools\aapt目录下。打包过程主要是调用了<code>resources.cpp</code>下的<code>buildresources()</code>。
路径为<code>main.cpp</code>下的<code>handlecommand(bundle* bundle)</code>到<code>command.cpp</code>下的<code>dopackage(bundle* bundle)</code>，经过一些初始化和检查后调用了我们要深入看的<code>buildresources(bundle* bundle, const sp<aaptassets>& assets)</code>。因为代码都比较长，这里不贴了，主要说一下大概的逻辑和流程。
主要做一些检查并使用<code>parsepackage</code>初始化并设置一些attribute，比如<code>package</code>, <code>minsdkversion</code>, <code>uses-sdk</code>。
使用<code>table.addincludedresources(bundle, assets)</code>添加被引用资源包，比如系统的那些android:命名空间下的资源。
收集资源文件:
处理overlay（重叠包，如果指定的重叠包有和当前编译包重名的资源，则使用重叠包的）:
对res目录下的各个资源子目录进行处理，函数为<code>makefileresources</code>:
<code>makefileresources</code>会对资源文件名做合法性检查，并将其添加到resourcetable内。
在上一步添加过程中，其实并没有对values资源进行处理，因为values比较特殊，需要经过编译之后，才能添加到资源表中。
编译会调用<code>resourcetable</code>的<code>compileresourcefile</code>进行:
在继续编译其他资源之前，我们需要先给bag资源（attrs，比如orientation这种属性的取值范围定义的子元素）分配id，因为其他资源可能对它们有引用。
最后我们终于可以编译xml文件了，因为我们已经为它准备好了一切可能引用到的东西（value, drawable等）。
程序会对layouts, anims, animators等逐一调用<code>resourcetable.cpp</code>的:
进行编译，内部流程又可以分为：解析xml文件，赋予属性名称资源id，解析属性值，扁平化为二进制文件（调用<code>flatten(bundle* bundle, const sp<aaptfile>& dest)</code>）。
该步骤其实也可以归为上一步，但由于manifest文件的特殊，所以姑且抽了出来。
生成我们解压后看到的那个<code>resources.arsc</code>:
而具体的resources.arsc生成则在<code>resourcetable.cpp</code>:
写入顺序为 索引资源表头部(resourcetypes:restable_header) -> 资源项的值字符串资源池 -> package数据块。
验证manifest各个属性对应值的合法性，即value中能出现的字符，完成后资源正式处理完毕，添加到<code>aaptassets</code>:
终于，我们已经读取并处理好了需要的一切，是时候开始写文件了，于是又回到了<code>command.cpp</code>的<code>dopackage</code>:
而<code>writeproguardfile(bundle, assets)</code>则会调用
writeproguardforandroidmanifest(&keep, assets);
writeproguardforlayouts(&keep, assets);
将规则更新到proguardkeepset中，然后打开proguard文件进行写入（proguard文件由-g命令指定）。
又是一个洋洋洒洒150多行的函数，浓缩一下看看删减版<code>package.cpp</code>:
处理aidl文件，调用build-tools下的aidl可执行文件生成对应的java文件。该工具的源码位于frameworks\base\tools\aidl。
我们有了r.java和aidl生成的java文件，再加上工程的源代码，现在可以使用javac进行正常的java编译生成class文件了。
调用dx.bat将所有的class文件（上一步生成的以及第三方库的）转化为classes.dex文件，实际调用的是build-tools\lib\dx.jar，其源码位于libcore\dex（描述dex文件的格式）及dalvik\dx（包含dx及multidex打包）下。
dx会将class转换为dalvik字节码，生成常量池，消除冗余数据等。
关于dex，我们下一篇会单独去细说。
打包生成apk文件。旧的apkbuilder脚本已经废弃，现在都已经通过<code>sdklib.jar</code>的<code>apkbuilder</code>类进行打包了。输入为我们之前生成的包含resources.arcs的.ap_文件，上一步生成的dex文件，以及其他资源如jni、jar包内的资源。
大致步骤为
以包含resources.arcs的.ap_文件为基础，new一个apkbuilder，设置debugmode
apkbuilder.addzipfile(f);
apkbuilder.addsourcefolder(f);
apkbuilder.addresourcesfromjar(f);
apkbuilder.addnativelibraries(nativefilelist);
apkbuilder.sealapk(); // 关闭apk文件
generatedependencyfile(depfile, inputpaths, outputfile.getabsolutepath());
对apk文件进行签名。apk需要签名才能在设备上进行安装，源码在build\tools\signapk下。
很多时候我们在逆向改完后，会因为没有签名文件导致最后的apk无法正常使用，又细分为本地验证和服务器验证。
调用buildtools\zipalign，对签名后的apk文件进行对齐处理，使apk中所有资源文件距离文件起始偏移为4字节的整数倍，从而在通过内存映射访问apk文件时会更快。
这样我们的最终apk就生成完毕了，对gradle是如何在输入gradle assembledebug之后打包的，可以参见aosp下builder/src/main/java/com/android/builder目录，这样你可以更了解整个流程和每个gradle子任务做了什么（像是buildconfig是怎么生成的）。
比如当我们在命令行输入
adb daemon start
实际上就会有2个进程被起起来（这就是下文提到的组件中的client和server了）
adb ps
adb扮演了2个角色
传输。host和设备间的通信路径。可能是usb，也可能是tcp，但host不需要关心。
服务。通过传输提供服务，在目标设备上执行指定命令。
adb中有3个组件
adb clients。其实就是那个子命令的可执行文件。比如起了3个adb shell，那就是3个clients。
adb server（就是那个动不动卡死要restart的东西）。在开发机器的后台运行，扮演着adb clients和adbd之间的中介，让彼此可以通信。
adb daemon(adbd)。在目标设备上运行的后台进程；由init启动，死掉后会由init重启。
当启动adb client的时候，client首先会检查是否有adb server进程在运行中，如果没有则启动进程。
server启动后会绑定到tcp端口5037，并监听来自adb clients的命令。接着server会通过扫描5555到5585之间的奇数端口（被模拟器和物理设备所使用），建立到所有运行中设备实例的连接。一旦server找到adb daemon，就会建立到那个端口的连接（而未开启usb调试的设备则没有adb daemon运行）。
每个设备实例都需要一对连续的端口（这就是为什么刚才只扫描奇数端口），一个偶数端口用于控制连接，一个奇数端口用于adb连接，例如：
模拟器1，控制: 5554
模拟器2，adb: 5555
nexus6，控制: 5556
nexus6, adb: 5557
...
如上，5554和5555其实都是被同一台设备所使用。
源码位于aosp的system/core/adb目录下，adb和adbd都是从这儿编译出来的。
有一部分文件是共用的：adb.c, fdevent.c, transort.c, transport_local.c, tansport_usb.c, service.c, sockets.c, util.c。
举个例子<code>adb.c</code>:
通过adb_host这个宏编译不同的代码。其他大部分文件则由server和client后缀可以区分。
跟我们的主题息息相关的主要就是install系列的命令了，先看看命令使用：
分别对应<code>commandline.cpp</code>下的三个方法:
这里以install命令为例看看adb做了什么:
还有几个有趣的命令
为什么有时候会安装不上apk呢？安装的界面是怎么弹出来的？抱着这些疑问，我们看下去。
大致上有四种
系统程序安装，开机时安装，没有安装界面。
由开机时启动的<code>packagemanagerservice</code>服务完成，会在启动时扫描<code>/system/app</code>, <code>vender/app</code>, <code>/data/app</code>, <code>/data/app-private</code>并安装。
通过android市场安装，google play可以直接安装，其他市场除非root，否则需要自己点击安装（除非定制rom），即和第4种一样。
adb安装，即上一节说的，也没有安装界面。shell:pm是<code>packagemanagerservice</code>的shell客户端，源码位于
/frameworks/base/cmds/pm
执行路径大致是从main -> run -> runinstall，挑一段最后的核心代码<code>pm.java</code>:
手机自行通过文件浏览器打开安装，有安装界面。
当我们在手机的文件管理器或者notification点击apk文件，就会出现如下图所示（nexus6 android 6.0.1）的界面，点击安装按钮即可开始安装，点击取消按钮返回。
安装界面
这个安装界面是android系统程序packageinstaller的packageinstalleractivity，dump一下可以看到如下图信息
packageinstalleractivity
当android系统请求安装apk程序时，会启动这个activity，并通过intent读取传来的apk信息，我们来简单看看该activty oncreate的代码:
整个方法有2个重点函数。
1) <code>packageutil.getpackageinfo(sourcefile)</code>
<code>getpackageinfo</code>会构造<code>packageparser</code>，调用<code>package parsemonolithicpackage(file apkfile, int flags)</code>去解析该apk程序包，然后记录下manifest的校验码。
<code>parsemonolithicpackage()</code>对于我们普通的app又会调用<code>parsebaseapk(file apkfile, assetmanager assets, int flags)</code>去做真正的解析并获得package对象（该类里有很多给split apk用的方法和逻辑）。
解析过程会首先读取androidmanifest.xml获取程序包名以构建package对象，然后再处理manifest的其他标签包括四大组件，并把信息全都存到package对象里面。
2) <code>initiateinstall()</code>
首先检测该程序是否已安装，是则弹框提示是否替换程序，否则直接调用<code>startinstallconfirm()</code>，做ui初始化和事件绑定，于是当我们点击安装的时候则会触发onclick下的ok按钮事件:
对于本地app则会继续走<code>startinstall</code>的逻辑，开启一个新的activity，installappprogress，该activity判断scheme进行不同的安装:
<code>installpackagewithverificationandencryption()</code>其实还是会调用<code>installpackage()</code>，结果和adb安装殊途同归，整个转的路径为<code>installpackage()</code> -> <code>installpackageasuser()</code>(这儿会先检查调用者是否有安装的权限)
-> processpendinginstall() -> installpackageli():
无论是替换还是新安装，都会调用<code>scanpackageli()</code>，然后跑去<code>scanpackagedirtyli</code>，它会判断是否为系统程序，解析apk程序包，检查依赖库，验证签名，检查shareduser签名、权限冲突、contentprovider冲突，更新native库目录文件（检测abi），进行dexopt，杀掉现有进程（仅对覆盖安装的场景）等等，最后调用createdatadirsli()进行实际安装:
<code>minstaller</code>为<code>installer</code>类的实例，但实际安装并不是在java做的，而会通过<code>installerconnection</code>把命令使用socket通信发到/system/bin/installd。
在这里第一次call的<code>install()</code>对应命令为
<code>install uuid name uid gid seinfo</code>
而第二次call的<code>createuserdata</code>则会使用命令
<code>mkuserdata uuid name uid userid seinfo</code>
installd是一个常驻进程，可以在adb shell通过<code>ps | grep installd</code>查看进程信息。源码位于frameworks/native/cmd/installd/installd.cpp下（dexopt也在这里哦），处理install命令的函数为do_install(),
do_install调用了<code>command.cpp</code>的<code>install()</code>:
执行完毕后，通过socket回传结果，而<code>packageinstaller</code>根据返回结果做对应处理并显示给用户，至此为止，整个apk安装过程结束。
我们了解了一个android工程是怎么变成apk的，apk是怎么跑到设备上，而最后又是如何安装的。下一次我们来看看dex和odex，art上的elf和oat都是什么，而dexopt又做了什么优化。dex加壳技术大多就是在dex上面做了手脚。
参考文献：
<a target="_blank" href="http://developer.android.com/tools/building/index.html">http://developer.android.com/tools/building/index.html</a>
<a target="_blank" href="http://developer.android.com/sdk/installing/studio-build.html">http://developer.android.com/sdk/installing/studio-build.html</a>
<a target="_blank" href="http://blog.csdn.net/luoshengyang/article/details/8744683">http://blog.csdn.net/luoshengyang/article/details/8744683</a>
《android软件安全与逆向分析》，作者：丰生强，人民邮电出版社
<a target="_blank" href="https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_kobayashi.pdf">https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_kobayashi.pdf</a>
<a target="_blank" href="http://developer.android.com/tools/help/adb.html">http://developer.android.com/tools/help/adb.html</a>
写的途中还不慎看到csdn上某排名500多的百度大v声称自己看老罗的博客并结合参考资料写的整理，实则完全就是照抄书上的，连错误的地方都照抄了，也没有说是人家的，我也是呵呵哒。更有趣的是该作者还在新的文章里提到觉得网上的文章内容重复太多。恩恩，不愧是伟大的百度公司的开发。实在忍不住喷一下。果然还是太年轻。