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

这个问题是刷完机正常开机后,发现手机无状态栏,下拉通知栏,按音量键也无法出现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 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与其他应用运行于同一进程,以防止类似问题。

以上纯属个人总结,可能有不对的地方,欢迎大家指正,共同分享~~ --------------------- 作者:天木楠 来源:CSDN 原文:https://blog.csdn.net/niexu19900104/article/details/52513832 版权声明:本文为博主原创文章,转载请附上博文链接!

上一篇:15分钟在阿里云Kubernetes服务上快速建立Jenkins X Platform并运用GitOps管理应用发布


下一篇:Android APK方式换肤实现原理