android的apk如何安装到手机（Android10.0PackageManagerService）

阅读本文大约需要花费40分钟。

文章首发大猫玩程序

专注于Android系统级源码分析，Android的平台设计，欢迎关注我，谢谢！

上一节讲解了apk的扫描，本节讲解APK的安装流程

系列文章：

Android 10.0系统源码取经之路——启动篇

Android系统架构浅析-「Android取经之路」

Android是怎么启动的-「Android取经之路」

Android 10.0系统启动之init进程（一）-「Android取经之路」

Android 10.0系统启动之init进程（二）-「Android取经之路」

Android 10.0系统启动之init进程（三）-「Android取经之路」

Android 10.0系统启动之init进程（四）-「Android取经之路」

Android 10.0系统启动之Zygote进程（一）-「Android取经之路」

Android 10.0系统启动之Zygote进程（二）-「Android取经之路」

Android 10.0系统启动之Zygote进程（三）-「Android取经之路」

Android 10.0系统启动之Zygote进程（四）-「Android取经之路」

Android 10.0系统启动之SystemServer进程（一）

Android 10.0系统启动之SystemServer进程（二）

Android 10.0系统服务之AMS启动流程--「Android取经之路」

Android10.0系统启动之Launcher启动流程-「Android取经之路」

Android10.0应用进程创建过程以及Zygote的fork流程

Android 10.0 PackageManagerService（一）工作原理及启动流程

1.概述

Android应用安装有如下四种方式：

• 1)系统应用和预制应用安装――开机时完成，没有安装界面，在PKMS的构造函数中完成安装

• 2)网络下载应用安装――通过应用商店应用完成，调用PackageManager.installPackages()，有安装界面。

• 3)ADB工具安装――没有安装界面，它通过启动pm脚本的形式，然后调用com.android.commands.pm.Pm类，之后调用到PMS.installStage()完成安装。

• 4)第三方应用安装――通过SD卡里的APK文件安装，有安装界面，由packageinstaller.apk应用处理安装及卸载过程的界面。

上述几种方式均通过PackageInstallObserver来监听安装是否成功。

2.代码路径

/frameworks/base/packages/apps/PackageInstaller/src/com/android/packageinstaller/PackageInstallerActivity.java /frameworks/base/packages/PackageInstaller/src/com/android/packageinstaller/InstallInstalling.java /frameworks/base/core/java/android/content/pm/IPackageInstallerSession.aidl /frameworks/base/services/core/java/com/android/server/pm/PackageInstallerSession.java /frameworks/base/services/core/java/com/android/server/pm/Installer.java /system/core/adb/client/commandline.cpp /system/core/adb/client/adb_install.cpp /frameworks/base/services/core/java/com/android/server/pm/PackageManagerShellCommand.java

3.APK的包组成

生成的APK文件本质还是一个zip文件，只不过被Google强行修改了一下后缀名称而已。所以我们将APK的后缀修改成.zip就可以查看其包含的内容了。

如下图所示：

• META-INF：关于签名的信息存放，应用安装验证签名的时候会验证该文件里面的信息 -res：资源文件，是被编译过的。raw和图片是保持原样的，但是其他的文件会被编译成二进制文件。

• res：这里面的资源是不经过编译原样打包进来的

• AndroidManifest.xml：程序全局配置文件。该文件是每个应用程序都必须定义和包含的文件，它描述了应用程序的名字、版本、权限、引用的库文件等等信息。

• classes.dex：Dalvik字节码文件，Android会将所有的class文件全部放到这一个文件里。

• resources.arsc：编译后的二进制资源文件，保存资源文件的索引，由aapt生成

• lib: 如果存在的话，存放的是ndk编出来的so库

4.APK的打包过程

打包具体步骤如下图所示：

编译器将源代码转换成DEX（Dalvik Executable) 文件，将资源文件转换成已编译资源。

APK打包器将DEX文件和已编译资源合并成单个APK。不过，必须先将APK签名，才能将应用安装并部署到Android设备上。

APK打包器使用密钥签署APK：a. 如果构建的APK是debug版本，那么将使用调试密钥签名，Android会默认提供一个debug的密钥。b. 如果构建的是release版本，会使用发布版本的密钥签名。

在生成最终的APK文件之前还会使用zipalign工具来优化文件。

5.APK SignatureSchemev2

使用V2的原因Android7.0(Nougat)引入一项新的应用签名方案APK SignatureSchemev2,它是一个对全文件进行签名的方案,能提供更快的应用安装时间、对未授权APK文件的更改提供更多保护.v2signature官方解释同时V2方案对V1方案做了 很好的兼容处理(Apk中同时存在v1,v2签名)。

