第三方apk内置因签名导致SystemUI未启动启动问题案例分析

2022-04-26 13:10:39

这个问题是刷完机正常开机后，发现手机无状态栏，下拉通知栏，按音量键也无法出现VolumeDialog，开始看到这个现象感觉是systemUI未编译到版本中去？或者是在systemserver中systemUI的服务为启动？因发现问题的版本是userdebug版本，未抓到第一次开机log，问题也没法定位。

分析该问题的时候，首先我们是从提交记录开始排查，因9月8号出的版本是没问题的，9月9号编译的版本就有问题，9.8日到9.9的提交记录不足10条，frameworks/base下的提交只有两条是我修改VolumeDialog中调节音量滑动条显示问题。为了快速定位问题，我们一边回退修改编译版本复现，查看是哪条提交记录引起的问题，一边抓log分析。Userdebug版本第一次开机后进设置手动打开adb，再次开机就可以抓到android log了。开始怀疑是这里造成systemUI报错，但是很快就排除了这种情况，因为如果这里报错的话，log中肯定能直接打印出来错误信息，但是这里修改添加的log一句都没有打印出来，而且从该问题的现象看，不像是systemUI报错，倒更像是systemUI没有这个应用。接着，adb shell进入system/priv-app，惊奇的发现，systemUI.apk赫然存在于我们系统中，那么此时就能排除systemUI未编译到我们的版本中这种情况。那么只剩下一种情况，就是systemUI存在于系统中，但是并没有启动。为了证实这个猜测，我们去Log里面查看，发现有如下Log:

01-01 08:15:40.318 960 960 I PackageManager: /system/priv-app/SystemUI changed; collecting certs

01-01 08:15:40.540 960 960 W PackageManager: Failed to parse /system/priv-app/SystemUI: Signature mismatch for shared user : SharedUserSetting{a250832 android.uid.systemui/10009}

01-01 08:15:40.540 960 960 D PackageManager: scan package: /system/priv-app/SystemUI , end at: 15322ms. elapsed time = 241ms.

01-01 08:15:43.864 960 960 E BluetoothManagerService: Unable to resolve SystemUI's UID.

01-01 08:15:43.864 960 960 E BluetoothManagerService: android.content.pm.PackageManager$NameNotFoundException: com.android.systemui

其中有关键两句：

01-01 08:15:40.540 960 960 W PackageManager: Failed to parse /system/priv-app/SystemUI: Signature mismatch for shared user : SharedUserSetting{a250832 android.uid.systemui/10009}

01-01 08:15:40.540 960 960 D PackageManager: scan package: /system/priv-app/SystemUI , end at: 15322ms. elapsed time = 241ms.

packageManager在扫描解析systemUI应用报错，所以并没有将systemUI真正添加到系统中（并没有将systemUI中对应的四大组件等信息解析到对应的数据结构中），因此在后面的log中也可以看到凡是要打开systemUI中相关类的地方，都会报NameNotFoundException异常。而此时，通过回退修改记录已经确认到是哪条提交记录引入了该问题。即SPM修改了内置的第三方应用的签名，有将四个应用的签名从系统签名修改成不签名，即使用的是应用本身的签名引入了该问题。再看看报错原因：Failed to parse /system/priv-app/SystemUI: Signature mismatch for shared user : SharedUserSetting{a250832 android.uid.systemui/10009}

提示的是systemUI的签名和共享进程android.uid.systemui不匹配，而SystemUI使用的是android.uid.systemui进程，签名用的是系统签名。那么问题来了，为什么修改第三方应用的签名（从系统签名修改成无签名，第三方自己的签名），会导致SystemUI的签名和进程名不匹配了？

原因只有一个，肯定是内置的第三方应用中（该提交记录中的四个应用中）至少有一个于SystemUI共享进程（可能通过指定process属性或者sharedUserId的方式让该应用和systemUI跑在了同一个进程中），但是签名不是使用的系统签名。为了证实自己的猜测，我们将第三方apk反编译，查看AndroidManifest.xml文件。在FloatButton.apk反编译的AndroidManifest.xml中果然有android:shareUserId=”android.uid.systemui”.因此FloatButton.apk必须要使用系统签名。至此，该问题的解决方法已经明了，只需要将FloatButton.apk的签名修改成系统签名即可。到这里，其实还有个疑问，那FloatButton.apk的签名和SystemUI的签名不同，为什么会导致SystemUI扫描时报异常而不是FloatButton.apk扫描报异常？其实很简单，原因是packageManagerService先扫描解析了FloatButton.apk，认为android.uid.systemui进程对应的签名是FloatButton.apk自己的签名，然后再扫描SystemUI.apk时，发现SystemUI的签名和android.uid.systemui不对应，所以就为将SystemUI扫描到系统中来。从log中可证实这一点：FloatButton.apk的扫描是在

01-01 08:15:39.457 960 960 D PackageManager: scan package: /system/priv-app/FloatButton , end at: 14239ms. elapsed time = 20ms

而SystemUI.apk的扫描是在：

01-01 08:15:40.540 960 960 D PackageManager: scan package: /system/priv-app/SystemUI , end at: 15322ms. elapsed time = 241ms.

同时从刷完机后，也可以看大，systemUI不能运行，但是FloatButton.apk中，除了需要调用到SystemUI中的一些功能无法正常运行以外，其他功能都可以正常运行。这一点也可以证实我们的猜测。

问题反思：

修改问题后，去packageManagerService.java的scanPackageDirtyLI()中看到有如下代码：

// However... if this package is part of a shared user, but it

// doesn't match the signature of the shared user, let's fail.

// What this means is that you can't change the signatures

// associated with an overall shared user, which doesn't seem all

// that unreasonable.

if (pkgSetting.sharedUser != null) {

if(compareSignatures(pkgSetting.sharedUser.signatures.mSignatures,

pkg.mSignatures) != PackageManager.SIGNATURE_MATCH) {

throw new PackageManagerException(

INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES,

"Signature mismatch for shared user : "

+ pkgSetting.sharedUser);

}

即当一个应用如果想通过sharedUserId的方式与另一个应用运行于同一个进程当中，这两个应用的签名必须保持一致。那么在第三方应用内置时，若第三方没有告诉我们该应用需要什么签名时，可反编译看一下该应用是否有通过sharedUserId与其他应用运行于同一进程，以防止类似问题。

码农公寓

相关文章