本文的內(nèi)容

1. PkMS是怎么知道apk的位置
2. 系統(tǒng)應(yīng)用和普通應(yīng)用的區(qū)別
3. 應(yīng)用掃描的過程以及應(yīng)用信息的保存
   

PkMS怎么知道apk的位置

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

1. system分區(qū)下的priv-app，app目錄/system/priv-app, /system/app
2. product分區(qū)
3. odm分區(qū)
4. oem分區(qū)
5. vendor分區(qū)
6. system_ext分區(qū)
7. data分區(qū)，最后掃描
   

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

系統(tǒng)應(yīng)用和普通應(yīng)用的區(qū)別

答案還是路徑，data分區(qū)內(nèi)的應(yīng)用是普通應(yīng)用，其他分區(qū)安裝的應(yīng)用都是系統(tǒng)應(yīng)用，系統(tǒng)應(yīng)用均不可卸載

應(yīng)用掃描過程

scanDirLI()

scanDirLI的幾個參數(shù)說明一下，

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

scanDirLI的邏輯比較簡單，

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

addForInitLI()

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

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

1. 包名修改多次怎么辦
2. 之前有安裝過老包名的應(yīng)用的處理情況
3. 之前未安裝過老包名的應(yīng)用的處理情況
4. 之前安裝過當前包名的應(yīng)用的處理情況
   

那么PkMS是怎么做的呢？

• 設(shè)計了一個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()中根據(jù)realPkgName獲取originalPkgSetting
• 接下來判斷是否要覆蓋安裝應(yīng)用

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

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

1. 如果安裝的應(yīng)用出現(xiàn)問題了，重新enable被disabled應(yīng)用
2. 如果是系統(tǒng)更新的應(yīng)用，則需要掃描disabled系統(tǒng)應(yīng)用，因為可能會有OTA升級導(dǎo)致系統(tǒng)應(yīng)用更新apk的情況，調(diào)用scanPackageOnlyLI()，進行掃描，后面還會分析
3. 接下來是根據(jù)disabled系統(tǒng)應(yīng)用和安裝應(yīng)用的版本號，判斷是否需要重新使用系統(tǒng)應(yīng)用

3.處理簽名，對于安裝的應(yīng)用，必須要簽名

• 確認是否需要重新簽名，對于非系統(tǒng)應(yīng)用來說，無需重新收集，這部分AOSP壓根沒寫，注釋里面的第二條還沒實現(xiàn)

// 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 installation
final boolean skipVerify = scanSystemPartition
    || (forceCollect && canSkipForcedPackageVerification(parsedPackage));
collectCertificatesLI(pkgSetting, parsedPackage, forceCollect, skipVerify);

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

• 簽名不相同，則卸載data分區(qū)的應(yīng)用
• 如果系統(tǒng)應(yīng)用的版本號更高，則移除data分區(qū)的應(yīng)用，但保留應(yīng)用的數(shù)據(jù)
• 如果系統(tǒng)應(yīng)用的版本號更低，則將shouldHideSystemApp設(shè)置為true，也就是將在下面disable系統(tǒng)應(yīng)用
  

5.調(diào)用scanPackageNewLI()繼續(xù)掃描

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

7.調(diào)用commitReconciledScanResultLocked()

scanPackageNewLI()

需要注意的是這個方法不僅僅是開機掃描的時候用，在安裝應(yīng)用的時候也是執(zhí)行的

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

scanPackageOnlyLI()

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

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

reconcilePackagesLocked()

先說一下幾個參數(shù):

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

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

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

commitReconciledScanResultLocked()

這里面也是安裝應(yīng)用和掃描應(yīng)用同時都會調(diào)用的方法，先只看掃描的情況

1. 處理PackageSetting，這部分邏輯是和安裝應(yīng)用是混在一起的，主要包括
   1. SharedUserSetting, 這個一般只有覆蓋安裝的時候如果sharedUserId變了，要重新賦值
   2. 重命名包名的邏輯，安裝重命名包名的時候會更新packages.xml文件
2. 將PackageSetting寫入package-restrictions.xml，里面主要存儲的是disabled和enabled四大組件
3. 最后調(diào)用commitPackageSettings()進行最后一步處理
   

commitPackageSettings()

1. 判斷是不是有廠商自定義的ResolveActivity(config_customResolverActivity屬性)，如果有則調(diào)用setUpCustomResolverActivity()設(shè)置ResolveActivity為自定義的，ResolveActivity就是處理未指定的android.action.View的
2. 處理ResolveActivity，如果沒有的話指定為framework的ResolveActivity
3. 更新SharedLibraries，這部分還不太熟悉
4. 檢查是否需要frozen應(yīng)用，如果需要但沒有frozen則退出安裝，有以下幾種情況無需frozen應(yīng)用
   1. SCAN_BOOTING，開機的時候，因為這時沒有應(yīng)用啟動的了
   2. SCAN_DONT_KILL_APP，安裝不殺死應(yīng)用，這個一般要么在PkMS中指定，要么在adb安裝的時候指定
   3. SCAN_IGNORE_FROZEN，忽略FROZEN，這個連adb也沒有指定選項，可能是代碼遺留
5. 調(diào)用mSettings.insertPackageSettingLPw()，這里并非是更新packages.xml的地方，只是將pkgSetting，放到Settings.mPackages中
6. 將AndroidPackage放到mPackages中
7. 更新KeySetManagerService的應(yīng)用信息，這是一個管理簽名的服務(wù)
8. 添加自定義的Permission和PermissionGroup到PermissionManagerService中
9. 添加保護廣播，但這個并非給安裝應(yīng)用使用，而是系統(tǒng)應(yīng)用，例如：teleservice等
10. 對于老的package或者Permission更新的需要對于申請了這些權(quán)限的應(yīng)用更新權(quán)限，注意，這些權(quán)限也是由應(yīng)用定義的
    

掃描完成之后需要做的事情

1. 清除掉已刪除的系統(tǒng)應(yīng)用和disable原本就disable的應(yīng)用
2. 調(diào)用PermissionManagerService.updateAllPermissions()更新權(quán)限，這部分是在所有應(yīng)用掃描完成之后才執(zhí)行
3. 創(chuàng)建應(yīng)用數(shù)據(jù)存儲的目錄，注意這里只是針對system core應(yīng)用(如SystemUI)做的操作，data下的應(yīng)用由于有多用戶的存在，每個data應(yīng)用是針對單個用戶的，
4. 最終將PackageSetting和permission以及簽名的fingerprint寫入到packages.xml當中，這里這樣設(shè)計我覺得應(yīng)該是怕中途關(guān)機，這樣一次性寫入所有的信息可以盡量減少寫了一半關(guān)機的情況

以上就是Android 開機應(yīng)用掃描相關(guān)總結(jié)的詳細內(nèi)容，更多關(guān)于Android 開機應(yīng)用掃描的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論