那么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)专门设计的,并不具备普遍性,安装的应用及时加了标签也还是会被认为是两个应用
-
对于覆盖安装系统应用的data区应用进行处理,什么是覆盖安装系统应用?即系统应用有更新,可以通过应用商店下载覆盖安装,但是并不会去卸载系统应用,而是disable系统应用,例如:Google的gms应用都是如此
-
如果安装的应用出现问题了,重新enable被disabled应用
-
如果是系统更新的应用,则需要扫描disabled系统应用,因为可能会有OTA升级导致系统应用更新apk的情况,调用
scanPackageOnlyLI()
,进行扫描,后面还会分析 -
接下来是根据disabled系统应用和安装应用的版本号,判断是否需要重新使用系统应用
-
处理签名,对于安装的应用,必须要签名
-
确认是否需要重新签名,对于非系统应用来说,无需重新收集,这部分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 installation
final boolean skipVerify = scanSystemPartition
|| (forceCollect && canSkipForcedPackageVerification(parsedPackage));
collectCertificatesLI(pkgSetting, parsedPackage, forceCollect, skipVerify);
-
还要处理一下第三步的反方向,即一开始有个安装的应用(data分区),而后OTA升级有添加了该系统应用(system或其他分区),分为三种情况进行讨论
-
签名不相同,则卸载data分区的应用
-
如果系统应用的版本号更高,则移除data分区的应用,但保留应用的数据
-
如果系统应用的版本号更低,则将
shouldHideSystemApp
设置为true,也就是将在下面disable系统应用 -
调用
scanPackageNewLI()
继续扫描 -
调用
reconcilePackagesLocked()
进行一致化处理 -
调用
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库 -
获取标签,这个我不知道是干嘛的,目前还没遇到这种标签
-
更新或创建新的
PackageSetting
,创建的情况有两种,首次安装应用或者是恢复出厂开机 -
根据第一步获取的
needToDeriveAbi
获取abi的类型并设置到PackageSetting中,另外就是要解析apk中的native so库,并获取对应so库的路径,这里有个SCAN_NEW_INSTALL
flag,这个是给安装用的,开机scan是不会有此问题 -
设置安装的时间戳,主要是第一次安装和当前安装,目前不知道这个属性的用处
-
创建
ScanResult
并返回
reconcilePackagesLocked
先说一下几个参数:
-
ReconcileRequest
,放置需要的参数,allPackages->mPackages, scannedPackages->scanPackageOnlyLI()返回的ScanResult,sharedLibrarySource->mSharedLibraries解析之后才会进行push -
KeySetManagerService
签名管理服务
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级安卓工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Android)
Pp-1710916071497)]
[外链图片转存中…(img-5r0QY3NF-1710916071497)]
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Android)
[外链图片转存中…(img-sNnheOh2-1710916071498)]