故事的开始
明天老大急冲冲的跑过来说：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.access$500(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 的利用可能共享权限
所有查看权限的最初步骤都是通过调用 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 /*pkgFlags*/, 0 /*pkgPrivateFlags*/, true /*create*/);
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 ParseResult<ParsingPackage> parseSharedUser(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,
"<manifest> 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$22$PackageManagerService:14802, PackageManagerService (com.android.server.pm)
run:-1, -$$Lambda$PackageManagerService$9znobjOH7ab0F1jsW2oFdNipS-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 不为空，都是非法的。
/**
* Verifies that signatures match.
* @returns {@code true} if the compat signatures were matched; otherwise, {@code false}.
* @throws PackageManagerException if the signatures did not match.
*/
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 调试，而后把这个包卸载掉。
最初分享下搜集整理的 Android 开发相干学习材料，点击这里查看全副