目錄本文的內容PkMS怎么知道apk的位置系統應用和普通應用的區別應用掃描過程scanDirLI()addForInitLI()scanPackageNewLI()scanPackageOnlyLI()reconcilePackagesLocked()commitReconciledScanResultLocked()commitPackageSettings()掃描完成之后需要做的事情本文的內容 PkMS是怎么知道apk的位置 系統應用和普通應用的區別 應用掃描的過程以及應用信息的保存 PkMS怎么知道apk的位置

答案是按照路徑，對于手機用戶安裝應用都是放在/data/app，對于系統應用則是分布各個分區中，可以簡單的認為是目錄,/data就是data分區，以下的分區都會被掃描，并且只會掃描priv-app和app目錄：

system分區下的priv-app，app目錄/system/priv-app, /system/app product分區 odm分區 oem分區 vendor分區 system_ext分區 data分區，最后掃描

不過這些分區都執行不是特別嚴格，沒涉及到gms測試的基本都不怎么管，那么apk是存在什么地方呢？例如：Settings就放在/system_ext/priv-app/Settings/Settings.apk，其他分區都是類似的，下面分析應用掃描過程還會說到。這里解釋一下，為什么要分priv-app和app兩個目錄進行掃描? priv-app意思是這個目錄里面都是privileged應用，可以獲取privilege權限，權限的定義frameworks/base/core/res/AndroidManifest.xml中找到

系統應用和普通應用的區別

答案還是路徑，data分區內的應用是普通應用，其他分區安裝的應用都是系統應用，系統應用均不可卸載

應用掃描過程scanDirLI()

scanDirLI的幾個參數說明一下，

scanDir，應用目錄的集合，以上面Settings為例，目錄是/system_ext/priv-app scanFlags，掃描的標志，當為系統應用時，會加上SCAN_AS_SYSTEM標志，如果是priv-app目錄還要加上SCAN_AS_PRIVILGED packageParser，這個就是解析AndroidManifest.xml主要工具類 executorService，生產者線程

scanDirLI的邏輯比較簡單，

以上面/system_ext/priv-app為例，遍歷目錄下的每個目錄和apk 使用ExecutorService(線程池)對所有目錄和apk進行解析，詳細看PkMS解析package指南 獲取ParsedPackage并進行調用addForInitLI() addForInitLI()

邏輯相當的復雜，考慮情況也要很多，有些自己也沒搞懂，只挑能說的說一下

1.首先重命名包名的邏輯，在PkMS當中所有的package都是按照包名作為唯一的主鍵值，那么就可能出現應用需要更換包名的情況，PkMS給出解決方案是加上<original-package android:name='com.android.oldpackagename' />指明需要覆蓋安裝的包名，但是這樣就需要考慮到諸多情況了

包名修改多次怎么辦 之前有安裝過老包名的應用的處理情況 之前未安裝過老包名的應用的處理情況 之前安裝過當前包名的應用的處理情況

那么PkMS是怎么做的呢？

設計了一個originalPackages表示之前原始package，當遇到original-package時，就將包名加入到originalPackages當中，代碼如下

//ParsingPackageUtils.parseOriginalPackage()String orig = sa.getNonConfigurationString( R.styleable.AndroidManifestOriginalPackage_name, 0);if (!pkg.getPackageName().equals(orig)) { if (pkg.getOriginalPackages().isEmpty()) {pkg.setRealPackage(pkg.getPackageName()); } pkg.addOriginalPackage(orig);} 然后在addForInitLI()中根據realPkgName獲取originalPkgSetting 接下來判斷是否要覆蓋安裝應用

不過我感覺里面還是有些bug，似乎只是為了用gms應用替換AOSP里面的應用(如：PackageInstaller和PermissionController)專門設計的，并不具備普遍性，安裝的應用及時加了標簽也還是會被認為是兩個應用

2.對于覆蓋安裝系統應用的data區應用進行處理，什么是覆蓋安裝系統應用？即系統應用有更新，可以通過應用商店下載覆蓋安裝，但是并不會去卸載系統應用，而是disable系統應用，例如:Google的gms應用都是如此

如果安裝的應用出現問題了，重新enable被disabled應用 如果是系統更新的應用，則需要掃描disabled系統應用，因為可能會有OTA升級導致系統應用更新apk的情況，調用scanPackageOnlyLI()，進行掃描，后面還會分析 接下來是根據disabled系統應用和安裝應用的版本號，判斷是否需要重新使用系統應用

3.處理簽名，對于安裝的應用，必須要簽名

確認是否需要重新簽名，對于非系統應用來說，無需重新收集，這部分AOSP壓根沒寫，注釋里面的第二條還沒實現

// Verify certificates against what was last scanned. Force re-collecting certificate in two// special cases:// 1) when scanning system, force re-collect only if system is upgrading.// 2) when scannning /data, force re-collect only if the app is privileged (updated from// preinstall, or treated as privileged, e.g. due to shared user ID).final boolean forceCollect = scanSystemPartition ? mIsUpgrade : PackageManagerServiceUtils.isApkVerificationForced(pkgSetting); 是否跳過簽名驗證，這個是覆蓋安裝時候使用

// Full APK verification can be skipped during certificate collection, only if the file is// in verified partition, or can be verified on access (when apk verity is enabled). In both// cases, only data in Signing Block is verified instead of the whole file.// TODO(b/136132412): skip for Incremental installationfinal boolean skipVerify = scanSystemPartition || (forceCollect && canSkipForcedPackageVerification(parsedPackage));collectCertificatesLI(pkgSetting, parsedPackage, forceCollect, skipVerify);

