Android---App 的安装过程

Android 系统中两个比较重要的服务 ActivityManagerService(AMS) 和 WindowManagerService(WMS)，这篇文章中通过分析 apk 的安装过程，来了解 Android 中另一个比较重要的系统服务 -- PackageManagerService(PMS)。

编译阶段

在分析安装过程之前，需要先了解 Android 项目是如何经过编译打包生成最终的 .apk 格式的安装包。Google 有一张官方图片来描述 apk 的打包流程。

一个完整的项目可能包含多个 module，而每一个 module 中的内容可以分为2部分：

$\bullet$ Resources 资源文件；

$\bullet$ Java 或者 Kotlin 源代码。

因此整个项目的编译打包过程，也是针对这两部分来完成的。

编译 Resource 资源文件

资源文件包括项目中 res 目录下的各种 XML 文件、动画、drawable 图片、音视频等。AAPT 工具负责编译项目中的这些资源文件，所有资源文件会被编译处理。XML 文件（drawable 图片除外）会被编译成二进制文件。所以解压 apk 之后，无法直接打开 XML 文件。但是，assets 和 raw 目录下的资源并不会被编译，会被原封不动的打包到 apk 压缩包中。

资源文件编译之后的产物包括两部分：

$\bullet$ resource.arsc 文件（保存的是一个资源索引表）；

$\bullet$ R.java 文件（定义了各个资源 ID 常量）。

这两者结合就可以在代码中找到对应的资源引用。比如如下的 R.java 文件

可以看出 R.java 中的资源 id 是一个4字节的无符号整数，用16进制表示。其中最高的1字节（7f）表示 packageId，次高的一个字节（01）表示 typeId，最低的两个字节（0000）表示 entryId。

resources.arsc 相当于一个资源索引表，也可以理解为一个 map 映射表。其中，map 的 key 是 R.java 中的资源 ID，而 value 是其对应的资源所在路径。实际上 resources 描述上还有其它相关信息。关于 Resource.arsc 的解析可以参考：解析编译之后的 Resource.arsc 文件格式

编译源码部分

项目中的代码首先会通过 javac 编译为 .class 字节码文件，然后这些 .class 文件连同依赖的第三方库中的 .class 文件一同被 dx 工具优化为 .dex 文件。如果有分包，那么也可能会生成多个 .dex 文件。实际上，源代码文件也包括 AIDL 接口文件编译之后生成的 .java 文件。Android 项目中如果包含 .aidl 接口文件，这些 .aidl 文件会被编译成 .java 文件。

打包阶段

使用工具 APK Builder 将已经编译之后的 resource 和 .dex 文件一起打包到 apk 中。实际上被打包到 apk 中的还有一些其他资源。比如 AndroidManifest.xml 清单文件和第三方库中使用的动态库 .so 文件。

apk 创建好之后还不能直接使用，需要使用工具 jarsigner 对其进行签名。Android 系统不会安装没有签名的程序。签名之后会生成 META_INF 文件夹，此文件夹中保存着跟签名相关的各个文件：

$\bullet$ CERT.SF：生成每个文件相对的密钥；

$\bullet$ MANIFEST.MF：数字签名信息；

$\bullet$ xxx.SF：JAR 文件的签名文件；

$\bullet$ xxx.DSA：对输出文件的签名和公钥。

PMS 在安装过程中，会检测 apk 中的签名、证书的合法性。

按照常量，签名之后的 apk 应该是能正常安装使用了。但是，实际打包过程还会多一步 apk 优化操作。使用工具 zipalign 对 apk 中的未压缩资源（图片、视频）等进行对齐操作。让资源按照 4 字节的边界进行对齐，这种思想主要是为了加快资源的访问速度。如果每个资源的开始位置都是上一个资源之后的 4*n 字节，那么访问下一个资源就不用再遍历，直接跳到 4*n 字节处判断是不是一个新的资源即可。

至此，一个完整 apk 安装包就创建成功。一个完整 apk 解压缩之后内容，如下图所示

整个编译打包流程可以用下图来描述

PMS 将 apk 安装到手机设置

PMS 安装过程概览

当点击某一个 App 安装包进行安装时，首先会弹出一个系统界面指示我们进行安装操作，这个界面是 Android Framework 中预置的一个 Activity--PackageInstallerActivity.java。当点击安装后，PackageInstallerActivity 最终会将所安装的 apk 信息，通过 PackageInstallerSession 传给 PMS。

