点击上方胡飞洋可以关注哦~

最近在了解插件化技术：把未安装的插件apk 集成到 宿主App中，以取得减少宿主APK包体积等优点。也就是说，一个完整的APK 虽然不经过安装过程，但使用了插件化技术后却可以在宿主中使用其功能。

那么对应的，一个APK的完整安装过程是怎样的呢？用户通常能体验到的安装过程有两种：

image.png

先下载APK，然后是安装过程，过程中没有跳转到其他页面，可以说是一键安装。

image.png

这种通常是用户下载一个APK文件，然后手动点击，跳转到安装页面，提示这个APK的下载信息等，然后是安装包详情页面，展示 版本号、所需权限 等一些信息，最后是安装中的页面。我使用的是小米手机，对应的Activity信息如下，这其中PermissionInfoActivity是点击“应用权限”的权限详情页面。

发现整个安装过程是执行在小米系统miui的"com.miui.packageinstaller"中，那么可想而知在原生Android系统也有对应的Activity。

APK包体越大，安装时间就越长，因为需要解析和校验的越多。无论哪种方式，安装完成后都会通知到 桌面应用Launcher，Launcher在桌面上添加一个App图标。这就是用户感受到的安装过程。

好了，APK安装过程 就讲完了！

—— 并没有😄，APK安装具体过程是怎样的？我们是Android应用开发者，read the source code！

阅读源码是一件痛苦的事情，一般需要结合其他资料一起理解。并且，重点掌握整体流程即可。

我们先来了解一个类：PackageManagerService（PMS），通过名字 你可能会想起 和四大组件紧密相关的 ActivityManagerService（AMS），它俩都是运行在SystemServer进程，App端和AMS、PMS进行交互都是通过Binder跨进程完成。AMS负责Activity等四大组件的管理，而PMS则负责 包package 的管理，APK的全称是Android Package，即PMS的作用就是管理APK。

除了这里的PMS，在之前相关文章中还介绍了 ActivityManagerService（AMS）、WindowManagerService（WMS）。

在平时开发中，我们会需要获取当前已安装的包的相关信息，例如已安装应用列表等，就可以在Activity中这么写：

getPackageManager() 实际是Context的方法，具体实现是 ContextImpl 中：

注意获取到的 PackageManager 实际是 ApplicationPackageManager，构造方法中传入了 通过 ActivityThread 获取的 IPackageManager、IPermissionManager。并且查看ApplicationPackageManager，会发现 基本所有方法都是对 传入的 pm的封装：

我们再看看 ActivityThread.getPackageManager() 如何获取 IPackageManager ：

到这里如果你对AMS的跨进程（IPC）比较熟，就会知道 这里同样是 为了IPC，即获取 SystemServer中 PMS 在App端的代理 IPackageManager。也就说，上面在Activity中通过getPackageManager()获取已安装应用列表，最后是IPC到了系统进程，在 PMS 中执行。类图如下：

image.png

那么 PMS 什么时候完成初始化的呢？因为 所有App运行都需要 这些系统服务，所以必然是 系统开机的时候 完成 PMS、AMS这些的初始化：

在开机系统启动时，zygote 进程会fork一个 SystemServer 进程然后执行上面main方法，这里进行大量的初始化，其中就包括 启动各种服务。这里我们看startBootstrapServices():

发现这里开启了 AMS、PMS，并且都使用了Installer。Installer 看名字像是安装器，后面再做介绍。PMS的main方法内用构造方法创建了PMS实例，而它的构造方法内容特别多，我们关注其中一句调用scanDirTracedLI()：

先读取packages.xml文件，解析后将数据存放到mSettings中，代表上次启动时的应用包信息。然后扫描所有APK目录并解析APK，最后更新packages.xml文件。而 packages.xml文件 是在 Settings 构造方法中创建。

data/app 是用户已安装App所在的目录，另外还有system/app存放 系统App。PMS构造方法中会对 这两个目录在内的多个目录进行扫描，我们这里可以猜想到这是开机时对所有已安装App的初始化。scanDirTracedLI()又走到scanDirLI()，那么就来详细看看怎么扫描的：