V1签名apk-signature-v1-location.png只是校验了apk资源,并没有约束zip,签名信息存储在zip/META-INF中。

APK Signature Scheme v2,它是一个对全文件进行签名的方案,能提供更快的应用安装时间、对未授权APK文件的更改提供更多保护.

如下图所示：

新的签名方案会在ZIP文件格式的 Central Directory 区块所在文件位置的前面添加一个APK Signing Block区块，下面按照ZIP文件的格式来分析新应用签名方案签名后的APK包。整个APK（ZIP文件格式）会被分为以下四个区块：

• Contents of ZIP entries（from offset 0 until the start of APK Signing Block）

• APK Signing Block

• ZIP Central Directory

• ZIP End of Central Directory

新应用签名方案的签名信息会被保存在区块2（APK Signing Block）中， 而区块1（Contents of ZIP entries）、区块3（ZIP Central Directory）、区块4（ZIP End of Central Directory）是受保护的，在签名后任何对区块1、3、4的修改都逃不过新的应用签名方案的检查。

6.APK的安装过程

这里我们主要来讲解下载APK后，点击进行安装的过程。

简单来说分为四步：

• 1)将APK的信息通过IO流的形式写入到PackageInstaller.Session中。

• 2)调用PackageInstaller.Session的commit方法，将APK的信息交由PKMS处理。

• 3)拷贝APK

• 4)最后进行安装

涉及的Binder服务：

1)PackageManager（抽象类）----IPackageManager------ PKMS

(实现类：ApplicationPackageManager )

2)PackageInstaller-----IPackageInstaller------PackageInstallerService

（其中会调用IPackageInstaller对象调用PackageInstallerService中的接口）

• 3)PackageInstaller.Session-----IPackageInstallerSession------ PackageInstallerSession

（PackageInstaller.Session中有IPackageInstallerSession类型的成员变量，来调用 PackageInstallerSession的接口）

点击安装后到完成APK 拷贝的流程如下：

点击一个未安装的apk后，会弹出安装界面，点击点击确定按钮后，会进入 PackageInstallerActivity.java的 bindUi()中的mAlert点击事件

点击apk后，弹出的安装界面底部显示的是一个diaglog，主要由bindUi构成，上面有”取消“和”安装“两个按钮，点击安装后 调用startInstall()进行安装

startInstall方法组装了一个Intent，并跳转到 InstallInstalling 这个Activity，并关闭掉当前的PackageInstallerActivity。InstallInstalling主要用于向包管理器发送包的信息并处理包管理的回调。

InstallInstalling 的Activity启动后，进入onCreate

主要分为6步：

• 1.如果savedInstanceState不为null，获取此前保存的mSessionId和mInstallId，其中mSessionId是安装包的会话id，mInstallId是等待的安装事件id

• 2.根据mInstallId向InstallEventReceiver注册一个观察者，launchFinishBasedOnResult会接收到安装事件的回调，无论安装成功或者失败都会关闭当前的Activity(InstallInstalling)。如果savedInstanceState为null，代码的逻辑也是类似的

• 3.创建SessionParams，它用来代表安装会话的参数,组装params

• 4.根据mPackageUri对包（APK）进行轻量级的解析，并将解析的参数赋值给SessionParams

• 5.向InstallEventReceiver注册一个观察者返回一个新的mInstallId，其中InstallEventReceiver继承自BroadcastReceiver，用于接收安装事件并回调给EventResultPersister。

• 6.PackageInstaller的createSession方法内部会通过IPackageInstaller与PackageInstallerService进行进程间通信，最终调用的是PackageInstallerService的createSession方法来创建并返回mSessionId

这里 PackageInstaller 的 createSession()内部会通过IPackageInstaller与PackageInstallerService进行进程间通信，最终调用的是PackageInstallerService的createSession方法来创建并返回mSessionId。

接着在InstallInstalling 的onResume方法中，调用onPostExecute()方法，将APK的信息通过IO流的形式写入到PackageInstaller.Session中

InstallingAsyncTask 的doInBackground()会根据包(APK)的Uri，将APK的信息通过IO流的形式写入到PackageInstaller.Session中

最后在onPostExecute()中 调用PackageInstaller.Session的commit方法，进行安装

接下来看一看PackageInstaller的commit()

