https://jeanboy.blog.csdn.net/?type=blog
概述
PackageManagerService(简称 PKMS),是 Android 系统中核心服务之一,管理着所有跟 package 相关的工作,常见的比如安装、卸载应用。
PackageManagerService 是在 SystemServer 进程中启动的。如不了解 Android 是如何从开机到 Launcher 启动的过程,请先阅读:Android - 系统启动过程。
PackageManagerService 启动
SystemServer 启动过程中涉及到的 PKMS 如下:
private void startBootstrapServices() { //启动installer服务 Installer installer = mSystemServiceManager.startService(Installer.class); ...
//处于加密状态则仅仅解析核心应用 String cryptState = SystemProperties.get("vold.decrypt"); if (ENCRYPTING_STATE.equals(cryptState)) { mOnlyCore = true; // ENCRYPTING_STATE = "trigger_restart_min_framework" } else if (ENCRYPTED_STATE.equals(cryptState)) { mOnlyCore = true; // ENCRYPTED_STATE = "1" }
//创建 PKMS 对象【1】 mPackageManagerService = PackageManagerService.main(mSystemContext, installer, mFactoryTestMode != FactoryTest.FACTORY_TEST_OFF, mOnlyCore); //PKMS是否首次启动 mFirstBoot = mPackageManagerService.isFirstBoot();
//【2】 mPackageManager = mSystemContext.getPackageManager(); //...}
private void startOtherServices() { //... //启动 MountService,后续 PackageManager 会需要使用 mSystemServiceManager.startService(MOUNT_SERVICE_CLASS); //【3】做 dex 优化。dex 是 Android 上针对 Java 字节码的一种优化技术,可提高运行效率 mPackageManagerService.performBootDexOpt(); /...
// phase 500 mSystemServiceManager.startBootPhase(SystemService.PHASE_SYSTEM_SERVICES_READY); //...
//【4】 mPackageManagerService.systemReady(); //...}整个 system_server 进程启动过程,涉及 PKMS 服务的主要几个动作如下,接下来分别讲解每个过程:
- PKMS.main()
- PKMS.performBootDexOpt()
- PKMS.systemReady()
PKMS.main()
public static PackageManagerService main(Context context, Installer installer, boolean factoryTest, boolean onlyCore) { //初始化 PKMS 对象 PackageManagerService m = new PackageManagerService(context, installer, factoryTest, onlyCore); //将 package 服务注册到 ServiceManager,这是 binder 服务的常规注册流程 ServiceManager.addService("package", m); return m;}该方法的主要功能创建 PKMS 对象,并将其注册到 ServiceManager 中,内部是一个 HashMap 的集合,存储了很多相关的 binder 服务,缓存起来,我们在使用的时候, 会通过 getService(key) 的方式去 map中获取,ServiceManger 工作流程详见:Android - Binder 机制。 关于 PKMS 对象的构造方法很长,分为以下几个阶段,每个阶段会输出相应的 EventLog。
public PackageManagerService(Context context, Installer installer, boolean factoryTest, boolean onlyCore) {
//PackageManagerService 启动开始 EventLog.writeEvent(EventLogTags.BOOT_PROGRESS_PMS_START, SystemClock.uptimeMillis()); //SDK 版本检查 if (mSdkVersion <= 0) { Slog.w(TAG, "**** ro.build.version.sdk not set!"); }
//读取开机启动模式 String mode = SystemProperties.get("ro.bootmode", "mode"); engModeEnable = "engtest".equals(mode) ? true : false; Slog.i(TAG, "engModeEnable: " + engModeEnable + " ,mode:" + mode); mContext = context; mFactoryTest = factoryTest;//开机模式 mOnlyCore = onlyCore;//是否对包做 dex 优化 //如果编译版本为 eng,则不需要 dex 优化 mNoDexOpt = "eng".equals(SystemProperties.get("ro.build.type")); //创建显示尺寸信息 mMetrics = new DisplayMetrics(); //存储系统运行过程中的设置信息 mSettings = new Settings();//【1】 /*创建 SharedUserSetting 对象并添加到 Settings 的成员变量 mSharedUsers 中, 在 Android 系统中,多个 package 通过设置 sharedUserId 属性可以运行在同一个进程,共享同一个 UID */ mSettings.addSharedUserLPw("android.uid.system", Process.SYSTEM_UID, ApplicationInfo.FLAG_SYSTEM); mSettings.addSharedUserLPw("android.uid.phone", RADIO_UID, ApplicationInfo.FLAG_SYSTEM); mSettings.addSharedUserLPw("android.uid.log", LOG_UID, ApplicationInfo.FLAG_SYSTEM); mSettings.addSharedUserLPw("android.uid.nfc", NFC_UID, ApplicationInfo.FLAG_SYSTEM); String separateProcesses = SystemProperties.get("debug.separate_processes"); if (separateProcesses != null && separateProcesses.length() > 0) { if ("*".equals(separateProcesses)) { mDefParseFlags = PackageParser.PARSE_IGNORE_PROCESSES; mSeparateProcesses = null; Slog.w(TAG, "Running with debug.separate_processes: * (ALL)"); } else { mDefParseFlags = 0; mSeparateProcesses = separateProcesses.split(","); Slog.w(TAG, "Running with debug.separate_processes: " + separateProcesses); } } else { mDefParseFlags = 0; mSeparateProcesses = null; }
mPreInstallDir = new File("/system/preloadapp"); //创建应用安装器 mInstaller = new Installer();
//获取屏幕尺寸大小 WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE); Display d = wm.getDefaultDisplay(); d.getMetrics(mMetrics); synchronized (mInstallLock) { // writer synchronized (mPackages) { //启动消息处理线程 mHandlerThread.start(); //为消息处理线程创建一个消息分发handler mHandler = new PackageHandler(mHandlerThread.getLooper()); // dataDir =/data/ File dataDir = Environment.getDataDirectory(); // mAppDataDir = /data/data mAppDataDir = new File(dataDir, "data"); // mAsecInternalPath = /data/app-asec mAsecInternalPath = new File(dataDir, "app-asec").getPath(); // mUserAppDataDir = /data/user mUserAppDataDir = new File(dataDir, "user"); // mDrmAppPrivateInstallDir = /data/app-private mDrmAppPrivateInstallDir = new File(dataDir, "app-private"); sUserManager = new UserManager(mInstaller, mUserAppDataDir); //读取并解析/etc/permissions下的XML文件 readPermissions(); mRestoredSettings = mSettings.readLPw(); long startTime = SystemClock.uptimeMillis();//【2】 } }
Runtime.getRuntime().gc(); //暴露私有服务,用于系统组件的使用 LocalServices.addService(PackageManagerInternal.class, new PackageManagerInternalImpl());}刚进入构造函数,就会遇到第一个较为复杂的数据结构 Settings 及它的 addSharedUserLPw() 函数。Settings 的作用是管理 Android 系统运行过程中的一些设置信息。到底是哪些信息呢?来看下面的分析。
Settings
先分析 addSharedUserLPw 函数。如下所示:
mSettings.addSharedUserLPw("android.uid.system",//字符串 Process.SYSTEM_UID, //系统进程使用的用户id,值为1000 ApplicationInfo.FLAG_SYSTEM//标志系统 Package);在进入对addSharedUserLPw 函数的分析前,先介绍一下 SYSTEM_UID 及相关知识。 Android 系统中 UID/GID 介绍: UID 为用户 ID 的缩写,GID 为用户组 ID 的缩写,这两个概念均与 Linux 系统中进程的权限管理有关。一般说来,每一个进程都会有一个对应的 UID(即表示该进程属于哪个 user,不同 user 有不同权限)。一个进程也可分属不同的用户组(每个用户组都有对应的权限)。 提示 Linux 的 UID/GID 还可细分为几种类型,此处我们仅考虑普适意义的 UID/GID。 下面分析 addSharedUserLPw 函数,代码如下:
SharedUserSetting addSharedUserLPw(String name, int uid, int pkgFlags) { /* 注意这里的参数:name 为字符串”android.uid.system”,uid 为 1000,pkgFlags 为 ApplicationInfo.FLAG_SYSETM (以后简写为FLAG_SYSTEM) */ //mSharedUsers 是一个 HashMap,key 为字符串,值为 SharedUserSetting 对象 SharedUserSetting s = mSharedUsers.get(name); if (s != null) { if (s.userId == uid) { return s; } //... return null; }
//创建一个新的 SharedUserSettings 对象,并设置的 userId 为 uid s = new SharedUserSetting(name, pkgFlags); s.userId = uid; if (addUserIdLPw(uid, s, name)) { mSharedUsers.put(name, s);//将name与s键值对添加到mSharedUsers中保存 return s; } return null;}从以上代码可知,Settings 中有一个 mSharedUsers 成员,该成员存储的是字符串与 SharedUserSetting 键值对,也就是说以字符串为 key 得到对应的 SharedUserSetting 对象。 那么 SharedUserSettings 是什么?它的目的是什么?来看一个例子。 该例子来源于 SystemUI 的 AndroidManifest.xml,如下所示:
<manifestxmlns:android="http://schemas.android.com/apk/res/android" package="com.android.systemui" coreApp="true" android:sharedUserId="android.uid.system" android:process="system">...在 xml 中,声明了一个名为 android
- 两个或多个声明了同一种 sharedUserIds 的 APK 可共享彼此的数据,并且可运行在同一进程中。
- 更重要的是,通过声明特定的 sharedUserId,该 APK 所在进程将被赋予指定的 UID。例如,本例中的 SystemUI 声明了 system 的 uid,运行 SystemUI 的进程就可享有 system 用户所对应的权限(实际上就是将该进程的 uid 设置为 system 的 uid)了。
提示:除了在 AndroidManifest.xml 中声明 sharedUserId 外,Apk 在编译时还必须使用对应的证书进行签名。例如,本例的 SystemUI,在其 Android.mk 中需要额外声明 LOCAL_CERTIFICATE := platform,如此,才可获得指定的 UID。 通过以上介绍,我们能了解到如何组织一种数据结构来包括上面的内容。此处有三个关键点需注意:
- XML 中 sharedUserId 属性指定了一个字符串,它是 UID 的字符串描述,故对应数据结构中也应该有这样一个字符串,这样就把代码和 XML 中的属性联系起来了。
- 在 Linux 系统中,真正的 UID 是一个整数,所以该数据结构中必然有一个整型变量。
- 多个 Package 可声明同一个 sharedUserId,因此该数据结构必然会保存那些声明了相同 sharedUserId的 Package 的某些信息。
了解了上面三个关键点,再来看 Android 是如何设计相应数据结构的,如图所示。
由上图可知:
- Settings 类定义了一个 mSharedUsers 成员,它是一个 HashMap,以字符串(如“android.uid.system”)为Key,对应的 Value 是一个 SharedUserSettings 对象。
- SharedUserSetting 派生自 GrantedPermissions 类,从 GrantedPermissions 类的命名可知,它和权限有关。SharedUserSetting 定义了一个成员变量 packages,类型为 HashSet,用于保存声明了相同 sharedUserId 的 Package 的权限设置信息。
- 每个 Package 有自己的权限设置。权限的概念由 PackageSetting 类表达。该类继承自 PackagesettingBase,而 PackageSettingBase 又继承自 GrantedPermissions。
- Settings 中还有两个成员,一个是 mUserIds,另一个是 mOtherUserIds,这两位成员的类型分别是 ArrayList 和 SparseArray。其目的是以 UID 为索引,得到对应的 SharedUserSettings 对象。在一般情况下,以索引获取数组元素的速度,比以 key 获取 HashMap 中元素的速度要快很多。
提示:根据以上对 mUserIds 和 mOtherUserIds 的描述,可知这是典型的以空间换时间的做法。 下边来分析 addUserIdLPw 函数,它的功能就是将 SharedUserSettings 对象保存到对应的数组中,代码如下:
private boolean addUserIdLPw(int uid, Object obj, Objectname) { //uid 不能超出限制。Android 对 UID 进行了分类,应用 APK 所在进程的 UID 从 10000 开始, //而系统 APK 所在进程小于 10000 if (uid >= PackageManagerService.FIRST_APPLICATION_UID + PackageManagerService.MAX_APPLICATION_UIDS) { return false; }
if (uid >= PackageManagerService.FIRST_APPLICATION_UID) { int N = mUserIds.size(); //计算索引,其值是 uid 和 FIRST_APPLICATION_UID 的差 final int index = uid - PackageManagerService.FIRST_APPLICATION_UID; while (index >= N) { mUserIds.add(null); N++; } //... //判断该索引位置的内容是否为空,为空才保存 mUserIds.set(index, obj);//mUserIds 保存应用 Package 的 UID } else { //... mOtherUserIds.put(uid, obj);//系统 Package 的 UID 由 mOtherUserIds 保存 } return true;}readPermissions()
先来分析 readPermissions 函数,从其函数名可猜测到它和权限有关,代码如下:
void readPermissions() { // 指向 /system/etc/permission 目录,该目录中存储了和设备相关的一些权限信息 FilelibraryDir = new File(Environment.getRootDirectory(), "etc/permissions"); //... for (File f : libraryDir.listFiles()) { //先处理该目录下的非platform.xml文件 if (f.getPath().endsWith("etc/permissions/platform.xml")) { continue; } //... // 调用 readPermissionFromXml 解析此 XML 文件 readPermissionsFromXml(f); }
finalFile permFile = new File(Environment.getRootDirectory(), "etc/permissions/platform.xml");
//解析 platform.xml 文件,看来该文件优先级最高 readPermissionsFromXml(permFile);}在 etc/permissions 目录下保存了一下配置文件:
函数 readPermissionsFromXml 使用 PULL 方式解析这些 XML 文件:
private void readPermissionsFromXml(File permFile) { FileReader permReader = null; try { permReader = new FileReader(permFile); } //... try { XmlPullParser parser = Xml.newPullParser(); parser.setInput(permReader); XmlUtils.beginDocument(parser, "permissions"); while (true) { //... String name = parser.getName(); //解析 group 标签,前面介绍的 XML 文件中没有单独使用该标签的地方 if ("group".equals(name)) { String gidStr = parser.getAttributeValue(null, "gid"); if (gidStr != null) { int gid = Integer.parseInt(gidStr); //转换 XML 中的 gi d字符串为整型,并保存到 mGlobalGids 中 mGlobalGids = appendInt(mGlobalGids, gid); } //... } else if ("permission".equals(name)) {//解析 permission 标签 String perm = parser.getAttributeValue(null, "name"); //... perm = perm.intern(); //调用 readPermission 处理 readPermission(parser, perm); } else if ("assign-permission".equals(name)) {//下面解析的是assign-permission标签 String perm = parser.getAttributeValue(null, "name"); //... String uidStr = parser.getAttributeValue(null, "uid"); //... //如果是 assign-permission,则取出 uid 字符串,然后获得 Linux 平台上 //的整型 uid 值 int uid = Process.getUidForName(uidStr); //... perm = perm.intern(); //和 assign 相关的信息保存在 mSystemPermissions 中 HashSet<String> perms = mSystemPermissions.get(uid); if (perms == null) { perms = newHashSet < String > (); mSystemPermissions.put(uid, perms); } perms.add(perm); //... } else if ("library".equals(name)) {//解析 library 标签 String lname = parser.getAttributeValue(null, "name"); String lfile = parser.getAttributeValue(null, "file"); if (lname == null) { //... } else if (lfile == null) { //... } else { //将 XML 中的 name 和 library 属性值存储到 mSharedLibraries 中 mSharedLibraries.put(lname, lfile); } //... } else if ("feature".equals(name)) {//解析 feature 标签 String fname = parser.getAttributeValue(null, "name"); //... { //在 XML 中定义的 feature 由 FeatureInfo 表达 FeatureInfo fi = newFeatureInfo(); fi.name = fname; //存储 feature 名和对应的 FeatureInfo 到 mAvailableFeatures 中 mAvailableFeatures.put(fname, fi); }//... } //... } //... }}readPermissions 函数就是将 XML 中的标签转换成对应的数据结构。
readLPw()
readLPw 函数的功能也是解析文件,不过这些文件的内容却是在 PKMS 正常启动后生成的。
Settings() { FiledataDir = Environment.getDataDirectory(); FilesystemDir = new File(dataDir, "system");//指向/data/system目录 systemDir.mkdirs();//创建该目录 //... /* 一共有 5 个文件,packages.xml 和 packages-backup.xml 为一组,用于描述系统中 所安装的 Package 的信息,其中 backup 是临时文件。PKMS 先把数据写到 backup 中, 信息都写成功后再改名成非 backup 的文件。其目的是防止在写文件过程中出错,导致信息丢失。
packages-stopped.xml 和 packages-stopped-backup.xml 为一组,用于描述系统中 强制停止运行的 pakcage 的信息,backup 也是临时文件。如果此处存在该临时文件,表明 此前系统因为某种原因中断了正常流程 packages.list 列出当前系统中应用级(即UID大于10000)Package 的信息 */ mSettingsFilename = new File(systemDir, "packages.xml"); mBackupSettingsFilename = new File(systemDir, "packages-backup.xml"); mPackageListFilename = new File(systemDir, "packages.list"); mStoppedPackagesFilename = new File(systemDir, "packages-stopped.xml"); mBackupStoppedPackagesFilename = new File(systemDir, "packages-stopped-backup.xml");}上面 5 个文件共分为三组,这里简单介绍一下这些文件的来历(不考虑临时的 backup 文件)。
- packages.xml: PKMS 扫描完目标文件夹后会创建该文件。当系统进行程序安装、卸载和更新等操作时,均会更新该文件。该文件保存了系统中与 package 相关的一些信息。
- packages.list:描述系统中存在的所有非系统自带的 APK 的信息。当这些程序有变动时,PKMS 就会更新该文件。
- packages-stopped.xml:从系统自带的设置程序中进入应用程序页面,然后在选择强制停止(ForceStop)某个应用时,系统会将该应用的相关信息记录到此文件中。也就是该文件保存系统中被用户强制停止的 Package 的信息。
readLPw 的函数功能就是解析其中的 XML 文件的内容,然后建立并更新对应的数据结构。例如,停止的 package 重启之后依然是 stopped 状态。
第一阶段总结
PKMS 构造函数在第一阶段的工作,主要是扫描并解析 XML 文件,将其中的信息保存到特定的数据结构中。 第一阶段扫描的 XML 文件与权限及上一次扫描得到的 Package 信息有关,它为 PKMS 下一阶段的工作提供了重要的参考信息。
扫描 Package
PKMS 构造函数第二阶段的工作就是扫描系统中的 APK 了。由于需要逐个扫描文件,因此手机上装的程序越多,PKMS 的工作量越大,系统启动速度也就越慢。
//...mRestoredSettings = mSettings.readLPw();//接第一段的结尾longstartTime = SystemClock.uptimeMillis();//记录扫描开始的时间//定义扫描参数intscanMode = SCAN_MONITOR | SCAN_NO_PATHS | SCAN_DEFER_DEX;if (mNoDexOpt) { scanMode |= SCAN_NO_DEX; //在控制扫描过程中是否对 APK 文件进行 dex 优化}finalHashSet<String> libFiles = new HashSet<String>();// mFrameworkDir指向/system/frameworks目录mFrameworkDir = newFile(Environment.getRootDirectory(), "framework");// mDalvikCacheDir指向/data/dalvik-cache目录mDalvikCacheDir = new File(dataDir, "dalvik-cache");booleandidDexOpt = false;/* 获取 Java 启动类库的路径,在 init.rc 文件中通过 BOOTCLASSPATH 环境变量输出,该值如下 /system/framework/core.jar:/system/frameworks/core-junit.jar: /system/frameworks/bouncycastle.jar:/system/frameworks/ext.jar: /system/frameworks/framework.jar:/system/frameworks/android.policy.jar: /system/frameworks/services.jar:/system/frameworks/apache-xml.jar: /system/frameworks/filterfw.jar 该变量指明了 framework 所有核心库及文件位置 */StringbootClassPath = System.getProperty("java.boot.class.path");if (bootClassPath != null) { String[] paths = splitString(bootClassPath, ':'); for (int i = 0; i < paths.length; i++) { try { //判断该 jar 包是否需要重新做 dex 优化 if (dalvik.system.DexFile.isDexOptNeeded(paths[i])) { /* 将该 jar 包文件路径保存到 libFiles 中,然后通过 mInstall 对象发送 命令给 installd,让其对该 jar 包进行 dex 优化 */ libFiles.add(paths[i]); mInstaller.dexopt(paths[i], Process.SYSTEM_UID, true); didDexOpt = true; } } //... }}//.../*还记得 mSharedLibrarires 的作用吗?它保存的是 platform.xml 中声明的系统库的信息。这里也要判断系统库是否需要做 dex 优化。处理方式同上*/if (mSharedLibraries.size() > 0) { //...}//将 framework-res.apk 添加到 libFiles 中。framework-res.apk 定义了系统常用的//资源,还有几个重要的 Activity,如长按 Power 键后弹出的选择框libFiles.add(mFrameworkDir.getPath() + "/framework-res.apk");//列举 /system/frameworks 目录中的文件String[] frameworkFiles = mFrameworkDir.list();if (frameworkFiles != null) { //... // 判断该目录下的 apk 或 jar 文件是否需要做 dex 优化。处理方式同上}/*上面代码对系统库(BOOTCLASSPATH 指定,或 platform.xml 定义,或/system/frameworks目录下的 jar 包与 apk 文件)进行一次仔细检查,该优化的一定要优化。如果发现期间对任何一个文件进行了优化,则设置 didDexOpt 为 true*/if (didDexOpt) { String[] files = mDalvikCacheDir.list(); if (files != null) { /* 如果前面对任意一个系统库重新做过 dex 优化,就需要删除 cache 文件。原因和 dalvik 虚拟机的运行机制有关。暂不探讨 dex 及 cache 文件的作用。 从删除 cache 文件这个操作来看,这些 cache 文件应该使用了 dex 优化后的系统库 所以当系统库重新做 dex 优化后,就需要删除旧的 cache 文件。可简单理解为缓存失效 */ for (int i = 0; i < files.length; i++) { String fn = files[i]; if (fn.startsWith("data@app@") || fn.startsWith("data@app-private@")) { (newFile(mDalvikCacheDir, fn)).delete(); //... } } }}清空 cache 文件后,PKMS 终于进入重点段了。接下来看 PKMS 第二阶段工作的核心内容,即扫描 Package。
//创建文件夹监控对象,监视 /system/frameworks 目录。利用了 Linux 平台的 notify 机制mFrameworkInstallObserver = new AppDirObserver(mFrameworkDir.getPath(), OBSERVER_EVENTS, true);mFrameworkInstallObserver.startWatching();
/* 调用 scanDirLI 函数扫描 /system/frameworks 目录,这个函数很重要,稍后会再分析。 注意,在第三个参数中设置了SCAN_NO_DEX标志,因为该目录下的package在前面的流程 中已经过判断并根据需要做过dex优化了 */scanDirLI(mFrameworkDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode | SCAN_NO_DEX, 0);//创建文件夹监控对象,监视 /system/app 目录mSystemAppDir = new File(Environment.getRootDirectory(), "app");mSystemInstallObserver = new AppDirObserver(mSystemAppDir.getPath(), OBSERVER_EVENTS, true);mSystemInstallObserver.startWatching();
//扫描 /system/app 下的 packagescanDirLI(mSystemAppDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode, 0);
//监视并扫描 /vendor/app 目录mVendorAppDir = new File("/vendor/app");mVendorInstallObserver = new AppDirObserver(mVendorAppDir.getPath(), OBSERVER_EVENTS, true);mVendorInstallObserver.startWatching();
//扫描 /vendor/app 下的 packagescanDirLI(mVendorAppDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode, 0);
//和 installd 交互。以后单独分析 installdmInstaller.moveFiles();由以上代码可知,PKMS 将扫描以下几个目录。
- /system/frameworks:该目录中的文件都是系统库,例如:framework.jar、services.jar、framework-res.apk。不过 scanDirLI 只扫描APK文件,所以 framework-res.apk 是该目录中唯一“受宠”的文件。
- /system/app:该目录下全是默认的系统应用,例如:Browser.apk、SettingsProvider.apk 等。
- /vendor/app:该目录中的文件由厂商提供,即厂商特定的 APK 文件,不过目前市面上的厂商都把自己的应用放在 /system/app 目录下。
PKMS 调用 scanDirLI 函数进行扫描,下面来分析此函数。
private void scanDirLI(File dir, int flags, int scanMode, long currentTime) { String[] files = dir.list();//列举该目录下的文件 //... int i; for (i = 0; i < files.length; i++) { File file = new File(dir, files[i]); if (!isPackageFilename(files[i])) { continue; //根据文件名后缀,判断是否为APK 文件。这里只扫描APK 文件 }
/* 调用scanPackageLI函数扫描一个特定的文件,返回值是PackageParser的内部类 Package,该类的实例代表一个APK文件,所以它就是和APK文件对应的数据结构 */ PackageParser.Package pkg = scanPackageLI(file, flags | PackageParser.PARSE_MUST_BE_APK, scanMode, currentTime); if (pkg == null && (flags & PackageParser.PARSE_IS_SYSTEM) == 0 && mLastScanError == PackageManager.INSTALL_FAILED_INVALID_APK) { //注意此处flags的作用,只有非系统Package扫描失败,才会删除该文件 file.delete(); } }}接着来分析 scanPackageLI 函数。PKMS 中有两个同名的 scanPackageLI 函数,后面会一一见到。先来看第一个也是最先碰到的 scanPackageLI 函数。
scanPackageLI()
首次相遇的 scanPackageLI 函数的代码如下:
private PackageParser.Package scanPackageLI(FilescanFile, int parseFlags, int scanMode, long currentTime) { mLastScanError = PackageManager.INSTALL_SUCCEEDED; StringscanPath = scanFile.getPath(); parseFlags |= mDefParseFlags;//默认的扫描标志,正常情况下为0
//创建一个 PackageParser 对象 PackageParser pp = new PackageParser(scanPath); pp.setSeparateProcesses(mSeparateProcesses);// mSeparateProcesses 为空 pp.setOnlyCoreApps(mOnlyCore);// mOnlyCore 为 false
/* 调用 PackageParser 的 parsePackage 函数解析APK文件。注意,这里把代表屏幕 信息的 mMetrics 对象也传了进去 */ finalPackageParser.Package pkg = pp.parsePackage(scanFile, scanPath, mMetrics, parseFlags); //... PackageSetting ps = null; PackageSetting updatedPkg; //...
/* 这里略去一大段代码,主要是关于 Package 升级方面的工作。 */ //收集签名信息,这部分内容涉及 signature。 if (!collectCertificatesLI(pp, ps, pkg, scanFile, parseFlags)) return null;
//判断是否需要设置 PARSE_FORWARD_LOCK 标志,这个标志针对资源文件和 Class 文件 //不在同一个目录的情况。目前只有 /vendor/app 目录下的扫描会使用该标志。这里不讨论 //这种情况。 if (ps != null && !ps.codePath.equals(ps.resourcePath)) parseFlags |= PackageParser.PARSE_FORWARD_LOCK;
String codePath = null; String resPath = null; if ((parseFlags & PackageParser.PARSE_FORWARD_LOCK) != 0) { //...//这里不考虑 PARSE_FORWARD_LOCK的情况。 } else { resPath = pkg.mScanPath; }
codePath = pkg.mScanPath;//mScanPath 指向该 APK 文件所在位置 //设置文件路径信息,codePath 和 resPath 都指向 APK 文件所在位置 setApplicationInfoPaths(pkg, codePath, resPath);
//调用第二个 scanPackageLI 函数 return scanPackageLI(pkg, parseFlags, scanMode | SCAN_UPDATE_SIGNATURE, currentTime);}scanPackageLI 函数首先调用 PackageParser 对 APK 文件进行解析。根据前面的介绍可知,PackageParser 完成了从物理文件到对应数据结构的转换。下面来分析这个 PackageParser。
PackageParser
PackageParser 主要负责 APK 文件的解析,即解析 APK 文件中的 AndroidManifest.xml 代码如下:
public Package parsePackage(File sourceFile, String destCodePath, DisplayMetrics metrics, int flags) { mParseError = PackageManager.INSTALL_SUCCEEDED; mArchiveSourcePath = sourceFile.getPath(); //...//检查是否为 APK 文件 XmlResourceParser parser = null; AssetManager assmgr = null; Resources res = null; boolean assetError = true; try { assmgr = new AssetManager(); int cookie = assmgr.addAssetPath(mArchiveSourcePath); if (cookie != 0) { res = new Resources(assmgr, metrics, null); assmgr.setConfiguration(0, 0, null, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, Build.VERSION.RESOURCES_SDK_INT); /* 获得一个 XML 资源解析对象,该对象解析的是 APK 中的 AndroidManifest.xml 文件。 以后再讨论 AssetManager、Resource 及相关的知识 */ parser = assmgr.openXmlResourceParser(cookie, ANDROID_MANIFEST_FILENAME); assetError = false; } //...//出错处理 String[] errorText = new String[1]; Package pkg = null; Exception errorException = null; try { //调用另外一个 parsePackage 函数 pkg = parsePackage(res, parser, flags, errorText); }//...
//...//错误处理 parser.close(); assmgr.close(); //保存文件路径,都指向 APK 文件所在的路径 pkg.mPath = destCodePath; pkg.mScanPath = mArchiveSourcePath; pkg.mSignatures = null; return pkg; }}以上代码中调用了另一个同名的 parsePackage 函数,此函数内容较长,但功能单一,就是解析 AndroidManifest.xml 中的各种标签,这里只提取其中相关的代码:
private Package parsePackage(Resources res, XmlResourceParser parser, int flags, String[] outError) throws XmlPullParserException, IOException { AttributeSet attrs = parser; mParseInstrumentationArgs = null; mParseActivityArgs = null; mParseServiceArgs = null; mParseProviderArgs = null; //得到 Package 的名字,其实就是得到 AndroidManifest.xml 中 package 属性的值, //每个 APK 都必须定义该属性 String pkgName = parsePackageName(parser, attrs, flags, outError); //... int type; //... //以 pkgName 名字为参数,创建一个 Package 对象。后面的工作就是解析 XML 并填充 //该 Package 信息 final Package pkg = new Package(pkgName); boolean foundApp = false; //...//下面开始解析该文件中的标签,由于这段代码功能简单,所以这里仅列举相关函数 while (如果解析未完成) { //... StringtagName = parser.getName(); //得到标签名 if (tagName.equals("application")) { //...//解析 application 标签 parseApplication(pkg, res, parser, attrs, flags, outError); } else if (tagName.equals("permission-group")) { //...//解析 permission-group 标签 parsePermissionGroup(pkg, res, parser, attrs, outError); } else if (tagName.equals("permission")) { //...//解析 permission 标签 parsePermission(pkg, res, parser, attrs, outError); } else if (tagName.equals("uses-permission")) { //从 XML 文件中获取 uses-permission 标签的属性 sa = res.obtainAttributes(attrs, com.android.internal.R.styleable.AndroidManifestUsesPermission); //取出属性值,也就是对应的权限使用声明 String name = sa.getNonResourceString(com.android.internal. R.styleable.AndroidManifestUsesPermission_name); //添加到 Package 的 requestedPermissions 数组 if (name != null && !pkg.requestedPermissions.contains(name)) { pkg.requestedPermissions.add(name.intern()); } } else if (tagName.equals("uses-configuration")) { /* 该标签用于指明本 package 对硬件的一些设置参数,目前主要针对输入设备(触摸屏、键盘 等)。游戏类的应用可能对此有特殊要求。 */ ConfigurationInfocPref = new ConfigurationInfo(); //...//解析该标签所支持的各种属性 pkg.configPreferences.add(cPref);//保存到 Package 的 configPreferences 数组 } //...//对其他标签解析和处理 }}上面代码展示了 AndroidManifest.xml 解析的流程,其中比较重要的函数是 parserApplication,它用于解析 application 标签及其子标签(Android 的四大组件在 application 标签中已声明)。
PackageParser 及其内部重要成员的信息。

- PackageParser 定了相当多的内部类,这些内部类的作用就是保存对应的信息。解析 AndroidManifest.xml 文件得到的信息由 Package 保存。从该类的成员变量可看出,和 Android 四大组件相关的信息分别由 activites、receivers、providers、services 保存。由于一个 APK 可声明多个组件,因此 activites 和 receiver s等均声明为 ArrayList。
- 以 PackageParser.Activity 为例,它从 Component 派生。Component 是一个模板类,元素类型是 ActivityIntentInfo,此类的顶层基类是 IntentFilter。PackageParser.Activity 内部有一个 ActivityInfo 类型的成员变量,该变量保存的就是四大组件中 Activity 的信息。细心的读者可能会有疑问,为什么不直接使用 ActivityInfo,而是通过 IntentFilter 构造出一个使用模板的复杂类型 PackageParser.Activity 呢?原来,Package 除了保存信息外,还需要支持 Intent 匹配查询。例如,设置 Intent 的 Action 为某个特定值,然后查找匹配该 Intent 的 Activity。由于 ActivityIntentInfo 是从 IntentFilter 派生的,因此它它能判断自己是否满足该 Intent 的要求,如果满足,则返回对应的 ActivityInfo。
- PackageParser 定了一个轻量级的数据结构 PackageLite,该类仅存储 Package 的一些简单信息。我们在介绍 Package 安装的时候,会遇到 PackageLite。
在 PackageParser 扫描完一个 APK 后,此时系统已经根据该 APK 中 AndroidManifest.xml,创建了一个完整的 Package 对象,下一步就是将该 Package 加入到系统中。此时调用的函数就是另外一个 scanPackageLI,其代码如下:
private PackageParser.PackagescanPackageLI( PackageParser.Package pkg, int parseFlags, int scanMode, long currentTime) { FilescanFile = new File(pkg.mScanPath); //... mScanningPath = scanFile; //设置 package 对象中 applicationInfo 的 flags 标签,用于标示该 Package 为系统 //Package if ((parseFlags & PackageParser.PARSE_IS_SYSTEM) != 0) { pkg.applicationInfo.flags |= ApplicationInfo.FLAG_SYSTEM; }
//下面这句 if 判断极为重要,见下面的解释 if (pkg.packageName.equals("android")) { synchronized (mPackages) { if (mAndroidApplication != null) { //...
mPlatformPackage = pkg; pkg.mVersionCode = mSdkVersion; mAndroidApplication = pkg.applicationInfo; mResolveActivity.applicationInfo = mAndroidApplication; mResolveActivity.name = ResolverActivity.class.getName(); mResolveActivity.packageName = mAndroidApplication.packageName; mResolveActivity.processName = mAndroidApplication.processName; mResolveActivity.launchMode = ActivityInfo.LAUNCH_MULTIPLE; mResolveActivity.flags = ActivityInfo.FLAG_EXCLUDE_FROM_RECENTS; mResolveActivity.theme = com.android.internal.R.style.Theme_Holo_Dialog_Alert; mResolveActivity.exported = true; mResolveActivity.enabled = true; //mResoveInfo 的 activityInfo 成员指向 mResolveActivity mResolveInfo.activityInfo = mResolveActivity; mResolveInfo.priority = 0; mResolveInfo.preferredOrder = 0; mResolveInfo.match = 0; mResolveComponentName = new ComponentName( mAndroidApplication.packageName, mResolveActivity.name); } } }}刚进入 scanPackageLI 函数,我们就发现了一个极为重要的内容,即单独判断并处理 packageName 为 android 的 Package。和该 Package 对应的APK是 framework-res.apk,有图为证。
framework-res.apk 的 AndroidManifest.xml:
实际上,framework-res.apk 还包含了以下几个常用的 Activity。
- ChooserActivity:当多个 Activity 符合某个 Intent 的时候,系统会弹出此 Activity,由用户选择合适的应用来处理。
- RingtonePickerActivity:铃声选择 Activity。
- ShutdownActivity:关机前弹出的选择对话框。
由前述知识可知,该 Package 和系统息息相关,因此它得到了 PKMS 的特别青睐,主要体现在以下几点。
- mPlatformPackage 成员用于保存该 Package 信息。
- mAndroidApplication 用于保存此 Package 中的 ApplicationInfo。
- mResolveActivity 指向用于表示 ChooserActivity 信息的 ActivityInfo。
- mResolveInfo 为 ResolveInfo 类型,它用于存储系统解析 Intent(经 IntentFilter 的过滤)后得到的结果信息,例如:满足某个 Intent 的 Activity 的信息。由前面的代码可知,mResolveInfo 的 activityInfo 其实指向的就是 mResolveActivity。
注意:在从 PKMS 中查询满足某个 Intent 的 Activity 时,返回的就是 ResolveInfo,再根据 ResolveInfo 的信息得到具体的 Activity。 此处保存这些信息,主要是为了提高运行过程中的效率。Goolge工 程师可能觉得 ChooserActivity 使用的地方比较多,所以这里单独保存了此 Activity 的信息。
//...//mPackages 用于保存系统内的所有 Package,以 packageName 为 keyif (mPackages.containsKey(pkg.packageName) || mSharedLibraries.containsKey(pkg.packageName)) { return null;}
File destCodeFile = newFile(pkg.applicationInfo.sourceDir);FiledestResourceFile = new File(pkg.applicationInfo.publicSourceDir);SharedUserSettingsuid = null;//代表该 Package 的 SharedUserSetting 对象PackageSetting pkgSetting = null;//代表该 Package 的 PackageSetting 对象synchronized (mPackages) { //...//此段代码大约有300行左右,主要做了以下几方面工作 /* 1. 如果该 Package 声明了”uses-libraries” 话,那么系统要判断该 library 是否在 mSharedLibraries 中 2. 如果 package 声明了 SharedUser,则需要处理 SharedUserSettings 相关内容,由 Settings 的 getSharedUserLPw 函数处理 3. 处理 pkgSetting,通过调用 Settings 的 getPackageLPw 函数完成 4. 调用 verifySignaturesLP 函数,检查该 Package 的 signature */}final long scanFileTime = scanFile.lastModified();final boolean forceDex = (scanMode & SCAN_FORCE_DEX) != 0;//确定运行该 package 的进程的进程名,一般用 packageName 作为进程名pkg.applicationInfo.processName = fixProcessName( pkg.applicationInfo.packageName, pkg.applicationInfo.processName, pkg.applicationInfo.uid);
if (mPlatformPackage == pkg) { dataPath = new File(Environment.getDataDirectory(), "system"); pkg.applicationInfo.dataDir = dataPath.getPath();} else { /* getDataPathForPackage 函数返回该 package 的目录,一般是 /data/data/packageName/ */ dataPath = getDataPathForPackage(pkg.packageName, 0); if (dataPath.exists()) { //...//如果该目录已经存在,则要处理 uid 的问题 } else { //...//向 installd 发送 install 命令,实际上就是在 /data/data 下 //建立 packageName 目录。后续将分析 installd 相关知识 int ret = mInstaller.install(pkgName, pkg.applicationInfo.uid, pkg.applicationInfo.uid); //为系统所有 user 安装此程序 mUserManager.installPackageForAllUsers(pkgName, pkg.applicationInfo.uid); if (dataPath.exists()) { pkg.applicationInfo.dataDir = dataPath.getPath(); } //...
if (pkg.applicationInfo.nativeLibraryDir == null && pkg.applicationInfo.dataDir != null) { //...//为该 Package 确定 native library 所在目录 //一般是 /data/data/packagename/lib } }
//如果该 APK 包含了 native 动态库,则需要将它们从 APK 文件中解压并复制到对应目录中 if (pkg.applicationInfo.nativeLibraryDir != null) { try { final File nativeLibraryDir = new File(pkg.applicationInfo.nativeLibraryDir); final String dataPathString = dataPath.getCanonicalPath();
//从 2.3 开始,系统 package 的 native 库统一放在 /system/lib 下。所以 //系统不会提取系统 Package 目录下 APK 包中的 native 库 if (isSystemApp(pkg) && !isUpdatedSystemApp(pkg)) { NativeLibraryHelper.removeNativeBinariesFromDirLI( nativeLibraryDir)){ } else if (nativeLibraryDir.getParentFile().getCanonicalPath() .equals(dataPathString)) { boolean isSymLink; try { isSymLink = S_ISLNK(Libcore.os.lstat( nativeLibraryDir.getPath()).st_mode);
} //...//判断是否为链接,如果是,需要删除该链接 if (isSymLink) { mInstaller.unlinkNativeLibraryDirectory(dataPathString); }
//在 lib 下建立和 CPU 类型对应的目录,例如 ARM 平台的是 arm/,MIPS 平台的是 mips/ NativeLibraryHelper.copyNativeBinariesIfNeededLI(scanFile, nativeLibraryDir); } else { mInstaller.linkNativeLibraryDirectory(dataPathString, pkg.applicationInfo.nativeLibraryDir); } } //... } pkg.mScanPath = path; if ((scanMode & SCAN_NO_DEX) == 0) { //...//对该 APK 做 dex 优化 performDexOptLI(pkg, forceDex, (scanMode & SCAN_DEFER_DEX); } //如果该 APK 已经存在,要先杀掉运行该 APK 的进程 if ((parseFlags & PackageManager.INSTALL_REPLACE_EXISTING) != 0) { killApplication(pkg.applicationInfo.packageName, pkg.applicationInfo.uid); } //... /* 在此之前,四大组件信息都属于 Package 的私有财产,现在需要把它们登记注册到 PKMS 内部的 财产管理对象中。这样,PKMS 就可对外提供统一的组件信息,而不必拘泥于具体的 Package */ synchronized (mPackages) { if ((scanMode & SCAN_MONITOR) != 0) { mAppDirs.put(pkg.mPath, pkg); } mSettings.insertPackageSettingLPw(pkgSetting, pkg); mPackages.put(pkg.applicationInfo.packageName, pkg); //处理该 Package 中的 Provider 信息 int N = pkg.providers.size(); int i; for (i = 0; i < N; i++) { PackageParser.Providerp = pkg.providers.get(i); p.info.processName = fixProcessName( pkg.applicationInfo.processName, p.info.processName, pkg.applicationInfo.uid); //mProvidersByComponent 提供基于 ComponentName 的 Provider 信息查询 mProvidersByComponent.put(new ComponentName( //... } //处理该 Package 中的 Service 信息 N = pkg.services.size(); r = null; for (i = 0; i < N; i++) { PackageParser.Service s = pkg.services.get(i); mServices.addService(s); } //处理该 Package 中的 BroadcastReceiver 信息 N = pkg.receivers.size(); r = null; for (i = 0; i < N; i++) { PackageParser.Activity a = pkg.receivers.get(i); mReceivers.addActivity(a, "receiver"); //... } //处理该 Package 中的 Activity 信息 N = pkg.activities.size(); r = null; for (i = 0; i < N; i++) { PackageParser.Activity a = pkg.activities.get(i); mActivities.addActivity(a, "activity"); } //处理该 Package 中的 PermissionGroups 信息 N = pkg.permissionGroups.size(); //...//permissionGroups 处理 N = pkg.permissions.size(); //...//permissions 处理 N = pkg.instrumentation.size(); //...//instrumentation 处理 if (pkg.protectedBroadcasts != null) { N = pkg.protectedBroadcasts.size(); for (i = 0; i < N; i++) { mProtectedBroadcasts.add(pkg.protectedBroadcasts.get(i)); } } //...//Package 的私有财产终于完成了公有化改造 return pkg; } }}scanPackageLI() 总结
扫描非系统 Package,非系统 Package 就是指那些不存储在系统目录下的 APK 文件,这部分代码如下:
if (!mOnlyCore) {//mOnlyCore 用于控制是否扫描非系统 Package Iterator<PackageSetting> psit = mSettings.mPackages.values().iterator();
while (psit.hasNext()) { //...//删除系统package中那些不存在的APK }
mAppInstallDir = new File(dataDir, "app"); //...//删除安装不成功的文件及临时文件 if (!mOnlyCore) { //在普通模式下,还需要扫描 /data/app 以及 /data/app_private 目录 mAppInstallObserver = new AppDirObserver( mAppInstallDir.getPath(), OBSERVER_EVENTS, false); mAppInstallObserver.startWatching(); scanDirLI(mAppInstallDir, 0, scanMode, 0); mDrmAppInstallObserver = newAppDirObserver( mDrmAppPrivateInstallDir.getPath(), OBSERVER_EVENTS, false); mDrmAppInstallObserver.startWatching(); scanDirLI(mDrmAppPrivateInstallDir, PackageParser.PARSE_FORWARD_LOCK, scanMode, 0); } else { mAppInstallObserver = null; mDrmAppInstallObserver = null; }}结合前述代码,这里总结几个存放APK文件的目录。
- 系统 Package 目录包括:/system/frameworks、/system/app 和 /vendor/app。
- 非系统 Package 目录包括:/data/app、/data/app-private。
第二阶段总结
PKMS 构造函数第二阶段的工作任务非常繁重,要创建比较多的对象,所以它是一个耗时耗内存的操作。在工作中,我们一直想优化该流程以加快启动速度,例如:延时扫描不重要的 APK,或者保存 Package 信息到文件中,然后在启动时从文件中恢复这些信息以减少 APK 文件读取并解析 XML 的工作量。但是一直没有一个比较完满的解决方案,原因有很多。比如:APK 之间有着比较微妙的依赖关系,因此到底延时扫描哪些 APK,尚不能确定。
构造函数扫尾工作
下面分析 PKMS 第三阶段的工作,这部分任务比较简单,就是将第二阶段收集的信息再集中整理一次,比如将有些信息保存到文件中,相关代码如下:
mSettings.mInternalSdkPlatform= mSdkVersion;
//汇总并更新和 Permission 相关的信息 updatePermissionsLPw(null, null, true, regrantPermissions,regrantPermissions);
//将信息写到 package.xml、package.list 及 package-stopped.xml 文件中 mSettings.writeLPr(); Runtime.getRuntime().gc(); mRequiredVerifierPackage= getRequiredVerifierLPr(); //...//PKMS 构造函数返回}从流程角度看,PKMS 构造函数的功能还算清晰,无非是扫描 XML 或 APK 文件,但是其中涉及的数据结构及它们之间的关系却较为复杂。这里有一些建议供读者参考:
- 理解 PKMS 构造函数工作的三个阶段及其各阶段的工作职责。
- 了解 PKMS 第二阶段工作中解析 APK 文件的几个关键步骤。
- 了解重点数据结构的名字和大体功能。
获取 PackageManager 服务
ContextImpl.java
public PackageManager getPackageManager() { if (mPackageManager != null) { return mPackageManager; } //见下面分析 IPackageManager pm = ActivityThread.getPackageManager(); if (pm != null) { //创建 ApplicationPackageManager 对象 return (mPackageManager = new ApplicationPackageManager(this, pm)); } return null;}获取 PKMS 服务,并创建 ApplicationPackageManager 对象。 ActivityThread.java
public static IPackageManager getPackageManager() { if (sPackageManager != null) { return sPackageManager; } IBinder b = ServiceManager.getService("package"); sPackageManager = IPackageManager.Stub.asInterface(b); return sPackageManager;}与 ServiceManager 通讯获取到 PKMS 的代理对象。
PKMS.performBootDexOpt()
PackageManagerService.java
public void performBootDexOpt() { // 确保只有 system 或者 root uid 有权限执行该方法 enforceSystemOrRoot("Only the system can request dexopt be performed");
//运行在同一个进程,此处拿到的 MountService 的服务端 IMountService ms = PackageHelper.getMountService(); if (ms != null) { final boolean isUpgrade = isUpgrade(); //处于更新状态,则执行fstrim boolean doTrim = isUpgrade; if (doTrim) { Slog.w(TAG, "Running disk maintenance immediately due to system update"); } else { //interval 默认值为 3 天 final long interval = android.provider.Settings.Global.getLong( mContext.getContentResolver(), android.provider.Settings.Global.FSTRIM_MANDATORY_INTERVAL, DEFAULT_MANDATORY_FSTRIM_INTERVAL); if (interval > 0) { final long timeSinceLast = System.currentTimeMillis() - ms.lastMaintenance(); if (timeSinceLast > interval) { doTrim = true; //距离上次 fstrim 时间超过 3 天,则执行 fstrim } } } //此处 ms 是指 MountService,该过程发送消息 H_FSTRIM 给 handler,然后再向 vold 发送 fstrim 命令 if (doTrim) { ms.runMaintenance(); } }
final ArraySet<PackageParser.Package> pkgs; synchronized (mPackages) { //清空延迟执行 dexopt 操作的 app,获取 dexopt 操作的 app 集合 pkgs = mPackageDexOptimizer.clearDeferredDexOptPackages(); }
if (pkgs != null) { ArrayList<PackageParser.Package> sortedPkgs = new ArrayList<PackageParser.Package>();
for (Iterator<PackageParser.Package> it = pkgs.iterator(); it.hasNext();) { PackageParser.Package pkg = it.next(); //将 pkgs 中的核心 app 添加到 sortedPkgs if (pkg.coreApp) { sortedPkgs.add(pkg); it.remove(); } }
//获取监听 PRE_BOOT_COMPLETE 的系统 app 集合 Intent intent = new Intent(Intent.ACTION_PRE_BOOT_COMPLETED); ArraySet<String> pkgNames = getPackageNamesForIntent(intent);
for (Iterator<PackageParser.Package> it = pkgs.iterator(); it.hasNext();) { PackageParser.Package pkg = it.next(); //将 pkg 中监听 PRE_BOOT_COMPLETE 的 app 添加到 sortedPkgs if (pkgNames.contains(pkg.packageName)) { sortedPkgs.add(pkg); it.remove(); } }
//获取 pkgs 中最近一周使用过的 app,详见下面 filterRecentlyUsedApps(pkgs);
//将最近一周的 app 添加到 sortedPkgs for (PackageParser.Package pkg : pkgs) { sortedPkgs.add(pkg); }
if (mLazyDexOpt) { filterRecentlyUsedApps(sortedPkgs); }
int i = 0; int total = sortedPkgs.size(); File dataDir = Environment.getDataDirectory(); long lowThreshold = StorageManager.from(mContext).getStorageLowBytes(dataDir); ...
for (PackageParser.Package pkg : sortedPkgs) { long usableSpace = dataDir.getUsableSpace(); if (usableSpace < lowThreshold) { break; } //详见下面 performBootDexOpt(pkg, ++i, total); } }}
private void filterRecentlyUsedApps(Collection<PackageParser.Package> pkgs) {
if (mLazyDexOpt || (!isFirstBoot() && mPackageUsage.isHistoricalPackageUsageAvailable())) { int total = pkgs.size(); int skipped = 0; long now = System.currentTimeMillis(); for (Iterator<PackageParser.Package> i = pkgs.iterator(); i.hasNext();) { PackageParser.Package pkg = i.next(); // 过滤出最近使用过的 app long then = pkg.mLastPackageUsageTimeInMills; if (then + mDexOptLRUThresholdInMills < now) { i.remove(); skipped++; } } }}
private void performBootDexOpt(PackageParser.Package pkg, int curr, int total) { if (!isFirstBoot()) { ActivityManagerNative.getDefault().showBootMessage( mContext.getResources().getString(R.string.android_upgrading_apk, curr, total), true); } PackageParser.Package p = pkg; synchronized (mInstallLock) { mPackageDexOptimizer.performDexOpt(p, null /* instruction sets */, false /* force dex */, false /* defer */, true /* include dependencies */, false /* boot complete */, false /*useJit*/); }}PKMS.systemReady()
PackageManagerService.java
public void systemReady() { mSystemReady = true; ...
synchronized (mPackages) { ArrayList<PreferredActivity> removed = new ArrayList<PreferredActivity>(); for (int i=0; i<mSettings.mPreferredActivities.size(); i++) { PreferredIntentResolver pir = mSettings.mPreferredActivities.valueAt(i); removed.clear(); for (PreferredActivity pa : pir.filterSet()) { if (mActivities.mActivities.get(pa.mPref.mComponent) == null) { removed.add(pa); } } if (removed.size() > 0) { for (int r=0; r<removed.size(); r++) { PreferredActivity pa = removed.get(r); pir.removeFilter(pa); } mSettings.writePackageRestrictionsLPr( mSettings.mPreferredActivities.keyAt(i)); } }
for (int userId : UserManagerService.getInstance().getUserIds()) { if (!mSettings.areDefaultRuntimePermissionsGrantedLPr(userId)) { grantPermissionsUserIds = ArrayUtils.appendInt( grantPermissionsUserIds, userId); } } }
sUserManager.systemReady(); //多用户服务
//升级所有已获取的默认权限 for (int userId : grantPermissionsUserIds) { mDefaultPermissionPolicy.grantDefaultPermissions(userId); }
//处理所有等待系统准备就绪的消息 if (mPostSystemReadyMessages != null) { for (Message msg : mPostSystemReadyMessages) { msg.sendToTarget(); } mPostSystemReadyMessages = null; }
//观察外部存储设备 final StorageManager storage = mContext.getSystemService(StorageManager.class); storage.registerListener(mStorageListener);
mInstallerService.systemReady(); mPackageDexOptimizer.systemReady();
MountServiceInternal mountServiceInternal = LocalServices.getService(MountServiceInternal.class); mountServiceInternal.addExternalStoragePolicy(...);}PackageManagerService 启动完整流程图:

installd
PackageManagerServie 服务负责应用的安装、卸载等相关工作,而真正干活的还是 installd。 其中 PKMS 执行权限为 system,而进程 installd 的执行权限为 root。
启动
installd 是由 Android 系统的 init 进程(pid=1),在解析 init.rc 文件的如下代码块时,通过 fork 创建的用户空间的守护进程 installd。
service installd /system/bin/installd class main socket installd stream 600 system systeminstalld 是随着系统启动过程中 main class 而启动的,并且会创建一个 socket 套接字,用于跟上层的 PKMS 进行交互。 installd 的启动入口 frameworks/base/cmds/installd/installd.c 的 main() 方法,接下来从这里开始说起。 installd.cpp
int main(const int argc __unused, char *argv[]) { char buf[BUFFER_MAX]; //buffer大小为1024Byte struct sockaddr addr; socklen_t alen; int lsocket, s; //...
//初始化全局信息【1】 if (initialize_globals() < 0) { exit(1); }
//初始化相关目录【2】 if (initialize_directories() < 0) { exit(1); }
//获取套接字"installd" lsocket = android_get_control_socket(SOCKET_PATH);
if (listen(lsocket, 5)) { //监听socket消息 exit(1); } fcntl(lsocket, F_SETFD, FD_CLOEXEC);
for (;;) { alen = sizeof(addr); s = accept(lsocket, &addr, &alen); //接受socket消息 if (s < 0) { continue; } fcntl(s, F_SETFD, FD_CLOEXEC);
for (;;) { unsigned short count; //读取指令的长度 if (readx(s, &count, sizeof(count))) { break; } if ((count < 1) || (count >= BUFFER_MAX)) { break; } //读取指令的内容 if (readx(s, buf, count)) { break; } buf[count] = 0; //... //执行指令【3】 if (execute(s, buf)) break; } close(s); } return 0;}installd.cpp -> initialize_globals
int initialize_globals() { // 数据目录/data/ if (get_path_from_env(&android_data_dir, "ANDROID_DATA") < 0) { return -1; }
// app目录/data/app/ if (copy_and_append(&android_app_dir, &android_data_dir, APP_SUBDIR) < 0) { return -1; }
// 受保护的app目录/data/priv-app/ if (copy_and_append(&android_app_private_dir, &android_data_dir, PRIVATE_APP_SUBDIR) < 0) { return -1; }
// app本地库目录/data/app-lib/ if (copy_and_append(&android_app_lib_dir, &android_data_dir, APP_LIB_SUBDIR) < 0) { return -1; }
// sdcard挂载点/mnt/asec if (get_path_from_env(&android_asec_dir, "ASEC_MOUNTPOINT") < 0) { return -1; }
// 多媒体目录/data/media if (copy_and_append(&android_media_dir, &android_data_dir, MEDIA_SUBDIR) < 0) { return -1; }
// 外部app目录/mnt/expand if (get_path_from_string(&android_mnt_expand_dir, "/mnt/expand/") < 0) { return -1; }
// 系统和厂商目录 android_system_dirs.count = 4;
android_system_dirs.dirs = (dir_rec_t*) calloc(android_system_dirs.count, sizeof(dir_rec_t)); //... dir_rec_t android_root_dir; // 目录/system if (get_path_from_env(&android_root_dir, "ANDROID_ROOT") < 0) { return -1; }
// 目录/system/app android_system_dirs.dirs[0].path = build_string2(android_root_dir.path, APP_SUBDIR); android_system_dirs.dirs[0].len = strlen(android_system_dirs.dirs[0].path);
// 目录/system/app-lib android_system_dirs.dirs[1].path = build_string2(android_root_dir.path, PRIV_APP_SUBDIR); android_system_dirs.dirs[1].len = strlen(android_system_dirs.dirs[1].path);
// 目录/vendor/app/ android_system_dirs.dirs[2].path = strdup("/vendor/app/"); android_system_dirs.dirs[2].len = strlen(android_system_dirs.dirs[2].path);
// 目录/oem/app/ android_system_dirs.dirs[3].path = strdup("/oem/app/"); android_system_dirs.dirs[3].len = strlen(android_system_dirs.dirs[3].path);
return 0;}installd.cpp -> initialize_directories
int initialize_directories() { int res = -1;
//读取当前文件系统版本 char version_path[PATH_MAX]; snprintf(version_path, PATH_MAX, "%s.layout_version", android_data_dir.path);
int oldVersion; if (fs_read_atomic_int(version_path, &oldVersion) == -1) { oldVersion = 0; } int version = oldVersion;
// 目录/data/user char *user_data_dir = build_string2(android_data_dir.path, SECONDARY_USER_PREFIX); // 目录/data/data char *legacy_data_dir = build_string2(android_data_dir.path, PRIMARY_USER_PREFIX); // 目录/data/user/0 char *primary_data_dir = build_string3(android_data_dir.path, SECONDARY_USER_PREFIX, "0"); //... //将/data/user/0链接到/data/data if (access(primary_data_dir, R_OK) < 0) { if (symlink(legacy_data_dir, primary_data_dir)) { goto fail; } } //... //处理data/media 相关 return res;}installd.cpp -> execute
static int execute(int s, char cmd[BUFFER_MAX]) { char reply[REPLY_MAX]; char *arg[TOKEN_MAX+1]; unsigned i; unsigned n = 0; unsigned short count; int ret = -1; reply[0] = 0;
arg[0] = cmd; while (*cmd) { if (isspace(*cmd)) { *cmd++ = 0; n++; arg[n] = cmd; if (n == TOKEN_MAX) { goto done; } } if (*cmd) { cmd++; //计算参数个数 } }
for (i = 0; i < sizeof(cmds) / sizeof(cmds[0]); i++) { if (!strcmp(cmds[i].name,arg[0])) { if (n != cmds[i].numargs) { //参数个数不匹配,直接返回 ALOGE("%s requires %d arguments (%d given)\n", cmds[i].name, cmds[i].numargs, n); } else { //执行相应的命令[见小节2.5] ret = cmds[i].func(arg + 1, reply); } goto done; } }
done: if (reply[0]) { n = snprintf(cmd, BUFFER_MAX, "%d %s", ret, reply); } else { n = snprintf(cmd, BUFFER_MAX, "%d", ret); } if (n > BUFFER_MAX) n = BUFFER_MAX; count = n;
//将命令执行后的返回值写入socket套接字 if (writex(s, &count, sizeof(count))) return -1; if (writex(s, cmd, count)) return -1; return 0;}Installer
当守护进程 installd 启动完成后,上层 framework 便可以通过 socket 跟该守护进程进行通信。 在 SystemServer 启动服务的过程中创建 Installer 对象,便会有一次跟 installd 通信的过程。 SystemServer.java
private void startBootstrapServices() { //启动 installer 服务 Installer installer = mSystemServiceManager.startService(Installer.class); //...}Installer.java
public Installer(Context context) { super(context); //创建 InstallerConnection 对象 mInstaller = new InstallerConnection();}
public void onStart() { Slog.i(TAG, "Waiting for installd to be ready."); mInstaller.waitForConnection();}先创建 Installer 对象,再调用 onStart() 方法,该方法中主要工作是等待 socket 通道建立完成。 InstallerConnection.java
public void waitForConnection() { for (;;) { if (execute("ping") >= 0) { return; } Slog.w(TAG, "installd not ready"); SystemClock.sleep(1000); }}
public int execute(String cmd) { String res = transact(cmd); try { return Integer.parseInt(res); } catch (NumberFormatException ex) { return -1; }}
public synchronized String transact(String cmd) { if (!connect()) { return "-1"; }
if (!writeCommand(cmd)) { if (!connect() || !writeCommand(cmd)) { return "-1"; } }
//读取应答消息 final int replyLength = readReply(); if (replyLength > 0) { String s = new String(buf, 0, replyLength); return s; } else { return "-1"; }}
private boolean connect() { if (mSocket != null) { return true; } Slog.i(TAG, "connecting..."); try { mSocket = new LocalSocket();
LocalSocketAddress address = new LocalSocketAddress("installd", LocalSocketAddress.Namespace.RESERVED);
mSocket.connect(address);
mIn = mSocket.getInputStream(); mOut = mSocket.getOutputStream(); } catch (IOException ex) { disconnect(); return false; } return true;}
private boolean writeCommand(String cmdString) { final byte[] cmd = cmdString.getBytes(); final int len = cmd.length; if ((len < 1) || (len > buf.length)) { return false; }
buf[0] = (byte) (len & 0xff); buf[1] = (byte) ((len >> 8) & 0xff); try { mOut.write(buf, 0, 2); //写入长度 mOut.write(cmd, 0, len); //写入具体命令 } catch (IOException ex) { disconnect(); return false; } return true;}
private int readReply() { if (!readFully(buf, 2)) { return -1; }
final int len = (((int) buf[0]) & 0xff) | ((((int) buf[1]) & 0xff) << 8); if ((len < 1) || (len > buf.length)) { disconnect(); return -1; }
if (!readFully(buf, len)) { return -1; }
return len;}
private boolean readFully(byte[] buffer, int len) { try { Streams.readFully(mIn, buffer, 0, len); } catch (IOException ioe) { disconnect(); return false; } return true; }可见,一次 transact 过程为先 connect() 来判断是否建立 socket 连接,如果已连接则通过 writeCommand() 将命令写入 socket 的 mOut 管道,等待从管道的 mIn 中 readFully() 读取应答消息。
Apk 安装过程分析
adb install 分析
adb install 有多个参数,这里仅考虑最简单的,如: adb install frameworktest.apk。adb 是一个命令,install 是它的参数。此处直接跳到处理 install 参数的代码: commandline.c
int adb_commandline(int argc, char **argv){ //... if(!strcmp(argv[0], "install")) { //... //调用 install_app 函数处理 return install_app(ttype, serial, argc, argv); } //...}
int install_app(transport_type transport, char*serial, int argc, char** argv){ //要安装的APK现在还在Host机器上,要先把APK复制到手机中。 //这里需要设置复制目标的目录,如果安装在内部存储中,则目标目录为/data/local/tmp; //如果安装在SD卡上,则目标目录为/sdcard/tmp。 static const char *const DATA_DEST = "/data/local/tmp/%s"; static const char *const SD_DEST = "/sdcard/tmp/%s"; const char* where = DATA_DEST; char apk_dest[PATH_MAX]; char verification_dest[PATH_MAX]; char *apk_file; char *verification_file = NULL; int file_arg = -1; int err int i;
for (i =1; i < argc; i++) { if(*argv[i] != '-') { file_arg = i break; } else if (!strcmp(argv[i], "-i")) { i++; } else if (!strcmp(argv[i], "-s")) { where = SD_DEST; //-s参数指明该APK安装到SD卡 } } //... apk_file = argv[file_arg]; //... //获取目标文件的全路径,如果安装在内部存储中,则目标全路径为/data/local/tmp/安装包名, //调用do_sync_push将此APK传送到手机的目标路径 err = do_sync_push(apk_file, apk_dest, 1 /* verify APK */); //... //执行 pm 命令【1】
pm_command(transport,serial, argc, argv); //... cleanup_apk:
//在手机中执行shell rm 命令,删除刚才传送过去的目标 Apk 文件 delete_file(transport, serial, apk_dest); return err;}commandline.c
static int pm_command(transport_type transport,char* serial, int argc, char** argv){ char buf[4096]; snprintf(buf,sizeof(buf), "shell:pm"); //... //发送"shell:pm install 参数"给手机端的 adbd send_shellcommand(transport, serial, buf); return 0;}手机端的 adbd 在收到客户端发来的 shell
# Script to start "pm" on the device,which has a very rudimentary# shell.#
base=/systemexport CLASSPATH=$base/frameworks/pm.jarexec app_process $base/bincom.android.commands.pm.Pm "$@"在编译 system.image 时,Android.mk 中会将该脚本复制到 system/bin 目录下。从 pm 脚本的内容来看,它就是通过 app_process 执行 pm.jar 包的 main 函数。 pm.java
public static void main(String[] args) { new Pm().run(args);//创建一个 Pm 对象,并执行它的 run 函数}
//直接分析 run 函数public void run(String[] args) { boolean validCommand = false; //... //获取PKMS的binder客户端 mPm = IPackageManager.Stub .asInterface(ServiceManager.getService("package")); //... mArgs = args; String op = args[0]; mNextArg = 1; //...//处理其他命令,这里仅考虑 install 的处理 if("install".equals(op)) { runInstall(); return; } //...}
private void runInstall() { intinstallFlags = 0; String installerPackageName = null; String opt; while ((opt=nextOption()) != null) { if (opt.equals("-l")) { installFlags |= PackageManager.INSTALL_FORWARD_LOCK; } else if (opt.equals("-r")) { installFlags |= PackageManager.INSTALL_REPLACE_EXISTING; } else if (opt.equals("-i")) { installerPackageName = nextOptionData(); //... //参数解析 } //... }
final Uri apkURI; final Uri verificationURI; final String apkFilePath = nextArg(); System.err.println("/tpkg: " + apkFilePath);
if(apkFilePath != null) { apkURI = Uri.fromFile(new File(apkFilePath)); } //... //获取 Verification Package 的文件位置 final String verificationFilePath = nextArg();
if(verificationFilePath != null) { verificationURI = Uri.fromFile(new File(verificationFilePath)); }else { verificationURI = null; } //创建 PackageInstallObserver,用于接收 PKMS 的安装结果 PackageInstallObserver obs = new PackageInstallObserver(); try{ //调用 PKMS 的 installPackageWithVerification 完成安装 mPm.installPackageWithVerification(apkURI, obs, installFlags,installerPackageName, verificationURI,null); synchronized (obs) { while(!obs.finished) { try{ obs.wait();//等待安装结果 } //... } if(obs.result == PackageManager.INSTALL_SUCCEEDED) { System.out.println("Success");//安装成功,打印 Success } //...//安装失败,打印失败原因 } //...}Pm 解析参数后,最终通过 PKMS 的 Binder 客户端调用 installPackageWithVerification 以完成后续的安装工作,所以,下面进入 PKMS 看看安装到底是怎么一回事。
installPackageWithVerification 分析
PackageManagerService.java::installPackageWithVerification
public void installPackageWithVerification(UripackageURI, IPackageInstallObserverobserver, int flags, String installerPackageName, Uri verificationURI, ManifestDigest manifestDigest) {
//检查客户端进程是否具有安装 Package 的权限。在本例中,该客户端进程是 shell mContext.enforceCallingOrSelfPermission( android.Manifest.permission.INSTALL_PACKAGES,null); final int uid = Binder.getCallingUid(); final int filteredFlags;
if(uid == Process.SHELL_UID || uid == 0) { //...//如果通过 shell pm 的方式安装,则增加 INSTALL_FROM_ADB 标志 filteredFlags = flags | PackageManager.INSTALL_FROM_ADB; }else { filteredFlags = flags & ~PackageManager.INSTALL_FROM_ADB; }
//创建一个 Message,code 为 INIT_COPY,将该消息发送给之前在 PKMS 构造函数中 //创建的 mHandler 对象,将在另外一个工作线程中处理此消息 final Message msg = mHandler.obtainMessage(INIT_COPY);
//创建一个 InstallParams,其基类是 HandlerParams msg.obj = new InstallParams(packageURI, observer, filteredFlags,installerPackageName, verificationURI,manifestDigest); mHandler.sendMessage(msg);}INIT_COPY 处理
INIT_COPY 只是安装流程的第一步。先来看相关代码: PackageManagerService.java::handleMesssage
public void handleMessage(Message msg) { try { doHandleMessage(msg);//调用 doHandleMessage 函数 } //...}
void doHandleMessage(Message msg) { switch (msg.what) { case INIT_COPY: { //这里记录的是 params 的基类类型 HandlerParams,实际类型为 InstallParams HandlerParams params = (HandlerParams) msg.obj; //idx为当前等待处理的安装请求的个数 int idx = mPendingInstalls.size();
if (!mBound) { //APK 的安装居然需要使用另外一个 APK 提供的服务,该服务就是 //DefaultContainerService,由 DefaultCotainerService.apk 提供, //下面的 connectToService 函数将调用 bindService 来启动该服务 if (!connectToService()) { params.serviceError(); return; } else { ////如果已经连上,则以 idx 为索引,将 params 保存到 mPendingInstalls 中 mPendingInstalls.add(idx, params); } } else { mPendingInstalls.add(idx, params); if (idx == 0) { //如果安装请求队列之前的状态为空,则表明要启动安装 mHandler.sendEmptyMessage(MCS_BOUND); } } break; } case MCS_BOUND: { //稍后分析 } }}这里假设之前已经成功启动了 DefaultContainerService(以后简称 DCS),并且 idx 为零,所以这是 PKMS 首次处理安装请求,也就是说,下一个将要处理的是 MCS_BOUND 消息。
MCS_BOUND 处理
void doHandleMessage(Message msg) { switch (msg.what) { case INIT_COPY: { //... } case MCS_BOUND: { if (msg.obj != null) { mContainerService = (IMediaContainerService) msg.obj; } if (mContainerService == null) { if (!mBound) { //如果没法启动该 service,则不能安装程序 mPendingInstalls.clear(); } } else if (mPendingInstalls.size() > 0) { HandlerParams params = mPendingInstalls.get(0); if (params != null) { //调用 params 对象的 startCopy 函数,该函数由基类 HandlerParams 定义 if (params.startCopy()) { //... if (mPendingInstalls.size() > 0) { mPendingInstalls.remove(0);//删除队列头 } if (mPendingInstalls.size() == 0) { if (mBound) { //如果安装请求都处理完了,则需要和 Service 断绝联系, //通过发送 MSC_UNB 消息处理断交请求 removeMessages(MCS_UNBIND); Message ubmsg = obtainMessage(MCS_UNBIND); sendMessageDelayed(ubmsg, 10000); } } else { //如果还有未处理的请求,则继续发送 MCS_BOUND 消息。 //为什么不通过一个循环来处理所有请求呢 mHandler.sendEmptyMessage(MCS_BOUND); } } } } break; } }}MCS_BOUND 的处理还算简单,就是调用 HandlerParams 的 startCopy 函数。 PackageManagerService.java::HandlerParams.startCopy()
final boolean startCopy() { booleanres; try { //MAX_RETIRES 目前为 4,表示尝试 4 次安装,如果还不成功,则认为安装失败 if(++mRetries > MAX_RETRIES) { mHandler.sendEmptyMessage(MCS_GIVE_UP); handleServiceError(); return false; } else { handleStartCopy();//调用派生类的 handleStartCopy 函数 res= true; } } ...
handleReturnCode();//调用派生类的 handleReturnCode,返回处理结果 return res;}在上述代码中,基类的 startCopy 将调用子类实现的 handleStartCopy 和 handleReturnCode 函数。下面来看 InstallParams 是如何实现这两个函数的。
InstallParams 分析
PackageManagerService::InstallParams.handleStartCopy()
public void handleStartCopy() throwsRemoteException {
int ret = PackageManager.INSTALL_SUCCEEDED; final boolean fwdLocked = (flags &PackageManager.INSTALL_FORWARD_LOCK) != 0;
//根据 adb install 的参数,判断安装位置 final boolean onSd = (flags & PackageManager.INSTALL_EXTERNAL) != 0; final boolean onInt = (flags & PackageManager.INSTALL_INTERNAL) != 0;
PackageInfoLite pkgLite = null;
if(onInt && onSd) { //APK 不能同时安装在内部存储和 SD 卡上 ret = PackageManager.INSTALL_FAILED_INVALID_INSTALL_LOCATION;
} else if (fwdLocked && onSd) { //fwdLocked 的应用不能安装在 SD 卡上 ret = PackageManager.INSTALL_FAILED_INVALID_INSTALL_LOCATION; } else { final long lowThreshold;
//获取 DeviceStorageMonitorService 的 binder 客户端 final DeviceStorageMonitorService dsm = (DeviceStorageMonitorService) ServiceManager.getService( DeviceStorageMonitorService.SERVICE);
if(dsm == null) { lowThreshold = 0L; }else { //从 DSMS 查询内部空间最小余量,默认是总空间的10% lowThreshold = dsm.getMemoryLowThreshold(); }
try { //授权 DefContainerService URI 读权限 mContext.grantUriPermission(DEFAULT_CONTAINER_PACKAGE, packageURI,Intent.FLAG_GRANT_READ_URI_PERMISSION);
//调用 DCS 的 getMinimalPackageInfo 函数,得到一个 PackageLite 对象,详见下面分析 pkgLite = mContainerService.getMinimalPackageInfo(packageURI, flags,lowThreshold);
}finally //...//撤销 URI 授权
//PacakgeLite 的 recommendedInstallLocation 成员变量保存该 APK 推荐的安装路径 int loc = pkgLite.recommendedInstallLocation;
if (loc == PackageHelper.RECOMMEND_FAILED_INVALID_LOCATION) { ret = PackageManager.INSTALL_FAILED_INVALID_INSTALL_LOCATION; } else if...{ } else { //根据 DCS 返回的安装路径,还需要调用 installLocationPolicy 进行检查 loc = installLocationPolicy(pkgLite, flags);
if(!onSd && !onInt) { if(loc == PackageHelper.RECOMMEND_INSTALL_EXTERNAL) { flags |= PackageManager.INSTALL_EXTERNAL; flags &=~PackageManager.INSTALL_INTERNAL;
} //...//处理安装位置为内部存储的情况 } } }
//创建一个安装参数对象,对于安装位置为内部存储的情况,args 的真实类型为 FileInstallArgs final InstallArgs args = createInstallArgs(this);
mArgs = args;
if (ret == PackageManager.INSTALL_SUCCEEDED) { final int requiredUid = mRequiredVerifierPackage == null ? -1 : getPackageUid(mRequiredVerifierPackage); if(requiredUid != -1 && isVerificationEnabled()) { //...//verification 的处理,这部分代码后续再介绍 } else { //调用 args 的 copyApk 函数 ret = args.copyApk(mContainerService, true); } } mRet = ret;//确定返回值}在以上代码中,一共列出了五个关键点,总结如下:
- 调用 DCS 的 getMinimalPackageInfo 函数,将得到一个 PackageLite 对象,该对象是一个轻量级的用于描述 APK 的结构(相比PackageParser.Package 来说)。在这段代码逻辑中,主要想取得其 recommendedInstallLocation 的值。此值表示该 APK 推荐的安装路径。
- 调用 installLocationPolicy 检查推荐的安装路径。例如:系统 Package 不允许安装在 SD 卡上。
- createInstallArgs 将根据安装位置创建不同的 InstallArgs。如果是内部存储,则返回 FileInstallArgs,否则为 SdInstallArgs。
- 在正式安装前,应先对该 APK 进行必要的检查。这部分代码后续再介绍。
- 调用 InstallArgs 的 copyApk。对本例来说,将调用 FileInstallArgs 的 copyApk 函数。
DefaultContainerService 分析
DefaultContainerService.java::getMinimalPackageInfo()
public PackageInfoLite getMinimalPackageInfo(finalUri fileUri, int flags, longthreshold) { //注意该函数的参数:fileUri 指向该 APK 的文件路径(此时还在 /data/local/tmp 下) PackageInfoLite ret = new PackageInfoLite(); //... String scheme = fileUri.getScheme(); //... String archiveFilePath = fileUri.getPath(); DisplayMetrics metrics = new DisplayMetrics(); metrics.setToDefaults();
//调用 PackageParser 的 parsePackageLite 解析该 APK 文件 PackageParser.PackageLite pkg = PackageParser.parsePackageLite(archiveFilePath,0);
if (pkg == null) {//解析失败 //...//设置错误值 return ret; }
ret.packageName = pkg.packageName; ret.installLocation = pkg.installLocation; ret.verifiers = pkg.verifiers;
//调用 recommendAppInstallLocation,取得一个合理的安装位置 ret.recommendedInstallLocation =
recommendAppInstallLocation(pkg.installLocation,archiveFilePath, flags, threshold); return ret;}APK 可在 AndroidManifest.xml 中声明一个安装位置,不过 DCS 除了解析该位置外,还需要做进一步检查,这个工作由 recommendAppInstallLocation 函数完成,代码如下: DefaultContainerService.java::recommendAppInstallLocation()
private int recommendAppInstallLocation(intinstallLocation, StringarchiveFilePath, int flags,long threshold) { int prefer; boolean checkBoth = false;
check_inner: { if((flags & PackageManager.INSTALL_FORWARD_LOCK) != 0) { prefer = PREFER_INTERNAL; break check_inner; //根据 FOWRAD_LOCK 的情况,只能安装在内部存储 } else if ((flags & PackageManager.INSTALL_INTERNAL) != 0) { prefer = PREFER_INTERNAL; break check_inner; } //...//检查各种情况 } else if(installLocation == PackageInfo.INSTALL_LOCATION_AUTO) { prefer= PREFER_INTERNAL;//一般设定的位置为 AUTO,默认是内部空间 checkBoth = true; //设置checkBoth为true breakcheck_inner; }
//查询 settings 数据库中的 secure 表,获取用户设置的安装路径 intinstallPreference = Settings.System.getInt(getApplicationContext() .getContentResolver(),
Settings.Secure.DEFAULT_INSTALL_LOCATION, PackageHelper.APP_INSTALL_AUTO);
if(installPreference == PackageHelper.APP_INSTALL_INTERNAL) { prefer = PREFER_INTERNAL; break check_inner; } else if(installPreference == PackageHelper.APP_INSTALL_EXTERNAL) { prefer = PREFER_EXTERNAL; breakcheck_inner; }
prefer =PREFER_INTERNAL; }
//判断外部存储空间是否为模拟的,这部分内容我们以后再介绍 final boolean emulated = Environment.isExternalStorageEmulated(); final FileapkFile = new File(archiveFilePath); boolean fitsOnInternal = false;
if(checkBoth || prefer == PREFER_INTERNAL) { try {//检查内部存储空间是否足够大 fitsOnInternal = isUnderInternalThreshold(apkFile, threshold); } //... }
boolean fitsOnSd = false; if(!emulated && (checkBoth || prefer == PREFER_EXTERNAL)) { try{ //检查外部存储空间是否足够大 fitsOnSd = isUnderExternalThreshold(apkFile); } //... }
if (prefer== PREFER_INTERNAL) { if(fitsOnInternal) {//返回推荐安装路径为内部空间 return PackageHelper.RECOMMEND_INSTALL_INTERNAL; } } else if (!emulated && prefer == PREFER_EXTERNAL) { if(fitsOnSd) {//返回推荐安装路径为外部空间 returnPackageHelper.RECOMMEND_INSTALL_EXTERNAL; } }
if(checkBoth) { if(fitsOnInternal) {//如果内部存储满足条件,先返回内部空间 return PackageHelper.RECOMMEND_INSTALL_INTERNAL; }else if (!emulated && fitsOnSd) { return PackageHelper.RECOMMEND_INSTALL_EXTERNAL; } }
//... //到此,前几个条件都不满足,此处将根据情况返回一个明确的错误值 return PackageHelper.RECOMMEND_FAILED_INSUFFICIENT_STORAGE; }}DCS 的 getMinimalPackageInfo 函数为了得到一个推荐的安装路径做了不少工作,其中,各种安装策略交叉影响。这里总结一下相关的知识点:
- APK 在 AndroidManifest.xml 中设置的安装点默认为 AUTO,在具体对应时倾向内部空间。
- 用户在 Settings 数据库中设置的安装位置。
- 检查外部存储或内部存储是否有足够空间。
InstallArgs 的 copyApk 函数分析
至此,我们已经得到了一个合适的安装位置,下一步工作就由 copyApk 来完成。 PackageManagerService.java::InstallArgs.copyApk()
int copyApk(IMediaContainerService imcs, booleantemp) throws RemoteException { if (temp) { /* 本例中temp参数为true,createCopyFile将在/data/app下创建一个临时文件。 临时文件名为vmdl-随机数.tmp。为什么会用这样的文件名呢? 因为PKMS通过Linux的inotify机制监控了/data/app,目录,如果新复制生成的文件名后缀 为apk,将触发PKMS扫描。为了防止发生这种情况,这里复制生成的文件才有了 如此奇怪的名字 */ createCopyFile(); }
FilecodeFile = new File(codeFileName); //... ParcelFileDescriptor out = null; try { out = ParcelFileDescriptor.open(codeFile, ParcelFileDescriptor.MODE_READ_WRITE); }//...
int ret = PackageManager.INSTALL_FAILED_INSUFFICIENT_STORAGE; try { mContext.grantUriPermission(DEFAULT_CONTAINER_PACKAGE, packageURI, Intent.FLAG_GRANT_READ_URI_PERMISSION); //调用 DCS 的 copyResource,该函数将执行复制操作,最终结果是 /data/local/tmp //下的APK文件被复制到 /data/app 下,文件名也被换成 vmdl-随机数.tmp ret = imcs.copyResource(packageURI, out); } finally { //...//关闭 out,撤销 URI 授权 } return ret;}handleReturnCode 分析
在 HandlerParams 的 startCopy 函数中,handleStartCopy 执行完之后,将调用 handleReturnCode 开展后续工作,代码如下: PackageManagerService.java::InstallParams.HandleParams()
void handleReturnCode() { if (mArgs != null) { //调用processPendingInstall函数,mArgs指向之前创建的FileInstallArgs对象 processPendingInstall(mArgs, mRet); }}
private void processPendingInstall(finalInstallArgs args, final intcurrentStatus) { //向 mHandler 中抛一个 Runnable 对象 mHandler.post(new Runnable() { public void run() { mHandler.removeCallbacks(this); //创建一个 PackageInstalledInfo 对象, PackageInstalledInfo res = new PackageInstalledInfo(); res.returnCode = currentStatus; res.uid = -1; res.pkg = null; res.removedInfo = new PackageRemovedInfo();
if (res.returnCode == PackageManager.INSTALL_SUCCEEDED) { //调用 FileInstallArgs 的 doPreInstall args.doPreInstall(res.returnCode); synchronized (mInstallLock) { //调用 installPackageLI 进行安装 installPackageLI(args, true, res); }
//调用 FileInstallArgs 的 doPostInstall args.doPostInstall(res.returnCode); }
final boolean update = res.removedInfo.removedPackage != null; boolean doRestore = (!update && res.pkg != null && res.pkg.applicationInfo.backupAgentName != null); int token;//计算一个ID号 if (mNextInstallToken < 0) mNextInstallToken = 1; token = mNextInstallToken++;
//创建一个 PostInstallData 对象 PostInstallData data = new PostInstallData(args, res);
//保存到 mRunningInstalls 结构中,以 token 为 key mRunningInstalls.put(token, data); if (res.returnCode == PackageManager.INSTALL_SUCCEEDED && doRestore){ //...//备份恢复的情况暂时不考虑 }
if (!doRestore) { //抛一个 POST_INSTALL 消息给 mHandler 进行处理 Message msg = mHandler.obtainMessage(POST_INSTALL, token, 0); mHandler.sendMessage(msg); } } });}由上面代码可知,handleReturnCode 主要做了 4 件事情:
- 调用 InstallArgs 的 doPreInstall 函数,在本例中是 FileInstallArgs 的 doPreInstall 函数。
- 调用 PKMS 的 installPackageLI 函数进行 APK 安装,该函数内部将调用 InstallArgs的doRename 对临时文件进行改名。另外,还需要扫描此 APK 文件。此过程和之前介绍的“扫描系统 Package”一节的内容类似。至此,该 APK 中的私有财产就全部被登记到 PKMS 内部进行保存了。
- 调用 InstallArgs 的 doPostInstall 函数,在本例中是 FileInstallArgs 的 doPostInstall 函数。
- 此时,该 APK 已经安装完成(不论失败还是成功),继续向 mHandler 抛送一个 POST_INSTALL 消息,该消息携带一个 token,通过它可从 mRunningInstalls 数组中取得一个 PostInstallData 对象。
这里介绍一下 FileInstallArgs 的 doRename 函数,它的功能是将临时文件改名,最终的文件的名称一般为“包名-数字.apk”。其中,数字是一个 index,从 1 开始。
POST_INSTALL 处理
PackageManagerService.java::doHandleMessage()
void doHandleMessage(Message msg) { switch (msg.what) { case INIT_COPY: { //... } case MCS_BOUND: { //... } case POST_INSTALL: { PostInstallData data = mRunningInstalls.get(msg.arg1); mRunningInstalls.delete(msg.arg1); boolean deleteOld = false;
if (data != null) { InstallArgs args = data.args; PackageInstalledInfo res = data.res;
if (res.returnCode == PackageManager.INSTALL_SUCCEEDED) { final String packageName = res.pkg.applicationInfo.packageName; res.removedInfo.sendBroadcast(false, true, false); Bundle extras = new Bundle(1); extras.putInt(Intent.EXTRA_UID, res.uid); //... final boolean update = res.removedInfo.removedPackage != null; if (update) { extras.putBoolean(Intent.EXTRA_REPLACING, true); } //发送 PACKAGE_ADDED 广播 sendPackageBroadcast(Intent.ACTION_PACKAGE_ADDED, packageName, extras, null, null, updateUsers); if (update) { //如果是 APK 升级,那么发送 PACKAGE_REPLACE 和 MY_PACKAGE_REPLACED 广播 //二者不同之处在于 PACKAGE_REPLACE 将携带一个 extra 信息 //... } //... } Runtime.getRuntime().gc(); if (deleteOld) { synchronized (mInstallLock) { //调用 FileInstallArgs 的 doPostDeleteLI 进行资源清理 res.removedInfo.args.doPostDeleteLI(true); } } if (args.observer != null) { try { // 向 pm 通知安装的结果 Bundle extras = extrasForInstallResult(res); args.observer.onPackageInstalled(res.name, res.returnCode, res.returnMsg, extras); } catch (RemoteException e) { Slog.i(TAG, "Observer no longer exists."); } } } else { Slog.e(TAG, "Bogus post-install token " + msg.arg1); } } break; }}Apk 安装流程总结