使用 ParallelPackageParser 对目录内的所有apk进行解析 然后使用 addForInitLI()处理解析结果parseResult。ParallelPackageParser 实际是对 PackageParser2 的使用上的封装，APK解析操作会走到 PackageParser2 的 parsePackage():

这里parsingUtils 是 ParsingPackageUtils 的实例，继续看parsingUtils.parsePackage():

两个分支 都会走到parseBaseApk()：

这里创建了 XmlResourceParser 实例，适用于解析APK的AndroidManifest.xml 文件，然后调用了重载的parseBaseApk()：

parseBaseApkTags()内部使用 XmlResourceParser 查找 AndroidManifest.xml中的 Application 标签，然后调用 parseBaseApplication() 来解析 APK中的基础 Application 节点树：

这里就是解析Application的子节点——四大组件，并把信息存入ParsingPackage实例pkg中，最后转成 ParallelPackageParser.ParseResult。那么再回到 PMS构造方法，解析后调用了 addForInitLI()，这个方法逻辑复杂，有很多对系统应用的校验（包名修改、版本升级、签名手收集和校验)，但我们只关注下面内容:

调用scanPackageNewLI()继续扫描，主要是更新 packageSetting（PackageSetting主要包含了一个APP的基本信息，如安装位置，lib位置等信息）。然后调用reconcilePackagesLocked()进行一致化处理，调用commitReconciledScanResultLocked() 提交包扫描结果、更新系统状态，内部又调用了commitPackageSettings():

也就是包信息记录在了PMS的属性中。也就是说，系统启动后，包信息记录在了PMS管理的内存中。

小结一下，系统启动后创建并启动了PMS，并且PMS完成了对所有存在APK的目录进行了扫描，解析所有APK的AndroidManifest.xml，然后进一步扫描APK 最后提交包扫描结果到 PMS 的属性中。

以上就是对 开机启动时 APK安装流程 的简单理解。那么，下面就来看看 APK安装普通流程。

上面提到，普通的应用安装过程 是执行在小米系统miui的"com.miui.packageinstaller"中，安装过程涉及几个Activity，我们来看看 如何使用代码 安装一个APK文件，以及原生Android系统是哪些Activity。

安装APK的代码如下：

Action是Intent.ACTION_VIEW，type是"application/vnd.android.package-archive"，这次使用 api 30的 原生模拟器，Activity信息如下：

过程截图如下：

image.png

我们从InstallStaging开始看起：

只做了一件事，开启AsyncTask 读取 apk文件，然后 启动了activity DeleteStagedFileOnResult，这是个跳板页面，里面直接透传 intent 启动了 PackageInstallerActivity：

整体逻辑比较清晰：

我们先看包信息 PackageInfo 的解析过程——PackageUtil.getPackageInfo():

继续看PackageManager的getPackageArchiveInfo()：

调用了 ParsingPackageUtils 的静态方法parseDefault()，里面创建了 ParsingPackageUtils 实例，继续调用它的 parsePackage()。上面介绍的 PMS 构造方法中 解析APK 也是 ParsingPackageUtils的 parsePackage()，只是这里的 参数flags 是 PackageManager.GET_PERMISSIONS，只解析了权限信息。这里不再跟踪进去了。

最终解析 获取到了apk所有信息的 PackageInfo，然后 点击”安装“ 跳转到了 InstallInstalling。

直接看 InstallInstalling：

整体过程如下：

PackageInstaller，APK安装器，是在ApplicationPackageManager的 getPackageInstaller()中创建：

是对 mPM.getPackageInstaller() 获取的 IPackageInstaller实例的封装，而 IPackageInstaller 在系统服务端的具体实现是 PackageInstallerService。

且 PackageInstallerService 的实例是在 PMS 的构造方法中创建的，初始化时会读取 /data/system 目录下的 install_sessions.xml 文件，这个文件中保存了系统中未完成的 Install Session。PMS 会根据文件的内容创建 PackageInstallerSession 对象并插入到 mSessions 中。

