APK安装(一)—— PMS原理分析

Posted 2023-03-23

参考技术A

在 APK安装概述 中曾提及apk有四种安装场景，但无论是哪一种方式，最终会提交给 PackageManagerService 处理，只是前置的处理链路 不同，所以本篇先对 PMS 这一主要过程进行分析。 frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java 【基于Android 9.0】

1、对特定的一些系统进程信息进行设置处理，并保存到 Settings 中
2、解析 /etc/permissions 下相关xml文件取得系统相关权限、系统具备的相关功能等信息
3、解析 /data/system/package.xml 文件获取已安装应用的相关信息
4、对相关的 apk 和 jar 进行 dex 优化处理，主要是 /system/framework 目录下的相关jar和apk
5、依据 sharedUserId 这个配置来确定 apk 运行在哪个进程，然后把运行的相关进程信息加入到 Settings 中，使得系统可以知道每个 apk 运行在哪个进程中
6、解析 AndroidManifest.xml 文件，提炼文件中的节点信息
7、扫描本地文件，主要针对系统应用、本地安装应用等等
8、管理本地 apk ，包括安装、删除等

前面说到 APK 的信息会提交给 PMS 进行安装的一系列工作，具体是通过 PackageHandler 发送消息来驱动 APK 的复制和安装，其时序图如下：

上相过程中有几点需要说明：
1、在 installStage 方法中创建了 InstallParams 对象，它对应于包的安装数据，并创建 INIT_COPY 消息并发送给 PackageHandler 进行处理；
2、 PackageHandler 在处理 INIT_COPY 消息时，会先判断是否绑定了 DefaultContainerService ，这是用于检查和赋值可移动文件的服务，比较耗时，所以和 PMS 并没有运行在同一个进程中，它们之间通过 IMediaContainerService 进行 IPC 通信，没有绑定则会进行绑定，之后

DefaultContainerConnection 同样是定义在 PMS 中，执行链路如下:

3、发送 MCS_BOUND 消息时，根据发送的 Message 是否带 Object 分为两种，如下所示：

4、 MCS_BOUND 消息的处理：

HandlerParams 是 PMS 中的抽象类，它的实现类为 PMS 的内部类 InstallParams 。 HandlerParams 的 startCopy 方法如下所示：

PackageManagerService.java#HandlerParams

在 注释① 处调用抽象方法 handleStartCopy ，具体实现在 InstallParams 中，如下所示：
PackageManagerService.java#InstallParams

1、 注释① 处确定了 APK 的安装位置。
2、 注释② 处创建 InstallArgs 对象，此对象是一个抽象类，定义了 APK 的复制和重命名APK等安装逻辑，在 Android 8.x 及之前的版本中有三个子类： FileInstallArgs、AsecInstallArgs、MoveInstallArgs 。其中 FileInstallArgs 用于处理安装到非ASEC的存储空间的APK，即内部存储空间（Data分区）； AsecInstallArgs 用于处理安装到ASEC（mnt/asec）即SD卡中的APK； MoveInstallArgs 用于处理已安装APK的移动的逻辑；但在 Android 9.x 之后已经去掉了 AsecInstallArgs ，
3、 注释③ 处调用 InstallArgs 的 copyApk 方法，这里以 FileInstallArgs 的实现为例，内部会调用 FileInstallArgs 的 doCopyApk 方法：

1、 注释① 处用于创建临时存储目录，比如 /data/app/vmdl18300388.tmp ，其中 18300388 是安装的 sessionId ；
2、 注释② 处通过 IMediaContainerService 跨进程调用 DefaultContainerService 的 copyPackage 方法，这个方法会在 DefaultContainerService 所在的进程中将 APK 复制到临时存储目录，比如 /data/app/vmdl18300388.tmp/base.apk ，至此 APK 的复制工作结束。

在上述 APK 的赋值调用链的过程中，在 HandlerParams 的 startCopy 方法中，会调用 handleReturnCode 方法，时序图如下：

PackageManagerService#handleReturnCode :

注释① 处检查APK的状态，在安装前确保安装环境的可靠，如果不可靠会清除复制的APK文件， 注释③ 处会检测是否安装成功，失败则删除安装相关的目录和文件。安装完成之后在 注释⑤ 处会发送 POST_INSALL 消息通知已安装完成，此处稍后会说明。
注释② 处的 installPackageTracedLI 会调用 PMS 的 installPackageLI 方法：
PackageManagerService.java#installPackageLI :

这里需要说明几点：
1、 注释③ 处，会先检测 Settings 中保存有要安装的 APK 信息，则说明安装该 APK ，因此需要检验APK 的签名信息，确保安全的进行替换。
2、 注释④ 处，会对临时文件重新命名，例如 /data/app/vmdl18300388.tmp/base.apk ，重命名为 /data/app/包名-oONlnRRPYyleU63AveqbYA==/base.apk 。新的包名后面带上的一串字母和数字的混合字符串，是使用MD5的方式对随机生成的16个字符进行加密之后的产物。
3、 注释⑤ 处，根据 replace 来做区分，如果是替换安装就会调用replacePackageLIF方法，其方法内部还会对系统APP和非系统APP进行区分处理，如果是新安装APK会调用installNewPackageLIF方法

PackageManagerService.java#installNewPackageLIF ：

在上面 processPendingInstall 方法的源码分析中，在 注释⑤ 处会发送 POST_INSTALL 消息通知安装完成，那么接下来就来具体看一看在 PackageHandler 中是怎么处理这个消息的。

以上为主要的方法摘要，具体可总结为：
1、第一步：这里主要是先将安装信息从安装列列表中移除，这个也是前面在processPendingInstall中添加的
2、第二步：安装成功后，获取运行时权限
3、第三步：获取权限后，发送ACTION_PACKAGE_ADDED广播，告诉Laucher之流，更新icon
4、第四步：如果是升级更新则在发送两条广播

5、第五步：如果安装包中设置了PRIVATE_FLAG_FORWARD_LOCK或者被要求安装在SD卡上，则调用sendResourcesChangedBroadcast方法来发送一个资源更改的广播
6、第六步：如果该应用是一个浏览器，则要清除浏览器设置，重新检查浏览器设置
7、第七步：强制调用gc，出发JVM进行垃圾回收操作
8、第八步：删除旧的安装信息
9、回调回调 IPackageInstallObserver2 的 packageInstalled 方法。告诉 PackageInstaller 安装结果。从而实现了安装回调到UI层

上述几部分大致说明 PMS 处理 APK 的主要步骤，可总结如下：
1、当 PackageInstaller 将 APK 的信息提交给 PMS 处理， PMS 会通过向 PackageHandler 发送消息来驱动 APK 的复制和安装工作
2、 PMS 发送 INIT_COPY 和 MCS_BOUND 类型的消息，控制 PackageHandler 来绑定 DefaultContainerService 来完成 APK 的复制等工作
3、复制 APK 完成之后，则开始进行安装 APK 的流程，包括安装前的检查、安装 APK 和安装后的收尾工作。

[ 1 ] https://maoao530.github.io/2017/01/18/package-install/
[ 2 ] https://blog.csdn.net/yiranfeng/article/details/103941371
[ 3 ] http://liuwangshu.cn/framework/pms/3-pms-install.html
[ 4 ] https://www.freesion.com/article/5119749905/
[ 5 ] https://www.jianshu.com/p/9ddb930153b7