android apk安装过程源码解析

*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布

前言：

前一篇博客分析了一下PackageManagerService是如何解析apk的以及我们如何解析未安装apk中的androidManifest.xml文件。解析完肯定要安装的，索性写一篇关于android系统是如何安装我们apk的流程分析。不过这里仅仅只分析java层面的代码，C层方面的就跳过了。

apk安装起始点-Pm.java run()

apk安装java层的起始位置是在Pm.java的run()中。

这里有2个重点，第一个红框可以看到与我们的PackageManagerService有关，获取PackageManagerService的binder对象，与PackageManagerService进行通信。并且如果这个对象为null 则输出异常信息直接返回，其实也不难理解，PackageManagerService把我们的apk给扫描了，那安装应该也会在其中。所以这里可以肯定的是apk的安装实现就在我们的PackageManagerService中；第二点就是根据这个install标识来执行安装的方法了。那我们就进入到runInstall()中来看下，它的内部是调用了PackageManagerService的什么方法来进行apk安装的。

runInstall()

从上面的runInstall()方法的代码可以看到 有3个标红框的地方需要了解，第一个obs对象，用于接收PackageManagerService安装结果，其实从第三个红框就一目了然的了解INSTALL_SUCCEEDED，安装成功！就输出Success；第二个红框就是通过binder来调起PackageManagerService中的installPackageWithVerificationAndEncryption（）方法。

那接下来看下PackageManagerService中的installPackageWithVerificationAndEncryption()方法是如何操作的

这个方法代码并不是很多，重点在最后一部分，通过handler发送一个INIT_COPY的消息，消息的内容是一个InstallParams对象。(这里要注意下InstallParams,等下会说下这个)

那我们就只要找到handleMessage中处理这个INIT_COPY的消息代码就行了

这里值得一提的是，安装apk的操作还需要一个服务，只有这个服务被bind了，才行进行下一步的工作，也就是通过handler继续发送一个消息。(这个服务是com.android.defcontainer.DefaultContainerService这里就不深层次分析了,它的作用就是用来解析APK，以及获取推荐安装路径的，安装的路径与内存情况以及一些标识来决定)

绕来绕去，开启服务之后又发送了一个消息，那只好继续看下这个MCS_BOUND消息是如何处理的。

MCS_BOUND:

从代码中就能明显看到，这里又对服务进行了一次判断，是否已经连接，所以这个服务于我们的apk安装是共存的，其中mPendingInstalls就是用于存储需要安装的请求，只有当这个队列为空时才断开连接。(在INIT_COPY消息处理中被添加到mPendingInstalls中的)，然后又调用了HandlerParams的startCopy()方法执行安装。

可以看到以下几个重点

1.HandlerParams是个抽象类

2.箭头那可以知道，这个安装会尝试4次，超过4次就GG了

3.执行handleStartCopy()方法

4.执行handleReturnCode()方法

在这之前值得一提的是前面installPackageWithVerificationAndEncryption()方法中通过handler发送消息，消息的内容是InstallParams，而InstallParams又是继承自HandlerParams这个抽象类，所以具体执行的是handleStartCopy()与handleReturnCode()的是InstallParams。

不过InstallParams这个方法的代码很长，这里大致说下，InstallParams的handleStartCopy()的主要内容是通过com.android.defcontainer.DefaultContainerService来获取apk的推荐安装路径，通过这个路径来确定是内部安装还是SD卡安装，并且在这个方法的末尾，根据路径来创建不同的InstallArgs,分别是FileInstallArgs/SdInstallArgs执行各自的copyApk()方法！

这里就从FileInstallArgs的copyApk()这条路线来分析。

FileInstallArgs.copyApk()

这个方法的重点部分就在红框位置，它的作用就是把我们的APK给复制到/data/app下，这个的路径可以通过context.getPackageCodePath()获取到，命名规则一般都是XXX.base.apk，不过这里是个临时文件，在安装的时候会对其进行改名操作。

到这就分析完了InstallParams的handleStartCopy()方法，还有一个重点部分是handleReturnCode方法，所以接着分析handleReturnCode()；

handleReturnCode()：

这里很简单，调用了processPendingInstall()方法

processPendingInstall()：

这里分为两部分：

第一张图可以看到标红框部分执行了doPreInstall()和installPackageLI(),doPostInstall();

doPreInstall和doPostInstall内部很简单，他的作用就是把我们安装过程中的临时文件删除，installPackageLI就是我们的正真安装操作。

第二张图则是安装之后，发送一个POST_INTALL消息，告诉系统是否安装完毕。

一系列的安装流程终于走到最后了，看下最终的install操作的方法

installPackageLI：

下面两个红框可以看到，分别通过两种不同的方式进行安装，具体的判断逻辑是根据包名来判断的，如果存在包名则是覆盖安装，而不存在就是安装一个新的apk。replacePackageLI()和installNewPackageLI()内部就和扫描系统中的package信息一样，如果不了解的，可以看下我这篇博客android 解析未安装apk中的AndroidManifest.xml以及系统源码分析  它把APK进行扫描，然后把apk中的信息存储到PackageManagerService中。了解4大组件的启动过程就会知道，有一段流程是在PackageManagerService中获取四大组件信息，这些信息就是通过把我们apk扫描安装然后存储到PackageMangerService中的。这样我们的apk就已经安装完成了。

图中还有一个红框，args.doRename()方法（这个args就是我们的FileInstallArgs），前面提到过我们的apk文件会被复制到/data/app下，当复制进来的时候命名格式不是xx.apk，而这里的doRename()方法就是把这个复制进来的文件改名成XXXbase.apk。所以我们context.getPackageCodePath()获取到的路径就是改名后的信息。

APK安装的源码分析就分析到这，大致的流程就是获取我们的安装位置，然后复制我们的apk文件到特定目录，然后安装我们的apk把apk的信息存储到PackageManagerService中。跟着上面的代码走一遍，相信还是很好理解的。