PackageInstaller 提供了 应用安装、更新、移除的能力，当然具体实现是 IPC 到了 PackageInstallerService中。

Session，是与 mSessionId绑定的安装会话，代表一个进行中的安装。Session类是对 IPackageInstaller.openSession(sessionId) 获取的 PackageInstallerSession（系统服务端）的封装。Session 管理安装的参数，并提供将安装包临时复制到特定路径（data/app-staging）的能力。

Session的创建和打开 具体实现是在 PackageInstallerService中，主要是 初始化apk的安装信息及环境，并创建一个sessionId，将安装Session与sessionId 进行绑定。（代码较多，就不放了）

我们重点看 把包信息写入mSessionId对应的session，然后提交，回到 InstallInstalling 中，看到在 InstallingAsyncTask 中执行了对 APK包文件 的读取和写入操作，写入的输出流是 通过Session获取，也即是把 将APK文件写入了Session 。完成后 又调用了 session.commit()，具体实现是在PackageInstallerSession， 来看看：

发送了一个handler消息，最后执行在 handleStreamValidateAndCommit()中，然后里面又发送了消息MSG_INSTALL，这个执行在handleInstall()：

最后，安装过程走到了 PMS 的 installStage()。

目前为止，只是通过 PackageInstaller 维持了安装 Session，把安装包写入到 Session中，真正的安装过程是 PMS 来执行。

那就直接看 PMS 的 installStage()：

mHandler 处理INIT_COPY是 params.startCopy():

调用了两个方法实现是在 InstallParams 中：

解析包返回最小的细节：pkgName、versionCode、安装所需空间大小；确认包安装位置；校验APK完整性。获取结果mRet。然后就看 handleReturnCode()：

判断mRet，执行apk拷贝，然后执行安装。先看 mArgs.copyApk()如何拷贝：

在FileInstallArgs中的copyApk()走到doCopyApk()，先获取了拷贝文件路径：/data/app，使用PackageManagerServiceUtils.copyPackage()进行APK拷贝，接着是 .so文件的拷贝。也就是说，把发送到 Session暂存目录 data/app-staging 的APK 拷贝到了 /data/app。

接着看执行安装processPendingInstall(mArgs, mRet)：

这里我们先重点看安装过程，installPackagesTracedLI() 又走到 installPackagesLI():

安装过程分四个阶段:

前三步主要是 解析和校验，第四部是把 包信息 提交到 PMS 内存数据结构中。其中解析和提交在上面的PMS初始化中 扫描apk目录后也是同样的过程。这里就不再展开跟踪了。

安装完成后，调用了 executePostCommitSteps() 准备app数据、执行dex优化：

这两个操作最终都是使用 Installer 对应的方法来操作。前面介绍 PMS 创建时传入了 Installer 的实例，而 Installer 继承自 SystemService 也是一个系统服务。这里来看下：

到这里安装完成，再回到 PMS 的 processInstallRequestsAsync()，最后调用restoreAndPostInstall()进行 备份、可能的回滚、发送安装完成先关广播：

mHandler 使用 PMS的 handlePackagePostInstall(）方法处理 POST_INSTALL：

到这里，APK的安装过程 就梳理完毕了，来回顾下：

未命名文件.png

本篇从用户感受的APK安装讲起，分别详细梳理了 包管理器服务——PackageManagerService 的服务开启、初始化扫描过程；然后分析了对应原生系统的安装过程及页面；接着就是详细分析了安装流程，包括创建Session 发送APK、PMS中的APK拷贝操作、包括APK解析校验和dexOpt等具体安装流程；最后是安装结果的发送。

内容确实很多，但是我们只需要重点了解 PMS的初始化、APK安装 的整体流程即可，无需关注繁杂的细节。

虽然耗费时不少时间阅读源码、也阅读了一些文章，但不免有错误和遗漏之处。欢迎讨论~