Android framework 应用安装流程 分析 PackageManagerService(Android5.1)_android framework app安装,更新过程

应用程序的安装是通过包管理服务PackageManagerService完成的，常见的安装方式有以下几种：
① 内置APP随着系统启动PMS而安装。
② 使用adb install命令安装。
③ 通过系统内置的PackageInstaller应用安装。
④ 在一些手机厂商内置的应用商店下载，然后静默安装。
分析源码之后，会发现，其实只有两种方式，
一是系统内置应用通过PackageManagerService使用scanDirLi扫描指定目录下的apk安装。
二是第三方apk通过PackageManager直接或者间接的调用PMS的installPackageAsUser接口安装。

一、安装的Activity

在Android，通过发送Intent可以启动应用的安装过程，如下所示：

在android的系统应用PackageInstaller中有一个PackageInstallActivity会响应这个Intent。在这个Activity中有两个重要的成员变量mPm和mInstaller，分别是ApplicationPackageManger和PackageInstaller的实例对象，这两个对象也是PackageManagerService和PackageInstallerService在应用中的代理对象。

PackageInstallerAcivity中创建这两个对象的代码如下：

二、管理安装会话

PackageManagerInstallerService是Android5.0新加入的服务，主要用于管理安装会话(Installer session)。在Android5.0中，可以通过PackageManagerInstallerService来分配一个SessionId，这个系统唯一的ID代表一次安装过程，如果一个应用的安装分成几个阶段来完成，即使设备重启了，也可以通过这个ID来继续安装过程。

PackageManagerInstallerService中提供的接口createSession来创建一个Session：

这个方法返回一个系统唯一值作为SessionID，如果希望再次使用这个Session，可以通过接口openSession方法来打开它，代码如下：

openSession返回一个IPackageInstallerSession对象，它是Binder服务PackageInstallerSession的IBinder对象。每个Install Session都会在SystemServer中有一个对应的PackageInstallerSession对象。在PackageInstallerService中mSessions数组保存了所有PackageInstallerSession对象，定义如下：

当系统启动时，PackageManageService初始化时会创建PackageManagerInstallerService服务，在这个服务的初始化函数中，会读取/data/system目录下的install_sessions.xml文件，这个文件保存系统未完成的Install Session。然后PackagemanagerInstallerService会根据文件的内容创建PackageInstallerSession对象并插入mSessions中。

PackageInstallerSession中保存了应用安装相关的数据。例如，安装包路径，安装进度、中间数据保存的目录等。

三、应用安装过程

应用可以调用PackageManager的installPackage方法来开始安装过程，最终会调用到PackageManagerService的installPackage或者installPackageAsUser来执行安装过程，整个安装过程比较复杂。

整个安装过程可以分成两个阶段：

1.第一阶段把需要安装的应用复制到/data/app目录下

2.第二阶段是对apk文件扫描优化，装载到内存中。

3.1 复制文件

PackageManagerService的installPackage方法只是用当前用户安装应用，最后也会调用installPackageAsUser

下面我们就来看看installPackageAsUser方法：

installPackageAsUser先检查调用进程是否有安装应用的权限，再检查调用进程所属的用户是否有权限安装应用，最后检查指定的用户是否被限制安装应用。如果参数installFlags带有INSTALL_ALL_USERS，则该应用将给系统中所有用户安装，否则只给指定用户安装。
安装应用实践比较长，因此不可能在一个函数中完成。上面函数把数据保存在installParams然后发送了INIT_COPY消息。

下面我们再来看看消息处理：

INIT_COPY消息的处理将绑定DefaultContainerService，因为这是一个异步的过程，要等待绑定的结果通过onServiceConnected返回，所以这里的安装参数放到了mPendingInstalls列表中。如果这个Service以前就绑定好了，现在就不需要再绑定，安装信息也会先放到mPendingInstalls。如果有多个安装请求同时到达，这里通过mPendingInstalls列表对他们进行排队。如果列表中只有一项，说明没有更多的安装请求，因此这种情况下回立即发出MCS_BOUND消息。而onServiceConnected方法同样是发出MCS_BOUND消息：

看下MCS_BOUND的消息处理

如果结束了我们看看MCS_UNBIND消息的处理

MCS_UNBIND消息的处理，如果处理的时候发现mPendingInstalls又有数据了，还是发送MCS_BOUND消息继续安装，否则断开和DefaultContainerService的连接，安装结束。
下面我们看执行安装的函数startCopy：

handleStartCopy和copyApk代码就不分析了。

handleStartCopy函数先通过DefaultContainerService调用了getMinimallPackageInfo来确定安装位置是否有足够的空间，并在PackageInfoLite对象的recommendedIntallLocation记录错误原因。发现空间不够，会调用installer的freecache方法来释放一部分空间。

再接下来handleStartCopy有很长一段都在处理apk的校验，这个校验过程是通过发送Intent ACTION_PACKAGE_NEEDS_VERIFICATION给系统中所有接受该Intent的应用来完成。如果无需校验，直接调用InstallArgs对象的copyApk方法。

而copyApk方法同样是调用DefaultContainerService的copyPackage将应用的文件复制到/data/app下，如果还有native动态库，也会把包在apk文件中的动态库提取出来。

执行完copyApk后，应用安装到了data/app目录下了。

3.2 装载应用

接下来是第二阶段的工作，把应用的格式装换成oat格式，为应用创建数据目录。最后把应用信息装载进PackageManagerService的数据结构中。

接着上面startCopy方法最后会调用handleReturnCode方法，代码如下：

我们继续看下processPendingInstall函数。

processPendingInstall方法post了一个消息，这样安装过程以异步的方式继续执行。在post消息的处理中，首先调用installPackageLI来装载应用，然后很大的代码在执行备份，备份是通过BackupManagerService来完成的。备份完成后，通过发送POST_INSTALL消息来继续处理。而这个消息的处理主要就是在发送广播，应用安装完成后要通知系统中其他的应用开始处理，比如Launcher中需要增加应用的图标等。

我们来分析下installPackageLI方法：

这里先调用parsePackage解析apk文件，这个之前分析过，我们就不再分析了。

继续分析processPendingInstall函数

继续分析

继续分析

下面我们分析下installNewPackageLI函数

这里和上篇博客分析扫描apk文件类似，我们来看下这个函数scanPackageLI

scanPackageLI函数主要调用了scanPackageDirtyLI函数，这个函数前面分析过了就不分析了。

我们再来看下在processPendingInstall函数中调用完installPackageLI函数之后，发送了一个POST_INSTALL消息，我们来看下这个消息的处理

这样安装应用的流程就讲完了。