具体方法在 commitLocked() 方法中，如下代码所示

图中的 mPm 就是系统服务 PackageManagerService。installStage 方法就是正式开始 apk 的安装过程。整个 apk 的安装过程可以分为两大步：1）拷贝安装包；2）装载代码。

拷贝安装包

从 installStage 方法开始看起，代码如下

图中1处创建了类型为 INIT_COPY的 message；图中2处创建了 InstallParams，并传入安装包的相关数据。

message 发送出去之后，由 PMS 的内部类 PackageHandler 接收并处理，如下代码所示

图中1处从 message 中取出 HandlerParams 对象；图中2处调用 connectToService() 方法连接安装 apk 的 service 服务。

PackageHandler 的 connectToService 方法

通过隐私 Intent 方法绑定 Service。实际绑定的 Service 类型是 DefaultContainerService 类型

当绑定 Service 成功之后，会在 onServiceConnected 方法中发送一个绑定操作的 message，如下所示

MCS_BOUND message 的接收者还是 PackageHandler，具体如下

mPendingInstall 是一个等待队列，里面保存所有需要安装 apk 解析出来的 handlerParams 参数。从 mPendingInstalls 中取出第一个需要安装的 HandlerParams 对象，并调用其 startCopy() 方法。在 startCopy() 方法中，继续调用一个抽象方法 handlerStartCopy() 处理安装请求。

通过之前的分析，我们知道 HandlerParams 实际类型是 InstallParams。因此，最终调用的是 InstallParams 的 handlerStartCopy 方法。

InstallParams 的 handlerStartCopy 方法

这个方法是整个安装包拷贝的核心方法。具体如下

图中1处设置安装标志位，决定是安装在手机内部存储空间还是 SD卡当中。图中2处判断 apk 安装位置，如果安装位置合法，则执行图中3处逻辑，创建一个 InstallArgs。实际上是其子类 FileInstallArgs 类型。然后调用其 copyApk() 方法进行安装包的拷贝工作。

FileInstallArgs 的 copyApk 方法

从图中可以看出，copyApk() 方法调用了 doCopyApk() 方法。doCopyApk 方法中主要做了3件事情。

图中1处创建存储安装包的目标路径，实际上是 dateApp应用包名目录；图中2处调用服务的 copyPackage 方法，将安装包 apk 拷贝到目标路径下；图中3处将 apk 中的动态库 so 文件也拷贝到目标路径中。

上图中的 IMediaContainerService 实际上就是在开始阶段进行连接操作的 DefaultContainerService 对象。其内部 copyPackage() 方法本质上就是执行 io 流操作，具体如下

最终，安装包在 dataApp 目录下以 base.apk 的方法保存。

至此，安装包的拷贝工作就已经完成。

装载代码

代码拷贝结束之后，就开始进入真正的安装步骤。代码回到上述的 HandleParams 的 startCopy 方法。

可以看出当安装包拷贝结束之后，继续调用 handleReturnCode() 方法来处理返回结果。最终调用 processPendingInstall() 方法处理安装过程，代码如下

图中1处执行预安装的操作，主要是检查安装包的状态，确保安装环境正常。如果安装环境有问题，则会清理拷贝文件；图中2处，是真正的安装阶段。installPackageTraceLI 方法中添加跟踪 trace，然后调用 installPackageLI 方法进行安装。图中3处处理安装完成之后的操作。installPackageLI 是 apk 安装阶段的核心代码

图中1处，调用 PackageParser 的 parsePackage 方法解析 apk 文件。主要是解析 AndroidManifest.xml 清单文件。将结果记录在 PackageParser.package 中。我们在清单文件中声明了 Activity、Service 等组件，就是在这一步被记录到 framework 中。后续它可以通过 startActivity 或 startService 启动相应的活动或者服务；图中2处对 apk 中的签名信息进行验证操作。collectCertificates 做签名验证，collectManifestDigest 主要做包的项目清单摘要的收集。主要是用来两个包是否一样，如果我们的设备上已经安装了一个 debug 版本的 apk，再次使用一个 release 版本的 apk 进行安装覆盖，会在这一步验证失败，会最终导致安装失败。图中3处执行 Dex 优化。图中4处调用 installNewPackageLI 方法，执行新 apk 的安装操作。

installNewPackageLI 方法，负责完成最后的 apk 安装过程。具体代码如下