android 安装系统级服务,Android PKMS服务

它的作用？

关于PKMS的全称是啥应该咱们不陌生，PackageManagerService，和AMS一样是Android系统的核心服务，它主要负责系统中Package的管理，应用程序的安装、卸载、信息查询等工作。几乎每个实际项目都会使用它，最典型的就是APP的更新安装。

服务何时启动？

那PKMS是在何时进行的启动了，其实是在SystemServer.main()中进行的，下面来直接看一下源码，其源码还是基于8.0，如下：

然后在它的run()方法中看一下启动细节，看核心：

然后接下来就启动各种服务了：

那么问题来了？PKMS服务的启动是在哪个方法中来执行的呢？咱先先来看第一个启动引导服务方法：

接下来就可以看到启动AMS服务了，也就是上次咱们所析的，这里再来回顾一下：

接下来还有一系列系统服务的启动，如：PowerManagerService：

DisplayManagerService：

好，接下来我们想要的答案的代码来了：

由于已经看到了咱们所要看到的服务的启动，对于其它2个启动服务的方法就暂且不看了，得集中精力分析我们想分析的PKMS，免得精力分散了：

好，咱们来分析一下PKMS的main()方法，既然在注册它时调用了它：

上面来将其整个PKMS启动的流程用图来表述一下：

然后最后将其注册到ServiceManager当中：

好，既然构造了PKMS，那下面来看一下它里面的构造细节。

构造方法：

该构造方法代码量很大：

700多行。。当然也只能顺着核心流程来分析喽，其实分为如下五个阶段。

第一阶段：

构造函数在第一阶段的工作，主要是扫描并解析 ，XML 文件，将其中的信息保存到特定的数据结构中。看下代码：

第二阶段：

该阶段主要是扫描系统文件。

1、创建/system的子目录，比如/system/framework、system/priv-app和/system/app等等。

瞅下代码：

2、扫描系统文件，比如/vendor/overlay、/system/framework、/system/app等等目录下的文件，对扫描到的系统文件做后续处理。

其中：

/system/frameworks：该目录中的文件都是系统库，例如：framework.jar、services.jar、framework-res.apk。不过 scanDirLI 只扫描APK文件，所以 framework-res.apk 是该目录中唯一“受宠”的文件。

该目录下全是默认的系统应用，例如：Browser.apk、SettingsProvider.apk 等。

/vendor/app：该目录中的文件由厂商提供，即厂商特定的 APK 文件，不过目前市面上的厂商都把自己的应用放在 /system/app 目录下。

瞅下代码：

第三阶段：

它是属于扫描data分区阶段，扫描/data/app和/data/app-private目录下的文件：

，具体细节为：

1、遍历possiblyDeletedUpdatedSystemApps列表，如果这个系统App的包信息不在PMS的变量mPackages中，说明是残留的App信息，后续会删除它的数据。说明是存在于Data分区，不属于系统App，那么移除其系统权限。

看下代码：

其中可以看到是利用PackageParser.Package来对包进行扫描的：

咱们点进去看一下大概扫描的细节：

然后看一下它里面定义的成员变量，就知道它的大概作用了：

也就是会扫描manifest文件，然后将其扫描的信息存储到对应的集合当中了。

2、遍历mExpectingBetter列表，根据系统App所在的目录设置扫描的解析参数，内部会将packageName对应的包设置数据(PackageSetting)添加到mSettings的mPackages中。扫描系统App的升级包，最后清除mExpectingBetter列表。

看下代码：

第四阶段：

扫描结束阶段主要是做了以下事情：

1、如果当前平台SDK版本和上次启动时的SDK版本不同，重新更新APK的授权;

2、如果是第一次启动或者是Android M升级后的第一次启动，需要初始化所有用户定义的默认首选App;

3、OTA升级后的第一次启动，会清除代码缓存目录。

4、把Settings的内容保存到packages.xml中，这样此后PMS再次创建时会读到此前保存的Settings的内容。

第五阶段：

此时就进入了准备安装的阶段了：

以上五个阶段走完之后，咱们再来完善之前的图：

installd进程：

我们在之前分析PKMS服务启动时知道在它之前会创建一个这样的服务：

而它是运行在installd进程中的，看一下Installer.java类的注释：

那么该进程是何时启动的呢？这里就得从开机到app启动的流程进行梳理一下，其创建结点这在其中，下面来梳理一下：

也就是installd 是由 Android 系统的 init 进程(pid=1)，在解析 init.rc 文件的如下代码块时，通过 fork 创建的用户空间的守护进程 installd，

而该进程的代码对应于这样cpp：

而installd 是随着系统启动过程中 main class 而启动的，并启动InstalldNativeService服务发布到native层的ServiceManager中，通过IPC机制跟上层的 installer服务进行交互。下面来看一下它的main入口函数：

然后咱们再来跟到InstalldNativeService.cpp中来看一下它启动的细节：

而它里面都是跟一些app的操作相关的服务，大致瞅一下提供的函数：

系统内置应用程序安装app：

对于应用的安装我们在应用时会这样来写：

咱们接下来就来分析一下它的整个安装过程，最终就是会用到PKMS来进行安装，先贴一张整个安装的流程图：

下面根据上面的流程来看一下具体的代码，对于上面的调用安装是最终会到PackageInstallerActivity这个界面上来，也就是安装确定界面，这个是大家再熟悉不过的了，下面打开看一下这个类的源码：

然后在onCreate()的最后会有一句这个代码：

判断是否是未知来源的应用，如果开启允许安装未知来源选项则直接初始化安装，这个在实际咱们在安装时也是经常会出现的，此时就需要到设置里去把未知来源勾选一下就可以正常安装了，好下面再来看一下检测方法：

好，下面直接来看一下直接安装的方法：

然后具体UI的细节就不看了，直接看到用户点了“安装”的事件：

此时就会跳到安装中的InstallInstalling的Acitivity界面了，跟进去看一下细节：

然后在安装后台线程中看一下真正执行安装的逻辑：

此时就转到PackageInstaller.Session.commit()方法来瞅一下：

而它的具体实现类则为PackageInstallerSession.java，所以看一下它的细节：

此时看一下这个消息处理逻辑：

而mPm就是PKMS：

所以又转到PKMS.installStage()方法中来瞅一下，最终的执行是通过消息处理：

最终的安装就会还是用installer服务来进行安装，也就是对于安装是底层来完成的。也就是这块：