今天老大急冲冲的跑过来说：xx，你帮我看看这手机咋回事，突然开不了机。
我心想：我最近也没提过代码，应该不是我的问题吧。（甩锅.）
把电脑插上手机后，我看到下面这段报错一直在loop
12-31 16:08:49.603 21899 21899 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main
12-31 16:08:49.603 21899 21899 E AndroidRuntime: java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: {com.xxx.xxx.xxxxx (/data/app/~~BR9Kz0rmscIpqqvqBf8jwg==/com.xxx.xxx.xxxxx-fLGzzHKkZaTB5_DLxgo_Fg==): android.permission.BACKUP, com.xxx.xxx.xxxxx (/data/app/~~BR9Kz0rmscIpqqvqBf8jwg==/com.xxx.xxx.xxxxx-fLGzzHKkZaTB5_DLxgo_Fg==): android.permission.UPDATE_DEVICE_STATS}
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.pm.permission.PermissionManagerService.systemReady(PermissionManagerService.java:4688)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.pm.permission.PermissionManagerService.access0(PermissionManagerService.java:181)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.pm.permission.PermissionManagerService$PermissionManagerServiceInternalImpl.systemReady(PermissionManagerService.java:4771)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.pm.PackageManagerService.systemReady(PackageManagerService.java:22183)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.SystemServer.startOtherServices(SystemServer.java:2305)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.SystemServer.run(SystemServer.java:624)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.server.SystemServer.main(SystemServer.java:440)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
12-31 16:08:49.603 21899 21899 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
看完之后我立马回答：老大，这个我知道，一定是系统应用组的同学忘记在privapp-permissions-platform.xml文件下面加权限声明了。
老大：不会呀，这个手机我一直在用，后面突然就变成这样了。
此刻的我一脸懵逼：还有如此神奇之事。故事的开始便是这样，接下来我就开始调查这个神奇的现象。
万恶之源《众 所 周 知》
手机开机会检查priv-app的权限是否和/etc/permissions/privapp-permissions-platform.xml（有可能在别的文件夹下，例如vendor/etc/permissions，也有可能叫其他名字，因为只要xml的节点是对的就行，pm中的SystemConfig会对这类文件夹的所有xml进行扫描）所声明的权限是否一样，不一样则无法开机，就会一直loop上面的crash。
先从log中的PermissionManagerService#systemReady方法入手
private void systemReady() {
mSystemReady = true;
// 万恶之源
if (mPrivappPermissionsViolations != null) {
throw new IllegalStateException("Signature|privileged permissions not in "
+ "privapp-permissions whitelist: " + mPrivappPermissionsViolations);
}
// ...
}
只要mPrivappPermissionsViolations这个数组中有数据，我们就永远无法开机，看看这个数组是怎么填充的。
private boolean grantSignaturePermission(String perm, AndroidPackage pkg,
PackageSetting pkgSetting, basePermission bp, PermissionsState origPermissions) {
// ...
if (!privappPermissionsDisable && privilegedPermission && pkg.isPrivileged()
&& !platformPackage && platformPermission) {
if (!hasPrivappWhitelistEntry(perm, pkg)) {
if (!mSystemReady
&& !pkgSetting.getPkgState().isUpdatedSystemApp()) {
ApexManager apexMgr = ApexManager.getInstance();
String apexContainingPkg = apexMgr.getActiveApexPackageNameContainingPackage(
pkg);
if (apexContainingPkg == null || apexMgr.isFactory(
apexMgr.getPackageInfo(apexContainingPkg, MATCH_ACTIVE_PACKAGE))) {
// ... 进行和xml声明的权限进行对比... 发现在黑名单找到这个perm的或者在白名单找不到这个perm
// 一律加到开机防火墙（我自己想的名字0.0）中
if (permissionViolation) {
Slog.w(TAG, "Privileged permission " + perm + " for package "
+ pkg.getPackageName() + " (" + pkg.getCodePath()
+ ") not in privapp-permissions whitelist");
if (RoSystemProperties.CONTROL_PRIVAPP_PERMISSIONS_ENFORCE) {
if (mPrivappPermissionsViolations == null) {
mPrivappPermissionsViolations = new ArraySet<>();
}
mPrivappPermissionsViolations.add(
pkg.getPackageName() + " (" + pkg.getCodePath() + "): "
+ perm);
}
} else {
return false;
}
}
// ....
}
}
}
}
}
看完这里，我有一个疑问，一个普通的App怎么会有如此大的影响（小身材大力量？），可以看到上面各种条件判断才能走到这个校检权限声明的码块里。而这其中的一个条件引起了我的注意—pkg.isPrivileged()，这个为true则说明这是一个priv-app，而priv-app一般都是内置在系统内作为系统软件，还能在外部安装？（可能是我见识太少了 丢人~~）。
与之关联的是一个scanFlag叫SCAN_AS_PRIVILEGED，这个在开机扫描的时候就经常使用，对一个指定的系统内部路径scan的时候加上SCAN_AS_PRIVILEGED，这个路径下面所有的包都是priv-app。果不其然，当我找这个flag的使用时候，发现PMS的其他地方也会给一个包附上这个flag，就在PMS#adjustScanFlags方法中。
// 对和priv-app进行sharedUser的应用也要像priv-app一样扫描
final boolean skipVendorPrivilegeScan = ((scanFlags & SCAN_AS_VENDOR) != 0)
&& getVendorPartitionVersion() < 28;
if (((scanFlags & SCAN_AS_PRIVILEGED) == 0)
&& !pkg.isPrivileged()
&& (pkg.getSharedUserId() != null)
&& !skipVendorPrivilegeScan) {
SharedUserSetting sharedUserSetting = null;
try {
sharedUserSetting = mSettings.getSharedUserLPw(pkg.getSharedUserId(), 0,
0, false);
} catch (PackageManagerException ignore) {
}
if (sharedUserSetting != null && sharedUserSetting.isPrivileged()) {
// 豁免使用平台密钥签名的SharedUsers。
// TODO（b / 72378145）修复此豁免。
// 强制签名应用程序像其他priv-apps一样将其特权许可列入白名单。
synchronized (mLock) {
PackageSetting platformPkgSetting = mSettings.mPackages.get("android");
if ((compareSignatures(platformPkgSetting.signatures.mSigningDetails.signatures,
pkg.getSigningDetails().signatures)
!= PackageManager.SIGNATURE_MATCH)) {
scanFlags |= SCAN_AS_PRIVILEGED;
}
}
}
}
而在PMS#adjustScanFlags方法中，给和priv-app sharedUser的应用 append 上SCAN_AS_PRIVILEGED，让其也要强制加入到开机检查的白名单列表，所以google这是故意而为之。既然作为一个priv-app，开机检查权限也就成了理所当然了。所以我们为priv-app预置到系统的时候，要确定该priv-app有没有其他的sharedUserId应用，如果有的话，也要在权限白名单privapp-permissions-platform.xml中声明这个没有预置到系统的App申请的权限，否则装上去之后重启会造成loop crash。
为什么SharedUser的应用能够共享权限《 众 所 周 知》 * 2
所有检查权限的最后步骤都是通过调用PackageSettings中的getPermissionsState()获取App的权限获取状态，代码如下：
@Override
public PermissionsState getPermissionsState() {
return (sharedUser != null)
? sharedUser.getPermissionsState()
: super.getPermissionsState();
}
如果Package的PackageSettings的sharedUser不为空，则默认用sharedUser的权限。所以SharedUser的应用能互相共享大家已有的权限，且一个权限授予了，在这个SharedUser的其他包都会默认授予这个权限。做系统应用的同学可能比较了解，只要在manifest.xml中声明android:sharedUserId=“android.uid.system”，就能获取并使用其他同属于android.uid.systemSharedUser组的其他权限。
SharedUser怎样被赋值到PackageSettings上 我们先来看看PMS#scanPackageNewLI方法中的这个地方，也就值sharedUser赋值的地方。
SharedUserSetting sharedUserSetting = null;
if (parsedPackage.getSharedUserId() != null) {
// SIDE EFFECTS; may potentially allocate a new shared user
sharedUserSetting = mSettings.getSharedUserLPw(parsedPackage.getSharedUserId(),
0 , 0 , true );
if (DEBUG_PACKAGE_SCANNING) {
if ((parseFlags & PackageParser.PARSE_CHATTY) != 0)
Log.d(TAG, "Shared UserID " + parsedPackage.getSharedUserId()
+ " (uid=" + sharedUserSetting.userId + "):"
+ " packages=" + sharedUserSetting.packages);
}
}
我们可以看到这里根据parsedPackage.getSharedUserId这个String类型的SharedUserId，就去pm.Settings中寻找属于这个package的SharedUserSetting了，也没有校验这个包的sharedUserId是否符合某些条件，例如签名之类的条件。
直到最后的PMS#commitPackageSettings（持久化PackageSettings到packages.xml文件中，安装包数据不再发生变化步骤），也没有对这个SharedUserSetting进行重新赋值，所以到这步我觉得应该是SharedUserId的问题。机智的我把想法就放在了这个SharedUserId的赋值流程上面了，一通查找之下，我找到了SharedUserId赋值的地方：ParsingPackageUtils#parseSharedUser
private static ParseResultparseSharedUser(ParseInput input, ParsingPackage pkg, TypedArray sa) { String str = nonConfigString(0, R.styleable.AndroidManifest_sharedUserId, sa); if (TextUtils.isEmpty(str)) { return input.success(pkg); } if (!"android".equals(pkg.getPackageName())) { ParseResult nameResult = validateName(input, str, true, true); if (nameResult.isError()) { return input.error(PackageManager.INSTALL_PARSE_FAILED_BAD_SHARED_USER_ID, " specifies bad sharedUserId name "" + str + "": " + nameResult.getErrorMessage()); } } return input.success(pkg .setSharedUserId(str.intern()) .setSharedUserLabel(resId(R.styleable.AndroidManifest_sharedUserLabel, sa))); }
上面这段代码很简单，大概的意思就是读取R.styleable.AndroidManifest_sharedUserId这个attribute中的内容，然后直接给它赋值到这个String类型的SharedUserId上面，也没有做合规检查。这时候不禁就有个疑问了，那我岂不是随便声明一个android:sharedUserId="xxx"就能获取到SharedUser的其他权限？这时候我打开了测试的test demo，给它加上android:sharedUserId属性，但没有成功安装成功，且报了INSTALL_FAILED_SHARED_USER_INCOMPATIBLE异常，往PMS那么一搜，啪的一下，很快就找到辣（但其实是找错了 因为报错不是在PMS中产生）。因为找错了的原因，我把安装的堆栈打了出来，发现报错其实是在PackageManagerServiceUtils#verifySignatures。
先把堆栈打出来
verifySignatures:689, PackageManagerServiceUtils (com.android.server.pm) reconcilePackagesLocked:16947, PackageManagerService (com.android.server.pm) installPackagesLI:17373, PackageManagerService (com.android.server.pm) installPackagesTracedLI:16696, PackageManagerService (com.android.server.pm) lambda$processInstallRequestsAsync$PackageManagerService:14802, PackageManagerService (com.android.server.pm) run:-1, -$$Lambda$PackageManagerServiceznobjOH7ab0F1jsW2oFdNipS-8 (com.android.server.pm) handleCallback:938, Handler (android.os) dispatchMessage:99, Handler (android.os) loop:223, Looper (android.os) run:67, HandlerThread (android.os) run:44, ServiceThread (com.android.server)
这也很符合逻辑，SharedUser中的其他包：你说你是我兄弟，那你就是我兄弟？拿你的签名跟我的对比一下，一样的才算我兄弟。毕竟在包管理中，一个包的签名相当于这个包的DNA了，只有经过同一个x509.pem和.pk8文件签名的apk的签名才会相同。
可以看到这里校验签名不匹配直接抛出了throw new PackageManagerException，终止安装流程，根本不给你安装成功的机会。所以并不需要置空SharedUserSetting或者SharedUserId，只要安装成功的Package且它们的SharedUserSetting不为空，都是合法的。
public static boolean verifySignatures(PackageSetting pkgSetting,
PackageSetting disabledPkgSetting, PackageParser.SigningDetails parsedSignatures,
boolean compareCompat, boolean compareRecover)
throws PackageManagerException {
final String packageName = pkgSetting.name;
boolean compatMatch = false;
// ...
// 检查是否匹配SharedUser的签名
if (pkgSetting.getSharedUser() != null
&& pkgSetting.getSharedUser().signatures.mSigningDetails
!= PackageParser.SigningDetails.UNKNOWN) {
// 已经存在的软件包。确保签名匹配。在签署证书轮换的情况下，
// 带有较新证书的软件包必须与较旧版本的sharedUserId保持一致。
// 我们检查是否新软件包是由较旧的证书签名的，可以使用当前的sharedUser签名，
// 还是由较新的证书签名，以及是否与现有的签名证书作为sharedUser签名，则可以。
boolean match =
parsedSignatures.checkCapability(
pkgSetting.getSharedUser().signatures.mSigningDetails,
PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID)
|| pkgSetting.getSharedUser().signatures.mSigningDetails.checkCapability(
parsedSignatures,
PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID);
// 如果sharedUserId功能检查失败，
// 则可能是由于这是sharedUserId中到目前为止唯一的包，
// 并且继承被更新以拒绝继承中先前密钥的sharedUserId功能。
if (!match && pkgSetting.getSharedUser().packages.size() == 1
&& pkgSetting.getSharedUser().packages.valueAt(0).name.equals(packageName)) {
match = true;
}
if (!match && compareCompat) {
match = matchSignaturesCompat(
packageName, pkgSetting.getSharedUser().signatures, parsedSignatures);
}
if (!match && compareRecover) {
match =
matchSignaturesRecover(packageName,
pkgSetting.getSharedUser().signatures.mSigningDetails,
parsedSignatures,
PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID)
|| matchSignaturesRecover(packageName,
parsedSignatures,
pkgSetting.getSharedUser().signatures.mSigningDetails,
PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID);
compatMatch |= match;
}
// 不配对 则抛异常 安装失败
if (!match) {
throw new PackageManagerException(INSTALL_FAILED_SHARED_USER_INCOMPATIBLE,
"Package " + packageName
+ " has no signatures that match those in shared user "
+ pkgSetting.getSharedUser().name + "; ignoring!");
}
// ...
}
return compatMatch;
}
最后
请大家注意好手机备份和软件来源的确认，如果有其他手机厂商“修复”了这个问题可以在评论区告知，AndroidQ和R都会存在这个问题，至于前面的版本就没一一确认了。我已经用这个apk搞坏了一台Google Pixel（泪目），普通用户大概也只能恢复出厂设置了，高级用户可以用串口打开USB调试，然后把这个包卸载掉。
文末我的库存，有需要以下资料的小伙伴请扫下方csdn官方二维码免费领取
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）