原文鏈接：https://blog.csdn.net/Innost/article/details/47253179
1??概述
PackageManagerService是本書分析的第一個核心服務，也是Android系統中最常用的服務之一。它負責系統中Package的管理，應用程序的安裝、卸載、信息查詢等。圖1展示了PackageManagerService及客戶端的類家族。
圖1 ?PackageManagerService及客戶端類家族
public interface IPackageManager extends android.os.IInterface {//定義內部類Stub，派生自Binder，實現IPackageManager接口public static abstract class Stub extends android.os.Binder implements android.content.pm.IPackageManager {private static final java.lang.String DESCRIPTOR = "android.content.pm.IPackageManager";public Stub() {this.attachInterface(this,DESCRIPTOR);}......//定義Stub的內部類Proxy，實現IPackageManager接口private static class Proxy implements android.content.pm.IPackageManager{//通過mRemote變量和服務端交互private android.os.IBinder mRemote;Proxy(android.os.IBinderremote) {mRemote = remote;}......}......}
}
?接下來分析PackageManagerService，為書寫方便起見，以后將其簡稱為PKMS。
2 ?初識PackageManagerService
PKMS作為系統的核心服務，由SystemServer創建，相關代碼如下：
//ServerThread的run函數
/*
4.0新增的一個功能，即設備加密（encrypting the device）,該功能由系統屬性vold.decrypt指定。這部分功能比較復雜，本書暫不討論。
該功能對PKMS的影響就是通過onlyCore實現的，該變量用于判斷是否只掃描系統庫（包括APK和Jar包）
*/
String cryptState = SystemProperties.get("vold.decrypt");
boolean onlyCore = false;
//ENCRYPTING_STATE的值為"trigger_restart_min_framework"
if(ENCRYPTING_STATE.equals(cryptState)) {......onlyCore = true;
} else if(ENCRYPTED_STATE.equals(cryptState)) {......onlyCore = true;
}
//1 調用PKMS的main函數，第二個參數用于判斷是否為工廠測試，我們不討論的這種情況，假定onlyCore的值為false
pm = PackageManagerService.main(context, factoryTest !=SystemServer.FACTORY_TEST_OFF,onlyCore);
boolean firstBoot = false;
try {//判斷本次是否為初次啟動。這里的FirstBoot是指開機后的第一次啟動firstBoot = pm.isFirstBoot();
}
......
try {//2 做dex優化，dex是Android上針對Java字節碼的一種優化技術，可提高運行效率pm.performBootDexOpt();
}
......
try {//3 通知系統進入就緒狀態pm.systemReady();
}
......
}//run函數結束
以上代碼中共有4個關鍵調用，分別是：
3 ?PKMS的main函數分析 PKMS的main函數代碼如下：
public static final IPackageManager main(Contextcontext, boolean factoryTest, boolean onlyCore) {//調用PKMS的構造函數，factoryTest和onlyCore的值均為falsePackageManagerService m = new PackageManagerService(context, factoryTest, onlyCore);//向ServiceManager注冊PKMSServiceManager.addService("package", m);return m;
}
main函數很簡單，只有短短幾行代碼，執行時間卻較長，主要原因是PKMS在其構造函數中做了很多“重體力活”，這也是Android啟動速度慢的主要原因之一。在分析該函數前，先簡單介紹一下PKMS構造函數的功能。
3.1 ?構造函數分析之前期準備工作
下面開始分析構造函數第一階段的工作，先看如下所示的代碼。
public PackageManagerService(Context context,boolean factoryTest, booleanonlyCore) {......if(mSdkVersion <= 0) {/*mSdkVersion是PKMS的成員變量，定義的時候進行賦值，其值取自系統屬性“ro.build.version.sdk”，即編譯的SDK版本。如果沒有定義，則APK就無法知道自己運行在Android哪個版本上*/Slog.w(TAG, "**** ro.build.version.sdk not set!");//打印一句警告}mContext = context;mFactoryTest = factoryTest;//假定為false，即運行在非工廠模式下mOnlyCore = onlyCore;//假定為false，即運行在普通模式下//如果此系統是eng版，則掃描Package后，不對package做dex優化mNoDexOpt = "eng".equals(SystemProperties.get("ro.build.type"));//mMetrics用于存儲與顯示屏相關的一些屬性，例如屏幕的寬/高尺寸，分辨率等信息mMetrics = new DisplayMetrics();//Settings是一個非常重要的類，該類用于存儲系統運行過程中的一些設置，//下面進行詳細分析 mSettings = new Settings();//1 addSharedUserLPw是什么？馬上來分析mSettings.addSharedUserLPw("android.uid.system",Process.SYSTEM_UID, ApplicationInfo.FLAG_SYSTEM);mSettings.addSharedUserLPw("android.uid.phone",MULTIPLE_APPLICATION_UIDS ? RADIO_UID :FIRST_APPLICATION_UID,ApplicationInfo.FLAG_SYSTEM);mSettings.addSharedUserLPw("android.uid.log",MULTIPLE_APPLICATION_UIDS ? LOG_UID :FIRST_APPLICATION_UID,ApplicationInfo.FLAG_SYSTEM);mSettings.addSharedUserLPw("android.uid.nfc",MULTIPLE_APPLICATION_UIDS ? NFC_UID :FIRST_APPLICATION_UID,ApplicationInfo.FLAG_SYSTEM);......//第一段結束
剛進入構造函數，就會遇到第一個較為復雜的數據結構Setting及它的addSharedUserLPw函數。Setting的作用是管理Android系統運行過程中的一些設置信息。到底是哪些信息呢？來看下面的分析。
1. ?初識Settings ? ?
先分析addSharedUserLPw函數。此處截取該函數的調用代碼，如下所示：
mSettings.addSharedUserLPw("android.uid.system",//字符串Process.SYSTEM_UID, //系統進程使用的用戶id，值為1000ApplicationInfo.FLAG_SYSTEM//標志系統Package
);
以此處的函數調用為例，我們為addSharedUserLPw傳遞了3個參數：（1） Android系統中UID/GID介紹
//系統進程使用的UID/GID，值為1000public static final int SYSTEM_UID = 1000;//Phone進程使用的UID/GID，值為1001public static final int PHONE_UID = 1001;//shell進程使用的UID/GID，值為2000public static final int SHELL_UID = 2000;//使用LOG的進程所在的組的UID/GID為1007public static final int LOG_UID = 1007;//供WIF相關進程使用的UID/GID為1010public static final int WIFI_UID = 1010;//mediaserver進程使用的UID/GID為1013public static final int MEDIA_UID = 1013;//設置能讀寫SD卡的進程的GID為1015public static final int SDCARD_RW_GID = 1015;//NFC相關的進程的UID/GID為1025public static final int NFC_UID = 1025;//有權限讀寫內部存儲的進程的GID為1023public static final int MEDIA_RW_GID = 1023;//第一個應用Package的起始UID為10000public static final int FIRST_APPLICATION_UID = 10000;//系統所支持的最大的應用Package的UID為99999public static final int LAST_APPLICATION_UID = 99999;//和藍牙相關的進程的GID為2000public static final int BLUETOOTH_GID = 2000;
下面分析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為uids = 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對象。
（2） SharedUserSetting分析 ? ?
<manifest xmlns:android="http://schemas.android.com/apk/res/android"package="com.android.systemui"coreApp="true"android:sharedUserId="android.uid.system"android:process="system">
......
在xml中，聲明了一個名為android:sharedUserId的屬性，其值為“android.uid.system”。sharedUserId看起來和UID有關，確實如此，它有兩個作用：
?圖2 ?SharedUserSetting類的關系圖
private boolean addUserIdLPw(int uid, Object obj, Objectname) {//uid不能超出限制。Android對UID進行了分類，應用APK所在進程的UID從10000開始，而系統APK所在進程小于10000if(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;
}
2. ?XML文件掃描
下面繼續分析PKMS的構造函數，代碼如下：
......//接前一段String separateProcesses = SystemProperties.get("debug.separate_processes");if(separateProcesses != null && separateProcesses.length() > 0) {......}else {mDefParseFlags = 0;mSeparateProcesses = null;}//創建一個Installer對象，該對象和Native進程installd交互，以后分析installd時再來討論它的作用mInstaller = new Installer();//得到一個WindowManager對象WindowManager wm = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);Display d = wm.getDefaultDisplay();d.getMetrics(mMetrics); //獲取當前設備的顯示屏信息synchronized (mInstallLock) {synchronized (mPackages) {//創建一個ThreadHandler對象，實際就是創建一個帶消息循環處理的線程，//該線程的工作是：程序安裝的和卸載等。以后分析程序安裝時會和它親密接觸mHandlerThread.start();//以ThreadHandler線程的消息循環(Looper對象)為參數創建一個PackageHandler，可知該Handler的handleMessage函數將運行在此線程上mHandler = new PackageHandler(mHandlerThread.getLooper());File dataDir = Environment.getDataDirectory();// mAppDataDir指向/data/data目錄mAppDataDir = new File(dataDir, "data");// mUserAppDataDir指向/data/user目錄mUserAppDataDir = new File(dataDir, "user");// mDrmAppPrivateInstallDir指向/data/app-private目錄mDrmAppPrivateInstallDir = new File(dataDir, "app-private");/*創建一個UserManager對象，目前沒有什么作用，但其前途將不可限量。根據Google的設想，未來手機將支持多個User，每個User將安裝自己的應用，該功能為Andorid智能手機推向企業用戶打下堅實基礎*/mUserManager = new UserManager(mInstaller, mUserAppDataDir);//1 從文件中讀權限readPermissions();//2 readLPw分析mRestoredSettings = mSettings.readLPw();long startTime = SystemClock.uptimeMillis();
以上代碼中調用了兩個函數，分別是readPermission和Setttings的readLPw，它們有什么作用呢？（1） readPermissions函數分析
void readPermissions() {// 指向/system/etc/permission目錄，該目錄中存儲了和設備相關的一些權限信息File libraryDir = 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);
}
readPermissions函數不就是調用readPermissionFromXml函數解析/system/etc/permissions目錄下的文件嗎？這些文件似乎都是XML文件。該目錄下都有哪些XML文件呢？如圖3所示。
圖3 ?/system/etc/permissions目錄下的內容
<permissions><!--建立權限名與gid的映射關系。如下面聲明的BLUTOOTH_ADMIN權限，它對應的用戶組是net_bt_admin。注意，該文件中的permission標簽只對那些需要通過讀寫設備（藍牙/camera）創建socket等進程劃分了gid。因為這些權限涉及和Linux內核交互，所以需要在底層權限（由不同的用戶組界定）和Android層權限（由不同的字符串界定）之間建立映射關系 -->
<permission name="android.permission.BLUETOOTH_ADMIN" ><group gid="net_bt_admin" />
</permission>
<permission name="android.permission.BLUETOOTH" ><group gid="net_bt" />
</permission>......<!--賦予對應uid相應的權限。如果下面一行表示uid為shell，那么就賦予它SEND_SMS的權限，其實就是把它加到對應的用戶組中--><assign-permission name="android.permission.SEND_SMS" uid="shell" /><assign-permission name="android.permission.CALL_PHONE" uid="shell" /><assign-permission name="android.permission.READ_CONTACTS" uid="shell" /><assign-permission name="android.permission.WRITE_CONTACTS" uid="shell" /><assign-permission name="android.permission.READ_CALENDAR" uid="shell" />......<!-- 系統提供的Java庫，應用程序運行時候必須要鏈接這些庫，該工作由系統自動完成 --><library name="android.test.runner"file="/system/frameworks/android.test.runner.jar"/><library name="javax.obex"file="/system/frameworks/javax.obex.jar"/>
</permissions>
?platform.xml文件中主要使用了如下4個標簽：
圖4 ?/system/etc/permission目錄中文件的來源
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中的gid字符串為整型，并保存到mGlobalGids中mGlobalGids =appendInt(mGlobalGids, gid);} ......} else if ("permission".equals(name)) {//解析permission標簽String perm = parser.getAttributeValue(null, "name");......perm = perm.intern();//調用readPermission處理readPermission(parser, perm);//下面解析的是assign-permission標簽} else if("assign-permission".equals(name)) {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);}......} ......} ......
}
?總結相關的數據結構，如圖4所示。在每個類圖中，首行是數據結構名，第二行是數據結構的類型，第三行是注釋。圖4中各種數據結構的目的是為了保存XML中各種標簽及它們之間的關系。
圖4 ?通過readPermissions函數建立的數據結構及其關系（2） readLPw的“佐料”
Settings() {File dataDir = Environment.getDataDirectory();File systemDir = 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文件）。
3. ?第一階段工作總結
掃描并解析XML文件，將其中的信息保存到特定的數據結構中。
3.2 ?構造函數分析之掃描Package
PKMS構造函數第二階段的工作就是掃描系統中的APK了。由于需要逐個掃描文件，因此手機上裝的程序越多，PKMS的工作量越大，系統啟動速度也就越慢。
1. ?系統庫的dex優化
接著對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");
boolean didDexOpt = 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;}} ......}} ......//將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優化。處理方式同上}
}
2. ?掃描系統Package
清空cache文件后，PKMS終于進入重點段了。接下來看PKMS第二階段工作的核心內容，即掃描Package，相關代碼如下：
//創建文件夾監控對象，監視/system/frameworks目錄。利用了Linux平臺的inotify機制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將掃描以下幾個目錄。（1） 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函數。（2） 初會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升級方面的工作。讀者可能會比較好奇：既然是升級，一定有新舊之分，如果這里剛解析后得到的Package信息是新，那么舊Package的信息從何得來？還記得”readLPw的‘佐料’”這一小節提到的package.xml文件嗎？此文件中存儲的就是上一次掃描得到的Package信息。對比這兩次的信息就知道是否需要做升級了。這部分代碼比較繁瑣，但不影響我們正常分析。感興趣的讀者可自行研究*///判斷是否需要設置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。（3） PackageParser分析
public Package parsePackage(File sourceFile, String destCodePath,DisplayMetrics metrics, int flags) {mParseError = PackageManager.INSTALL_SUCCEEDED;mArchiveSourcePath = sourceFile.getPath();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;
}
以上代碼中調用了另一個同名的PackageParser函數，就是解析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信息finalPackage pkg = new Package(pkgName);boolean foundApp = false;......//下面開始解析該文件中的標簽，由于這段代碼功能簡單，所以這里僅列舉相關函數while(如果解析未完成){......String tagName = parser.getName(); //得到標簽名if(tagName.equals("application")){......//解析application標簽parseApplication(pkg,res, parser, attrs, flags, outError);} elseif (tagName.equals("permission-group")) {......//解析permission-group標簽parsePermissionGroup(pkg, res, parser, attrs, outError);} elseif (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標簽中聲明）。
?圖5 ?PackageParser大家族（4） 與scanPackageLI再相遇
private PackageParser.PackagescanPackageLI(PackageParser.Package pkg,int parseFlags, int scanMode, long currentTime) {File scanFile = new File(pkg.mScanPath);......mScanningPath = scanFile;//設置package對象中applicationInfo的flags標簽，用于標示該Package為系統Packageif((parseFlags&PackageParser.PARSE_IS_SYSTEM) != 0) {pkg.applicationInfo.flags |= ApplicationInfo.FLAG_SYSTEM;}//1 下面這句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成員指向mResolveActivitymResolveInfo.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，有圖為證，如圖6所示為該APK的AndroidManifest.xml中的相關內容。
圖6 ?framework-res.apk的AndroidManifest.xml
......//mPackages用于保存系統內的所有Package，以packageName為keyif(mPackages.containsKey(pkg.packageName) || mSharedLibraries.containsKey(pkg.packageName)) {return null;}File destCodeFile = new File(pkg.applicationInfo.sourceDir);File destResourceFile = new File(pkg.applicationInfo.publicSourceDir);SharedUserSettingsuid = null;//代表該Package的SharedUserSetting對象PackageSetting pkgSetting = null;//代表該Package的PackageSetting對象synchronized(mPackages) {......//此段代碼大約有300行左右，主要做了以下幾方面工作/*1 如果該Packge聲明了” uses-librarie”話，那么系統要判斷該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的進程的進程名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(p.info.packageName,p.info.name), p);......}//處理該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;
}
?到此這個長達800行的代碼就分析完了，下面總結一下Package掃描的流程。（5） scanDirLI函數總結
?圖7 ?scanDirLI工作流程總結
圖8 ?PKMS中重要的數據結構
3. ?掃描非系統Package
非系統Package就是指那些不存儲在系統目錄下的APK文件，這部分代碼如下：
if (!mOnlyCore) {//mOnlyCore用于控制是否掃描非系統PackageIterator<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文件的目錄。
4. ?第二階段工作總結
PKMS構造函數第二階段的工作任務非常繁重，要創建比較多的對象，所以它是一個耗時耗內存的操作。
3.3 ?構造函數分析之掃尾工作
下面分析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構造函數返回
}
3.4 ?PKMS構造函數總結
從流程角度看，PKMS構造函數的功能還算清晰，無非是掃描XML或APK文件，但是其中涉及的數據結構及它們之間的關系卻較為復雜。這里有一些建議供讀者參考：
4 ?APK Installation分析
本節將分析APK的安裝及相關處理流程，從adb install開始。
4.1 ?adb install分析
adb install有多個參數，這里僅考慮最簡單的，如adb install frameworktest.apk。adb是一個命令，install是它的參數。此處直接跳到處理install參數的代碼：
int adb_commandline(int argc, char **argv) {......if(!strcmp(argv[0], "install")) {......//調用install_app函數處理return install_app(ttype, serial, argc, argv);}......
}
install_app函數也在commandline.c中定義，代碼如下：
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 */);...... //1 4.0新增了一個安裝包Verification功能，相關知識稍后分析//2 執行pm命令，這個函數很有意思pm_command(transport,serial, argc, argv);......cleanup_apk://3 在手機中執行shell rm 命令，刪除剛才傳送過去的目標APK文件。為什么要刪除呢delete_file(transport, serial, apk_dest);return err;
}
以上代碼中共有三個關鍵點，分別是：
4.2 ?pm分析
pm_command代碼如下：
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 參數"給手機端的adbdsend_shellcommand(transport, serial, buf);return 0;
}
手機端的adbd在收到客戶端發來的shellpm命令時會啟動一個shell，然后在其中執行pm。pm是什么？為什么可以在shell下執行？
# Script to start "pm" on the device,which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/frameworks/pm.jar
exec app_process $base/bincom.android.commands.pm.Pm "$@"
在編譯system.image時，Android.mk中會將該腳本復制到system/bin目錄下。從pm腳本的內容來看，它就是通過app_process執行pm.jar包的main函數。在分析Zygote時，已經介紹了app_process是一個Native進程，它通過創建虛擬機啟動了Zygote，從而轉變為一個Java進程。實際上，app_process還可以通過類似的方法（即先創建Dalvik虛擬機，然后執行某個類的main函數）來轉變成其他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;}......
}
接下來分析pm.java的runInstall函數，代碼如下：
private void runInstall() {int installFlags = 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{//1 調用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看看安裝到底是怎么一回事。
4.3 ?installPackageWithVerification函數分析
installPackageWithVerification的代碼如下：
public void installPackageWithVerification(UripackageURI,IPackageInstallObserverobserver,int flags, String installerPackageName, Uri verificationURI,ManifestDigest manifestDigest) {//檢查客戶端進程是否具有安裝Package的權限。在本例中，該客戶端進程是shellmContext.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，其基類是HandlerParamsmsg.obj = new InstallParams(packageURI, observer,filteredFlags,installerPackageName,verificationURI,manifestDigest);mHandler.sendMessage(msg);
}
installPackageWithVerification函數倒是蠻清閑，簡簡單單創建幾個對象，然后發送INIT_COPY消息給mHandler就退出了。根據之前在PKMS構造函數中介紹的知識可知，mHandler被綁定到另外一個工作線程（借助ThreadHandler對象的Looper）中，所以該INIT_COPY消息也將在那個工作線程中進行處理。
1. ?INIT_COPY處理
INIT_COPY只是安裝流程的第一步。先來看相關代碼：
public void handleMessage(Message msg) {try {doHandleMessage(msg);//調用doHandleMessage函數} ......
}void doHandleMessage(Message msg) {switch(msg.what) {case INIT_COPY: {//1 這里記錄的是params的基類類型HandlerParams，實際類型為InstallParamsHandlerParams params = (HandlerParams) msg.obj;//idx為當前等待處理的安裝請求的個數int idx = mPendingInstalls.size();if(!mBound) {/*很多讀者可能想不到，APK的安裝居然需要使用另外一個APK提供的服務，該服務就是DefaultContainerService，由DefaultCotainerService.apk提供，下面的connectToService函數將調用bindService來啟動該服務*/if(!connectToService()) {return;}else {//如果已經連上，則以idx為索引，將params保存到mPendingInstalls中mPendingInstalls.add(idx, params);}} else {mPendingInstalls.add(idx, params);if(idx == 0) {//如果安裝請求隊列之前的狀態為空，則表明要啟動安裝mHandler.sendEmptyMessage(MCS_BOUND);}}break;}......//后續再分析
這里假設之前已經成功啟動了DefaultContainerService（以后簡稱DCS），并且idx為零，所以這是PKMS首次處理安裝請求下一個將要處理的是MCS_BOUND消息。
2. ?MCS_BOUND處理
現在，安裝請求的狀態從INIT_COPY變成MCS_BOUND了，此時的處理流程時怎樣的呢？依然在doHandleMessage函數中，直接從對應的case開始，代碼如下：
......//接doHandleMesage中的switch/case
case MCS_BOUND: {if(msg.obj != null) {mContainerService= (IMediaContainerService) msg.obj;}if(mContainerService == null) {......//如果沒法啟動該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函數。在深入分析前，應先認識一下HandlerParams及相關的對象。（1） HandlerParams和InstallArgs介紹
圖8 ?HandlerParams及InstallArgs家族成員
final boolean startCopy() {boolean res;try {//MAX_RETIRES目前為4，表示嘗試4次安裝，如果還不成功，則認為安裝失敗if(++mRetries > MAX_RETRIES) {mHandler.sendEmptyMessage(MCS_GIVE_UP);handleServiceError();return false;} else {handleStartCopy();//1 調用派生類的handleStartCopy函數res= true;}} ......handleReturnCode();//2 調用派生類的handleReturnCode，返回處理結果return res;
}
?在上述代碼中，基類的startCopy將調用子類實現的handleStartCopy和handleReturnCode函數。下面來看InstallParams是如何實現這兩個函數的。
（2） InstallParams分析
先來看派生類InstallParams的handleStartCopy函數，代碼如下：
public void handleStartCopy() throwsRemoteException {int ret= PackageManager.INSTALL_SUCCEEDED;//根據adb install的參數，判斷安裝位置finalboolean onSd = (flags & PackageManager.INSTALL_EXTERNAL) != 0;finalboolean onInt = (flags & PackageManager.INSTALL_INTERNAL) != 0;PackageInfoLite pkgLite = null;if(onInt && onSd) {//APK不能同時安裝在內部存儲和SD卡上ret = PackageManager.INSTALL_FAILED_INVALID_INSTALL_LOCATION;} else {finallong lowThreshold;//獲取DeviceStorageMonitorService的binder客戶端finalDeviceStorageMonitorService 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);//1 調用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;}//2 根據DCS返回的安裝路徑，還需要調用installLocationPolicy進行檢查loc = installLocationPolicy(pkgLite, flags);if(!onSd && !onInt) {if(loc == PackageHelper.RECOMMEND_INSTALL_EXTERNAL) {flags |= PackageManager.INSTALL_EXTERNAL;flags &=~PackageManager.INSTALL_INTERNAL;} ......//處理安裝位置為內部存儲的情況}}//3 創建一個安裝參數對象，對于安裝位置為內部存儲的情況，args的真實類型為FileInstallArgsfinalInstallArgs args = createInstallArgs(this);mArgs = args;if (ret == PackageManager.INSTALL_SUCCEEDED) {final int requiredUid = mRequiredVerifierPackage == null ? -1:getPackageUid(mRequiredVerifierPackage);if(requiredUid != -1 && isVerificationEnabled()) {......//4 待會再討論verification的處理} else {//5 調用args的copyApk函數ret= args.copyApk(mContainerService, true);}}mRet =ret;//確定返回值
}
在以上代碼中，一共列出了五個關鍵點，總結如下：
3. ?handleStartCopy分析
（1） DefaultContainerService分析
public PackageInfoLite getMinimalPackageInfo(finalUri fileUri, int flags, long threshold) {//注意該函數的參數：fileUri指向該APK的文件路徑（此時還在/data/local/tmp下）PackageInfoLite ret = new PackageInfoLite();......Stringscheme = fileUri.getScheme();......StringarchiveFilePath = 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函數完成。（2） InstallArgs的copyApk函數分析
int copyApk(IMediaContainerService imcs, boolean temp) throws RemoteException {if (temp){/*本例中temp參數為true，createCopyFile將在/data/app下創建一個臨時文件。臨時文件名為vmdl-隨機數.tmp。為什么會用這樣的文件名呢？因為PKMS通過Linux的inotify機制監控了/data/app,目錄，如果新復制生成的文件名后綴為apk，將觸發PKMS掃描。為了防止發生這種情況，這里復制生成的文件才有了如此奇怪的名字*/createCopyFile();}File codeFile = 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-隨機數.tmpret= imcs.copyResource(packageURI, out);} finally {......//關閉out，撤銷URI授權}return ret;
}
關于臨時文件，這里提供一個示例，如圖9所示。
圖9 ?createCopyFile生成的臨時文件
4. ?handleReturnCode分析
在HandlerParams的startCopy函數中，handleStartCopy執行完之后，將調用handleReturnCode開展后續工作，代碼如下：
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) {//1 調用FileInstallArgs的doPreInstallargs.doPreInstall(res.returnCode);synchronized (mInstallLock) {//2 調用installPackageLI進行安裝installPackageLI(args, true, res);}//3 調用FileInstallArgs的doPostInstallargs.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為keymRunningInstalls.put(token, data);if (res.returnCode ==PackageManager.INSTALL_SUCCEEDED && doRestore) {......//備份恢復的情況暫時不考慮}if(!doRestore) {//4 拋一個POST_INSTALL消息給mHandler進行處理Message msg = mHandler.obtainMessage(POST_INSTALL, token, 0);mHandler.sendMessage(msg);}}});
}
由上面代碼可知，handleReturnCode主要做了4件事情：
5. ?POST_INSTALL處理
現在需要處理POST_INSTALL消息，因為adb install還等著安裝結果呢。相關代碼如下：
......//接前面的switch/case
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) {res.removedInfo.sendBroadcast(false, true);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, res.pkg.applicationInfo.packageName,extras, null, null);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通知安裝的結果args.observer.packageInstalled(res.name, res.returnCode);} ......}} break;
4.4 ?APK 安裝流程總結
沒想到APK的安裝流程竟然如此復雜，其目的無非是讓APK中的私人財產公有化。
?圖10 ?APK安裝流程
5 ?queryIntentActivities分析
PKMS除了負責Android系統中Package的安裝、升級、卸載外，還有一項很重要的職責，就是對外提供統一的信息查詢功能，其中包括查詢系統中匹配某Intent的Activities、BroadCastReceivers或Services等。本節將以查詢匹配某Intent的Activities為例，介紹PKMS在這方便提供的服務。
5.1 ?Intent及IntentFilter介紹
1. ?Intent介紹
Intent中文是“意圖”的意思，它是Android系統中一個很重要的概念，其基本思想來源于對日常生活及行為的高度抽象。
2. ?IntentFilter介紹
IntentFilter來表達自己的訴求。Andorid規定了3項內容：
5.2 ?Activity信息的管理
前面在介紹PKMS掃描APK時提到，PKMS將解析得到的Package私有的Activity信息加入到自己的數據結構mActivities中保存。先來回顧一下代碼：
......//此時APK文件已經解析完成N = pkg.activities.size();//取出該APK中包含的Activities信息r = null;for (i=0; i<N; i++) {PackageParser.Activity a = pkg.activities.get(i);a.info.processName = fixProcessName(pkg.applicationInfo.processName,a.info.processName,pkg.applicationInfo.uid);mActivities.addActivity(a,"activity");//1 加到mActivities中保存
}
上面的代碼中有兩個比較重要的數據結構，如圖11所示：
圖11 ?相關數據結構示意圖
public final void addActivity(PackageParser.Activity a, String type) {final boolean systemApp = isSystemApp(a.info.applicationInfo);//將Component和Activity保存到mActivities中mActivities.put(a.getComponentName(), a);final int NI = a.intents.size();for(int j=0; j<NI; j++) {//ActivityIntentInfo存儲的就是XML中聲明的IntentFilter信息PackageParser.ActivityIntentInfo intent = a.intents.get(j);if(!systemApp && intent.getPriority() > 0 && "activity".equals(type)) {//非系統APK的priority必須為0。后續分析中將介紹priority的作用intent.setPriority(0);}addFilter(intent);//接下來將分析這個函數}
}
?下面來分析addFilter函數，這里涉及較多的復雜數據結構，代碼如下：
public void addFilter(F f) {......mFilters.add(f);//mFilters保存所有IntentFilter信息//除此之外，為了加快匹配工作的速度，還需要分類保存IntentFilter信息//下邊register_xxx函數的最后一個參數用于打印信息int numS = register_intent_filter(f, f.schemesIterator(), mSchemeToFilter, " Scheme: ");int numT = register_mime_types(f, " Type: ");if(numS == 0 && numT == 0) {register_intent_filter(f, f.actionsIterator(), mActionToFilter," Action: ");}if(numT != 0) {register_intent_filter(f, f.actionsIterator(), mTypedActionToFilter, " TypedAction: ");}
}
正如代碼注釋中所說，為了加快匹配工作的速度，這里使用了泛型編程并定義了較多的成員變量。下面總結一下這些變量的作用（注意，除mFilters為HashSet<F>類型外，其他成員變量的類型都是HashMap<String, ArrayList<F>>，其中F為模板參數）。
<intent-filter android:label="test"><action android:name="android.intent.action.VIEW" />data android:mimeType="audio/*" android:scheme="http"
</intent-filter>
那么：
5.3 ?Intent 匹配查詢分析
1. ?客戶端查詢
客戶端通過ApplicationPackageManager輸出的queryIntentActivities函數向PKMS發起一次查詢請求，代碼如下：
public List<ResolveInfo>queryIntentActivities(Intent intent, int flags) {try {return mPM.queryIntentActivities(intent, //下面這句話很重要intent.resolveTypeIfNeeded(mContext.getContentResolver()),flags);}......
}
如果Intent的Data包含一個URI，那么就需要查詢該URI的提供者（即ContentProvider）以取得該數據的數據類型。讀者可自行閱讀resolveTypeIfNeeded函數的代碼。
2. ?queryIntentActivities分析
該函數代碼如下：
public List<ResolveInfo>queryIntentActivities(Intent intent,String resolvedType, int flags) {final ComponentName comp = intent.getComponent();if(comp != null) {//1 Explicit的Intents，直接根據component得到對應的ActivityInfofinal List<ResolveInfo> list = new ArrayList<ResolveInfo>(1);final ActivityInfo ai = getActivityInfo(comp, flags);if (ai != null) {final ResolveInfo ri = new ResolveInfo();//ResovlerInfo的activityInfo指向查詢得到的ActivityInfori.activityInfo = ai;list.add(ri);}return list;}synchronized (mPackages) {final String pkgName = intent.getPackage();if (pkgName == null) {//3 Implicit Intents，我們重點分析此中情況return mActivities.queryIntent(intent, resolvedType, flags);}//Intent指明了PackageName，比Explicit Intents情況差一點final PackageParser.Package pkg = mPackages.get(pkgName);if (pkg != null) {//2 其實是從該Package包含的Activities中進行匹配查詢return mActivities.queryIntentForPackage(intent, resolvedType, flags, pkg.activities);}return new ArrayList<ResolveInfo>();}
}
上邊代碼分三種情況：
public List<ResolveInfo> queryIntent(Intentintent, String resolvedType, intflags) {mFlags =flags;//調用基類的queryIntent函數return super.queryIntent(intent, resolvedType, (flags&PackageManager.MATCH_DEFAULT_ONLY) != 0);
}
基類queryIntent里設置了最多四輪匹配關卡，然后逐一執行匹配工作。具體的匹配代碼由buildResolveList完成。
6 ?installd介紹
在前面對PKMS構造函數分析時介紹過一個Installer類型的對象mInstaller，它通過socket和后臺服務installd交互，以完成一些重要操作。這里先回顧一下PKMS中mInstaller的調用方法：
//創建一個Installer對象
mInstaller = new Installer();
//對某個APK文件進行dexopt優化
mInstaller.dexopt(paths[i], Process.SYSTEM_UID,true);
//掃描完系統Package后，調用moveFiles函數
mInstaller.moveFiles();
//當存儲空間不足時，調用該函數清理存儲空間
mInstaller.freeCache(freeStorageSize);
Installer的種種行為都和其背后的installd有關。下面來分析installd。
6.1 installd概貌
installd是一個native進程，代碼非常簡單，其功能就是啟動一個socket，然后處理來自Installer的命令，其代碼如下：
int main(const int argc, const char *argv[]) {char buf[BUFFER_MAX];struct sockaddr addr;socklen_t alen;int lsocket, s, count;if (初始化全局變量,如果失敗則退出) {initialize_globals();initialize_directories();......}......lsocket = android_get_control_socket(SOCKET_PATH);listen(lsocket, 5);fcntl(lsocket, F_SETFD, FD_CLOEXEC);for (;;){alen = sizeof(addr);s = accept(lsocket, &addr, &alen);fcntl(s, F_SETFD, FD_CLOEXEC);for(;;) {unsigned short count;readx(s, &count, sizeof(count));//執行installer發出的命令，具體解釋見下文execute(s, buf);}close(s);}return 0;
}
installd支持的命令及參數信息都保存在數據結構cmds中，代碼如下：
struct cmdinfo cmds[] = {//第二個變量是參數個數，第三個參數是命令響應函數{"ping", 0,do_ping },{"install", 3,do_install },{"dexopt", 3,do_dexopt },{"movedex", 2,do_move_dex },{"rmdex", 1,do_rm_dex },{"remove", 2,do_remove },{"rename", 2, do_rename },{"freecache", 1,do_free_cache },{"rmcache", 1,do_rm_cache },{"protect", 2,do_protect },{"getsize", 4,do_get_size },{"rmuserdata", 2,do_rm_user_data },{"movefiles", 0,do_movefiles },{"linklib", 2,do_linklib },{"unlinklib", 1,do_unlinklib },{"mkuserdata", 3,do_mk_user_data },{"rmuser", 1,do_rm_user },
};
下面來分析相關的幾個命令。
6.2 ?dexOpt命令分析
PKMS在需要對一個APK或jar包做dex優化時，會發送dexopt命令給installd，相應的處理函數為do_dexopt，代碼如下：
static int do_dexopt(char **arg, charreply[REPLY_MAX])
{return dexopt(arg[0], atoi(arg[1]), atoi(arg[2]));
}
[-->commands.c]
int dexopt(const char *apk_path, uid_t uid, intis_public)
{struct utimbuf ut;struct stat apk_stat, dex_stat;char dex_path[PKG_PATH_MAX];char dexopt_flags[PROPERTY_VALUE_MAX];char *end;int res, zip_fd=-1, odex_fd=-1;......//取出系統級的dexopt_flags參數property_get("dalvik.vm.dexopt-flags", dexopt_flags,"");strcpy(dex_path, apk_path);end = strrchr(dex_path, '.');if (end!= NULL) {strcpy(end, ".odex");if(stat(dex_path, &dex_stat) == 0) {return 0;}}//得到一個字符串，用于描述dex文件名，位于/data/dalvik-cache/下if(create_cache_path(dex_path, apk_path)) {return -1;}memset(&apk_stat, 0, sizeof(apk_stat));stat(apk_path, &apk_stat);zip_fd = open(apk_path, O_RDONLY, 0);......unlink(dex_path);odex_fd = open(dex_path, O_RDWR | O_CREAT | O_EXCL, 0644);......pid_t pid;pid = fork();if (pid== 0) {......//uid設置//創建一個新進程，然后對exec dexopt進程進行dex優化run_dexopt(zip_fd, odex_fd, apk_path, dexopt_flags);exit(67); } else {//installd父進程將等待dexopt完成優化工作res = wait_dexopt(pid, apk_path);......}......//資源清理return -1;
}
讓人大跌眼鏡的是，dex優化工作竟然由installd委派給dexopt進程來實現。dex優化后會生成一個dex文件，一般位于/data/dalvik-cache/目錄中。這里給出一個示例，如圖12所示。
圖12 ?dex文件示例
6.3 ?movefiles命令分析
PKMS掃描完系統Package后，將發送該命令給installd，相應處理函數的代碼如下：
static int do_movefiles(char **arg, char reply[REPLY_MAX])
{return movefiles();
}
[-->commands.c]
int movefiles()
{DIR *d;int dfd,subfd;struct dirent *de;struct stat s;char buf[PKG_PATH_MAX+1];int bufp, bufe, bufi, readlen;char srcpkg[PKG_NAME_MAX];char dstpkg[PKG_NAME_MAX];char srcpath[PKG_PATH_MAX];char dstpath[PKG_PATH_MAX];int dstuid=-1, dstgid=-1;int hasspace;//打開/system/etc/updatecmds/目錄d = opendir(UPDATE_COMMANDS_DIR_PREFIX);if (d ==NULL) {goto done;}dfd = dirfd(d);while((de = readdir(d))) {......//解析該目錄下的文件，然后執行對應操作}closedir(d);
done:return 0;
}
movefiles的功能和系統升級有關。
6.4 ?doFreeCache
當系統空間不夠時，DSMS會調用PKMS的freeStorageAndNotify函數進行空間清理。該工作真正的實施者是installd，相應的處理命令為do_free_cache，其代碼如下：
static int do_free_cache(char **arg, char reply[REPLY_MAX])
{return free_cache((int64_t)atoll(arg[0]));
}
[-->commands.c]
int free_cache(int64_t free_size)
{const char *name;int dfd,subfd;DIR *d;struct dirent *de;int64_t avail;avail = disk_free();//獲取當前系統的剩余空間大小if(avail < 0) return -1;if(avail >= free_size) return 0;d = opendir(android_data_dir.path);//打開/data/目錄dfd = dirfd(d);while((de = readdir(d))) {if (de->d_type != DT_DIR) continue;name = de->d_name;......//略過.和..文件subfd = openat(dfd, name, O_RDONLY | O_DIRECTORY);//刪除/data及各級子目錄中的cache文件夾delete_dir_contents_fd(subfd, "cache");close(subfd);......//如果剩余空間恢復正常，則返回}closedir(d);return -1;//清理空間后，仍然不滿足要求
}
7 ?本章學習指導
這里提出一些學習建議供讀者參考。
總結
以上是生活随笔 為你收集整理的[2021.8.18]深入理解PackageManagerService 的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網站內容還不錯，歡迎將生活随笔 推薦給好友。