commit()中 mSession的类型为IPackageInstallerSession，这说明要通过IPackageInstallerSession来进行进程间的通信，最终会调用PackageInstallerSession的commit方法，这样代码逻辑就到了Java框架层的。

markAsCommitted方法中会将包的信息封装为 PackageInstallObserverAdapter ，它在PKMS中被定义,然后返回到commit()中，向Handler发送一个类型为MSG_COMMIT的消息

MSG_COMMIT在handler中进行处理，进入handleCommit()

commitNonStagedLocked()中首先 调用了PackageInstallObserver的 onPackageInstalled方法，将 Complete 方法出现的PackageManagerException的异常信息回调给

PackageInstallObserverAdapter。

最终调用installStage()，进入PKMS

进入PKMS的installStage()

对INIT_COPY的消息的处理

handleStartCopy()需要执行下面几步：

• 1.首先检查文件和cid是否已生成，如生成则设置installFlags。

• 2.检查空间大小，如果空间不够则释放无用空间。

• 3.覆盖原有安装位置的文件，并根据返回结果来确定函数的返回值，并设置installFlags

• 4.确定是否有任何已安装的包验证器，如有，则延迟检测。主要分三步：首先新建一个验证Intent，然后设置相关的信息，之后获取验证器列表，最后向每个验证器发送验证Intent。

向验证器客户端发送intent，只有当验证成功之后才会开启copy工作。如果没有任何验证器则直接拷贝。

在handleReturnCode()中调用 copyApk()进行APK的拷贝动作

APK 拷贝调用栈如下：

通过文件流的操作，把APK拷贝到/data/app等目录

APK拷贝完成后，进入真正的安装，流程如下：

以原子方式安装一个或多个包。此操作分为五个阶段：

• 1)Prepare 准备：分析任何当前安装状态，分析包并对其进行初始验证。

• 2)Scan 扫描：考虑到prepare中收集的上下文，询问已分析的包。

• 3)Reconcile 调和：在彼此的上下文和当前系统状态中验证扫描的包，以确保安装成功。

• 4)Commit 提交：提交所有扫描的包并更新系统状态。这是安装流中唯一可以修改系统状态的地方，必须在此阶段之前确定所有可预测的错误。

• 5)完成APK的安装

安装过程细分为以下15步：

1)首先检查安装包的完整性并解析安装包。

2) 检查SDK版本和沙箱版本，同时检查是否有静态共享库，如有则需要放在内部存储中。

3)检查是否有子安装包，如有则子安装包也需要检测。

4)校验安装包签名

5)设置相关的权限，包括生成权限、移植权限等

6)如果这是一个系统应用，则检查是否在外部存储上或是是否被其他应用替换等

7) 生成安装包Abi(Application binary interface，应用二进制接口，描述应用程序和操作系统之间或其他应用程序的低级接口)

8)如有必要，优化dex文件

9)冻结APK，并决定是替换安装，还是新安装，组装参数

10)扫描APK，将APK的信息存储在PackageParser.Package类型的newPackage中，一个Package的信息包含了1个base APK以及0个或者多个split APK。

参考上一节的APK扫描：

进入 [PackageManagerService.java] scanPackageTracedLI

调用栈：

scanPackageTracedLI()

|

scanPackageLI()

|

parsePackage()

11) 更新共享库

12)更新该APK对应的Settings信息，Settings用于保存所有包的动态设置。

13) 安装APK,并为新的代码路径准备应用程序配置文件,并再次检查是否需要dex优化

如果是直接安装新包，会为新的代码路径准备应用程序配置文件

如果是替换安装：其主要过程为更新设置，清除原有的某些APP数据，重新生成相关的app数据目录等步骤，同时要区分系统应用替换和非系统应用替换。而安装新包：则直接更新设置，生成APP数据即可。

14)APK的安装

[PackageManagerService.java] prepareAppDataAfterInstallLIF()

通过一系列的调用，最终会调用到[Installer.java] createAppData()进行安装，交给installed进程进行APK的安装

调用栈如下：

prepareAppDataAfterInstallLIF()

|

prepareAppDataLIF()

|

prepareAppDataLeafLIF()

|

[Installer.java]

createAppData()

15)安装完成后，更新设置，更新安装锁等。

7 总结

APK的安装主要分为以下4步：

• 1)将APK的信息通过IO流的形式写入到PackageInstaller.Session中。

• 2)调用PackageInstaller.Session的commit方法，将APK的信息交由PKMS处理。

• 3)拷贝APK

• 4)最后进行安装

最终是交给installed守护进行完成真正的APK安装

,