4.還要處理一下第三步的反方向，即一開始有個安裝的應用(data分區)，而后OTA升級有添加了該系統應用(system或其他分區)，分為三種情況進行討論

簽名不相同，則卸載data分區的應用 如果系統應用的版本號更高，則移除data分區的應用，但保留應用的數據 如果系統應用的版本號更低，則將shouldHideSystemApp設置為true，也就是將在下面disable系統應用

5.調用scanPackageNewLI()繼續掃描

6.調用reconcilePackagesLocked()進行一致化處理

7.調用commitReconciledScanResultLocked()

scanPackageNewLI()

需要注意的是這個方法不僅僅是開機掃描的時候用，在安裝應用的時候也是執行的

再次處理重命名包名，這個應該和安裝有關系，我測試的時候是覆蓋安裝系統應用有效，普通應用無法生效，會被認為是兩個應用 調用adjustFlags()重新調整scanFlags，分為以下幾種情況 重命名包名應用或者覆蓋安裝的應用是系統應用，scanFlags添加上SCAN_AS_SYSTEM以及可能的其他flags如果sharedUserId是包含了privilege應用，則正在掃描的應用也要加上SCAN_AS_PRIVILEGED 獲取SharedUserSetting，這個在addForInitLI()獲取過一次，是為了掃描disabledPkgSetting獲取的 構建ScanRequest并且調用scanPackageOnlyLI()獲取ScanResult scanPackageOnlyLI()

這部分主要的邏輯是更新packageSetting和nativelibrary的解析

確定是否需要獲取abi(needToDeriveAbi)，如果packageSetting，如果應用已安裝，則無需更改cpuAbi，如果未安裝，則需要解析native庫 獲取<uses-static-library>標簽，這個我不知道是干嘛的，目前還沒遇到這種標簽 更新或創建新的PackageSetting，創建的情況有兩種，首次安裝應用或者是恢復出廠開機 根據第一步獲取的needToDeriveAbi獲取abi的類型并設置到PackageSetting中，另外就是要解析apk中的native so庫，并獲取對應so庫的路徑，這里有個SCAN_NEW_INSTALLflag，這個是給安裝用的，開機scan是不會有此問題 設置安裝的時間戳，主要是第一次安裝和當前安裝，目前不知道這個屬性的用處 創建ScanResult并返回 reconcilePackagesLocked()

先說一下幾個參數:

ReconcileRequest，放置需要的參數，allPackages->mPackages, scannedPackages->scanPackageOnlyLI()返回的ScanResult，sharedLibrarySource->mSharedLibraries解析之后才會進行push KeySetManagerService簽名管理服務

reconcilePackagesLocked()也會被安裝應用的流程調用，所以ReconcileRequest的參數有些是為了給它們用的，這個方法的主要功能就是為了校驗簽名

首先檢查簽名是否需要更新ksms.shouldCheckUpgradeKeySetLocked(signatureCheckPs, scanFlags)，這個不太能理解，簽名是可以更新的？ 調用verifySignatures()進行校驗簽名 最后生成ReconciledPackage并返回 commitReconciledScanResultLocked()

這里面也是安裝應用和掃描應用同時都會調用的方法，先只看掃描的情況

處理PackageSetting，這部分邏輯是和安裝應用是混在一起的，主要包括 SharedUserSetting, 這個一般只有覆蓋安裝的時候如果sharedUserId變了，要重新賦值重命名包名的邏輯，安裝重命名包名的時候會更新packages.xml文件 將PackageSetting寫入package-restrictions.xml，里面主要存儲的是disabled和enabled四大組件 最后調用commitPackageSettings()進行最后一步處理 commitPackageSettings() 判斷是不是有廠商自定義的ResolveActivity(config_customResolverActivity屬性)，如果有則調用setUpCustomResolverActivity()設置ResolveActivity為自定義的，ResolveActivity就是處理未指定的android.action.View的 處理ResolveActivity，如果沒有的話指定為framework的ResolveActivity 更新SharedLibraries，這部分還不太熟悉 檢查是否需要frozen應用，如果需要但沒有frozen則退出安裝，有以下幾種情況無需frozen應用 SCAN_BOOTING，開機的時候，因為這時沒有應用啟動的了SCAN_DONT_KILL_APP，安裝不殺死應用，這個一般要么在PkMS中指定，要么在adb安裝的時候指定SCAN_IGNORE_FROZEN，忽略FROZEN，這個連adb也沒有指定選項，可能是代碼遺留 調用mSettings.insertPackageSettingLPw()，這里并非是更新packages.xml的地方，只是將pkgSetting，放到Settings.mPackages中 將AndroidPackage放到mPackages中 更新KeySetManagerService的應用信息，這是一個管理簽名的服務 添加自定義的Permission和PermissionGroup到PermissionManagerService中 添加保護廣播，但這個并非給安裝應用使用，而是系統應用，例如：teleservice等 對于老的package或者Permission更新的需要對于申請了這些權限的應用更新權限，注意，這些權限也是由應用定義的 掃描完成之后需要做的事情 清除掉已刪除的系統應用和disable原本就disable的應用 調用PermissionManagerService.updateAllPermissions()更新權限，這部分是在所有應用掃描完成之后才執行 創建應用數據存儲的目錄，注意這里只是針對system core應用(如SystemUI)做的操作，data下的應用由于有多用戶的存在，每個data應用是針對單個用戶的， 最終將PackageSetting和permission以及簽名的fingerprint寫入到packages.xml當中，這里這樣設計我覺得應該是怕中途關機，這樣一次性寫入所有的信息可以盡量減少寫了一半關機的情況

以上就是Android 開機應用掃描相關總結的詳細內容，更多關于Android 開機應用掃描的資料請關注好吧啦網其它相關文章！