Android 开机应用扫描

addForInitLI

逻辑相当的复杂，考虑情况也要很多，有些自己也没搞懂，只挑能说的说一下

1. 首先重命名包名的逻辑，在PkMS当中所有的package都是按照包名作为唯一的主键值，那么就可能出现应用需要更换包名的情况，PkMS给出解决方案是加上<original-package android:name="com.android.oldpackagename" />指明需要覆盖安装的包名，但是这样就需要考虑到诸多情况了

2. 包名修改多次怎么办

3. 之前有安装过老包名的应用的处理情况

4. 之前未安装过老包名的应用的处理情况

5. 之前安装过当前包名的应用的处理情况

那么PkMS是怎么做的呢？

1. 设计了一个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);

}

复制代码

2. 然后在addForInitLI()中根据realPkgName获取originalPkgSetting

3. 接下来判断是否要覆盖安装应用

不过我感觉里面还是有些bug，似乎只是为了用gms应用替换AOSP里面的应用(如：PackageInstaller和PermissionController)专门设计的，并不具备普遍性，安装的应用及时加了标签也还是会被认为是两个应用

2. 对于覆盖安装系统应用的data区应用进行处理，什么是覆盖安装系统应用？即系统应用有更新，可以通过应用商店下载覆盖安装，但是并不会去卸载系统应用，而是disable系统应用，例如:Google的gms应用都是如此

3. 如果安装的应用出现问题了，重新enable被disabled应用

4. 如果是系统更新的应用，则需要扫描disabled系统应用，因为可能会有OTA升级导致系统应用更新apk的情况，调用scanPackageOnlyLI()，进行扫描，后面还会分析

5. 接下来是根据disabled系统应用和安装应用的版本号，判断是否需要重新使用系统应用

6. 处理签名，对于安装的应用，必须要签名

7. 确认是否需要重新签名，对于非系统应用来说，无需重新收集，这部分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);

2. 是否跳过签名验证，这个是覆盖安装时候使用

// 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. 还要处理一下第三步的反方向，即一开始有个安装的应用(data分区)，而后OTA升级有添加了该系统应用(system或其他分区)，分为三种情况进行讨论

5. 签名不相同，则卸载data分区的应用

6. 如果系统应用的版本号更高，则移除data分区的应用，但保留应用的数据

7. 如果系统应用的版本号更低，则将shouldHideSystemApp设置为true，也就是将在下面disable系统应用

8. 调用scanPackageNewLI()继续扫描

9. 调用reconcilePackagesLocked()进行一致化处理

10. 调用commitReconciledScanResultLocked()

scanPackageNewLI

需要注意的是这个方法不仅仅是开机扫描的时候用，在安装应用的时候也是执行的

1. 再次处理重命名包名，这个应该和安装有关系，我测试的时候是覆盖安装系统应用有效，普通应用无法生效，会被认为是两个应用

2. 调用adjustFlags()重新调整scanFlags，分为以下几种情况

3. 重命名包名应用或者覆盖安装的应用是系统应用，scanFlags添加上SCAN_AS_SYSTEM以及可能的其他flags

4. 如果sharedUserId是包含了privilege应用，则正在扫描的应用也要加上SCAN_AS_PRIVILEGED

5. 获取SharedUserSetting，这个在addForInitLI()获取过一次，是为了扫描disabledPkgSetting获取的

6. 构建ScanRequest并且调用scanPackageOnlyLI()获取ScanResult

scanPackageOnlyLI

这部分主要的逻辑是更新packageSetting和nativelibrary的解析

1. 确定是否需要获取abi(needToDeriveAbi)，如果packageSetting，如果应用已安装，则无需更改cpuAbi，如果未安装，则需要解析native库

2. 获取标签，这个我不知道是干嘛的，目前还没遇到这种标签

3. 更新或创建新的PackageSetting，创建的情况有两种，首次安装应用或者是恢复出厂开机

4. 根据第一步获取的needToDeriveAbi获取abi的类型并设置到PackageSetting中，另外就是要解析apk中的native so库，并获取对应so库的路径，这里有个SCAN_NEW_INSTALLflag，这个是给安装用的，开机scan是不会有此问题

5. 设置安装的时间戳，主要是第一次安装和当前安装，目前不知道这个属性的用处

6. 创建ScanResult并返回

reconcilePackagesLocked

先说一下几个参数:

1. ReconcileRequest，放置需要的参数，allPackages->mPackages, scannedPackages->scanPackageOnlyLI()返回的ScanResult，sharedLibrarySource->mSharedLibraries解析之后才会进行push

2. KeySetManagerService签名管理服务

reconcilePackagesLocked()也会被安装应用的流程调用，所以ReconcileRequest的参数有些是为了给它们用的，这个方法的主要功能就是为了校验签名

1. 首先检查签名是否需要更新ksms.shouldCheckUpgradeKeySetLocked(signatureCheckPs, scanFlags)，这个不太能理解，签名是可以更新的？

2. 调用verifySignatures()进行校验签名

3. 最后生成ReconciledPackage并返回

commitReconciledScanResultLocked

这里面也是安装应用和扫描应用同时都会调用的方法，先只看扫描的情况

1. 处理PackageSetting，这部分逻辑是和安装应用是混在一起的，主要包括

2. SharedUserSetting, 这个一般只有覆盖安装的时候如果sharedUserId变了，要重新赋值

3. 重命名包名的逻辑，安装重命名包名的时候会更新packages.xml文件

4. 将PackageSetting写入package-restrictions.xml，里面主要存储的是disabled和enabled四大组件

5. 最后调用commitPackageSettings()进行最后一步处理

commitPackageSettings

1. 判断是不是有厂商自定义的ResolveActivity(config_customResolverActivity属性)，如果有则调用setUpCustomResolverActivity()设置ResolveActivity为自定义的，ResolveActivity就是处理未指定的android.action.View的

2. 处理ResolveActivity，如果没有的话指定为framework的ResolveActivity

3. 更新SharedLibraries，这部分还不太熟悉

4. 检查是否需要frozen应用，如果需要但没有frozen则退出安装，有以下几种情况无需frozen应用

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

最后

下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。希望能够帮助到大家提升技术

高级UI，自定义View

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。

不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

)]

高级UI，自定义View

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。

不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

[外链图片转存中…(img-Twf6fLDK-1712824147806)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-smA2TzHX-1712824147806)]