摘要:PackageManagerService是Android系统核心服务之一,在Android中的非常重要,主要负责APK、jar包等的管理。
阅读本文大约需要花费50分钟。
文章的内容主要还是从源码进行分析,虽然又臭又长,但是如果想要学习Android系统源码,这是必要走的路,没有捷径。
相对于碎片学习,我更倾向于静下心来花费1个小时认真的学习一段内容。
文章首发微信公众号:IngresGe
专注于Android系统级源码分析,Android的平台设计,欢迎关注我,谢谢!
欢迎关注我的公众号!
[Android取经之路] 的源码都基于Android-Q(10.0) 进行分析
[Android取经之路] 系列文章:
《系统启动篇》
- Android系统架构
- Android是怎么启动的
- Android 10.0系统启动之init进程
- Android10.0系统启动之Zygote进程
- Android 10.0 系统启动之SystemServer进程
- Android 10.0 系统服务之ActivityMnagerService
- Android10.0系统启动之Launcher(桌面)启动流程
- Android10.0应用进程创建过程以及Zygote的fork流程
- Android 10.0 PackageManagerService(一)工作原理及启动流程
- Android 10.0 PackageManagerService(二)权限扫描
- Android 10.0 PackageManagerService(三)APK扫描
- Android 10.0 PackageManagerService(四)APK安装流程
《日志系统篇》
- Android10.0 日志系统分析(一)-logd、logcat 指令说明、分类和属性
- Android10.0 日志系统分析(二)-logd、logcat架构分析及日志系统初始化
- Android10.0 日志系统分析(三)-logd、logcat读写日志源码分析
- Android10.0 日志系统分析(四)-selinux、kernel日志在logd中的实现
《PackageManagerService系列文章》
- Android 10.0 PackageManagerService(一)工作原理及启动流程
- Android 10.0 PackageManagerService(二)权限扫描
- Android 10.0 PackageManagerService(三)APK扫描
- Android 10.0 PackageManagerService(四)APK安装流程
《Binder通信原理》
- Android10.0 Binder通信原理(一)Binder、HwBinder、VndBinder概要
- Android10.0 Binder通信原理(二)-Binder入门篇
- Android10.0 Binder通信原理(三)-ServiceManager篇
- Android10.0 Binder通信原理(四)-Native-CC++实例分析
- Android10.0 Binder通信原理(五)-Binder驱动分析
- Android10.0 Binder通信原理(六)-Binder数据如何完成定向打击
- Android10.0 Binder通信原理(七)-Framework binder示例
- Android10.0 Binder通信原理(八)-Framework层分析
- Android10.0 Binder通信原理(九)-AIDL Binder示例
- Android10.0 Binder通信原理(十)-AIDL原理分析-Proxy-Stub设计模式
- Android10.0 Binder通信原理(十一)-Binder总结
《HwBinder通信原理》
- HwBinder入门篇-Android10.0 HwBinder通信原理(一)
- HIDL详解-Android10.0 HwBinder通信原理(二)
- HIDL示例-C++服务创建Client验证-Android10.0 HwBinder通信原理(三)
- HIDL示例-JAVA服务创建-Client验证-Android10.0 HwBinder通信原理(四)
- HwServiceManager篇-Android10.0 HwBinder通信原理(五)
- Native层HIDL服务的注册原理-Android10.0 HwBinder通信原理(六)
- Native层HIDL服务的获取原理-Android10.0 HwBinder通信原理(七)
- JAVA层HIDL服务的注册原理-Android10.0 HwBinder通信原理(八)
- JAVA层HIDL服务的获取原理-Android10.0 HwBinder通信原理(九)
- HwBinder驱动篇-Android10.0 HwBinder通信原理(十)
- HwBinder原理总结-Android10.0 HwBinder通信原理(十一)
《编译原理》
- 编译系统入门篇-Android10.0编译系统(一)
- 编译环境初始化-Android10.0编译系统(二)
- make编译过程-Android10.0编译系统(三)
- Image打包流程-Android10.0编译系统(四)
- Kati详解-Android10.0编译系统(五)
PackageManagerService是Android系统核心服务之一,在Android中的非常重要,主要负责的功能如下:
-
解析 AndroidManifest.xml,主要包括AndroidManifest中节点信息的解析和target-name的分析和提炼
-
扫描本地文件,主要针对apk,主要是系统应用、本地安装应用等等。这部分会在下面仔细讲解。
-
管理本地apk,主要包括安装、删除等等。
下面称PackageManagerService为PKMS。
扫描APK的AndroidManifest.xml中的各个标签信息,
例如"application"、"overlay"、"permission"、"uses-permission"等信息。
再针对各个标签的子标签进程扫描,
例如application会扫描"activity"、"receiver"、"service"、"provider"等信息
后面会详细讲解扫描过程
PKMS服务由SystemServer进行启动,在SystemServer中startBootstrapServices()启动PKMS服务,再调用startOtherServices()进行dex优化,磁盘管理等功能,并让PKMS进入systemready状态。
启动调用栈如下图所示:
4.1.1 [SystemServer.java] startBootstrapServices()
说明:startBootstrapServices()首先启动Installer服务,也就是安装器,随后判断当前的设备是否处于加密状态,如果是则只是解析核心应用,接着调用PackageManagerService的静态方法main来创建pms对象
(1)启动Installer服务
(2)获取设备是否加密(手机设置密码),如果设备加密了,则只解析"core"应用
(3)调用PKMS main方法初始化PackageManagerService,其中调用PackageManagerService()构造函数创建了PKMS对象
(4)如果设备没有加密,操作它。管理A/B OTA dexopting。
源码:
4.1.2 [SystemServer.java]
startOtherServices()
说明:
(5)执行 updatePackagesIfNeeded ,完成dex优化;
(6)执行 performFstrimIfNeeded ,完成磁盘维护;
(7)调用systemReady,准备就绪。
源码:
4.1.3 [PackageManagerService.java] main()
说明:
main函数主要工作:
(1)检查Package编译相关系统属性
(2)调用PackageManagerService构造方法
(3)启用部分应用服务于多用户场景
(4)往ServiceManager中注册”package”和”package_native”。
源码:
PKMS初始化时的核心部分为PackageManagerService()构造函数的内容,我们下面就来分析该流程
4.2 PKMS构造函数分析
PKMS的构造函数中由两个重要的锁(mInstallLock、mPackages) 和5个阶段构成,下面会详细的来分析这些内容。
mInstallLock :用来保护所有安装apk的访问权限,此操作通常涉及繁重的磁盘数据读写等操作,并且是单线程操作,故有时候会处理很慢。
此锁不会在已经持有mPackages锁的情况下火的,反之,在已经持有mInstallLock锁的情况下,立即获取mPackages是安全的
mPackages:用来解析内存中所有apk的package信息及相关状态。
5个阶段:
阶段1:BOOT_PROGRESS_PMS_START
阶段2:BOOT_PROGRESS_PMS_SYSTEM_SCAN_START
阶段3:BOOT_PROGRESS_PMS_DATA_SCAN_START
阶段4:BOOT_PROGRESS_PMS_SCAN_END
阶段5:BOOT_PROGRESS_PMS_READY
PKMS服务也是通过binder进行通信,IPackageManager.aidl由工具转换后自动生成binder的服务端IPackageManager.Stub和客户端IPackageManager.Stub.Proxy,具体关系如图:
Binder服务端:PackageManagerService继承于IPackageManager.Stub;
Binder客户端:ApplicationPackageManager(简称APM)的成员变量mPM继承于IPackageManager.Stub.Proxy; 本身APM是继承于PackageManager对象。
4.2.1 [PackageManagerService.java]
说明:IPackageManager.Stub是IPackageManager.aidl自动生成的,正好也说明了PKMS是service端的,通过binder交互
源码:
4.2.2 [PackageManagerService.java] PackageManagerService()
说明:PackageManagerService构造函数
源码:
4.2.3 阶段1:BOOT_PROGRESS_PMS_START
主要工作:
(1)构造 DisplayMetrics ,保存分辨率等相关信息;
(2)创建Installer对象,与installd交互;
(3)创建mPermissionManager对象,进行权限管理;
(4)构造Settings类,保存安装包信息,清除路径不存在的孤立应用,主要涉及/data/system/目录的packages.xml,packages-backup.xml,packages.list,packages-stopped.xml,packages-stopped-backup.xml等文件。
(5)构造PackageDexOptimizer及DexManager类,处理dex优化;
(6)创建SystemConfig实例,获取系统配置信息,配置共享lib库;
(7)创建PackageManager的handler线程,循环处理外部安装相关消息。
源码:
readLPw()会扫描下面5个文件
1) "/data/system/packages.xml"
2) "/data/system/packages-backup.xml"
3) "/data/system/packages.list"
4) "/data/system/packages-stopped.xml"
5) "/data/system/packages-stopped-backup.xml"
个文件共分为三组,简单的作用描述如下:
-
packages.xml:PKMS 扫描完目标文件夹后会创建该文件。当系统进行程序安装、卸载和更新等操作时,均会更新该文件。该文件保存了系统中与 package 相关的一些信息。
-
packages.list:描述系统中存在的所有非系统自带的 APK 的信息。当这些程序有变动时,PKMS 就会更新该文件。
-
packages-stopped.xml:从系统自带的设置程序中进入应用程序页面,然后在选择强制停止(ForceStop)某个应用时,系统会将该应用的相关信息记录到此文件中。也就是该文件保存系统中被用户强制停止的 Package 的信息。
这些目录的指向,都在Settings中的构造函数完成, 如下所示,得到目录后调用readLPw()进行扫描
解析上面这个几个xml的内容,建立对应的数据结构
说明:创建 SharedUserSetting 对象并添加到 Settings 的成员变量 mSharedUsers 中,在 Android 系统中,多个 package 通过设置 sharedUserId 属性可以运行在同一个进程,共享同一个 UID
源码:
4.2.4 阶段2:BOOT_PROGRESS_PMS_SYSTEM_SCAN_START
主要工作:
(1)从init.rc中获取环境变量BOOTCLASSPATH和SYSTEMSERVERCLASSPATH;
(2)对于旧版本升级的情况,将安装时获取权限变更为运行时申请权限;
(3)扫描system/vendor/product/odm/oem等目录的priv-app、app、overlay包;
(4)清除安装时临时文件以及其他不必要的信息。
源码:
4.2.5 阶段3:BOOT_PROGRESS_PMS_DATA_SCAN_START
主要工作有:对于不仅仅解析核心应用的情况下,还处理data目录的应用信息,及时更新,祛除不必要的数据。
源码:
4.2.6 阶段4:BOOT_PROGRESS_PMS_SCAN_END
主要工作:
(1)sdk版本变更,更新权限;
(2)OTA升级后首次启动,清除不必要的缓存数据;
(3)权限等默认项更新完后,清理相关数据;
(4)更新package.xml
源码:
4.2.7 阶段5:BOOT_PROGRESS_PMS_READY
主要工作有:
(1)创建PackageInstallerService对象
(2)GC回收内存
源码:
检查是否需要去更新Packages并进行dex优化,如果没有OTA升级、没有大版本升级、没有清楚过dalvik虚拟机的缓存,可以去更新packages,
最终调用的是Installer的dexopt()进行优化
调用栈如下:
4.3.1 [PackageManagerService.java] updatePackagesIfNeeded()
说明:
检查是否需要去更新Packages并进行dex优化,如果没有OTA升级、没有大版本升级、没有清楚过dalvik虚拟机的缓存,可以去更新packages
更新packages的优先级:core app >system app > other app,调用 performDexOptUpgrade()进行更新
源码:
4.3.2 [PackageManagerService.java] performDexOptUpgrade()
说明:判断是否需要对package进行更新,如果需要更新那么按照优先级完成dex优化,最终调用Install的dexopt()进行dex优化,参考上面的调用栈
源码:
4.4 磁盘维护
磁盘维护最终调用的是vold进程的 fstrim()进行清理操作
调用栈:
[PackageManagerService.java] performFstrimIfNeeded()
说明:主要是执行磁盘清理工作,释放磁盘空间
源码:
4.5 PKMS 准备就绪
[PackageManagerService.java] systemReady()
说明:systemReady主要完成的是默认授权和更新package的信息,通知在等待pms的一些组件
源码:
下一节将会讲解PKMS 的权限扫描、APK扫描、安装等内容,欢迎关注我
微信公众号:IngresGe