微信公众号可以做微网站,山西建设执业注册管理中心网站,高端行业网站建设,汉中定制网站建设公司前言#xff1a;前一篇博客分析了一下PackageManagerService是如何解析apk的以及我们如何解析未安装apk中的androidManifest.xml文件。解析完肯定要安装的#xff0c;索性写一篇关于android系统是如何安装我们apk的流程分析。不过这里仅仅只分析java层面的代码#xff0c;C层…前言前一篇博客分析了一下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信息一样 它把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中。跟着上面的代码走一遍相信还是很好理解的。
