Android内置系统apk问题

平台:Rockchip
android版本: 7.1
个人博客:https://www.letcos.top/

1.问题描述

​ 一款产品需要内置定制的launcher,使用了一些第三方的sdk。按系统app的内置方法,增加share system uid获得系统权限。但是在使用的过程中大概率会出现系统应用setting(设置)闪退。并伴随录音服务挂掉,密钥链等问题(开始以为是独立的 bug,后面分析都是内置系统apk引起的问题)。

2. 分析思路

2.1 分析

查看logcat ,下面是关键log

03-12 10:48:50.247 1381 1381 E AndroidRuntime: Process: com.android.settings, PID: 1381
03-12 10:48:50.247 1381 1381 E AndroidRuntime: java.lang.RuntimeException: Unable to instantiate application com.android.settings.SettingsApplication: java.lang.ClassNotFoundException: Didn’t find class “com.android.settings.SettingsApplication” on path: DexPathList[[zip file “/system/priv-app/Settings/Settings.apk”],nativeLibraryDirectories=[/system/priv-app/Settings/lib/arm64, /system/priv-app/Settings/Settings.apk!/lib/armeabi-v7a, /system/lib, /vendor/lib, /system/lib, /vendor/lib]]

setting apk找不到32位的库,所以运行会闪退。那看一下系统内置的setting是多少位的。

//查看系统apk信息
adb shell dumpsys package p > dumpsys_p

在 dumpsys_P中找到setting的primaryCpuAbi=arm64-v8a,可见setting是64位apk。由于setting是64位apk,而且没有编译32位库,所以找不到32位库闪退就很好解释了。现在的问题是为什么64位的setting apk会到32位的目录下去找所需要的库?

 Package [com.android.settings] (f0c9a0e):
    userId=1000
    sharedUser=SharedUserSetting{f9d70ba android.uid.system/1000}
    pkg=Package{3232b02 com.android.settings}
    codePath=/system/priv-app/Settings
    resourcePath=/system/priv-app/Settings
    legacyNativeLibraryDir=/system/priv-app/Settings/lib
    primaryCpuAbi=arm64-v8a
    secondaryCpuAbi=null
    versionCode=25 minSdk=25 targetSdk=25
    versionName=7.1.2
    splits=[base]	
    ...

通过对比安装 launcher app挂掉之前和之后发现以下13个系统app被强制从64bit改到了32bit

package:/system/app/KeyChain/KeyChain.apk=com.android.keychain  //可能导致密钥链问题
package:/system/app/SoundRecorder/SoundRecorder.apk=com.android.soundrecorder //可能导致语音挂掉问题
package:/system/priv-app/SettingsProvider/SettingsProvider.apk=com.android.providers.settings
package:/system/app/RkExplorer/RkExplorer.apk=com.android.rk
package:/system/priv-app/InputDevices/InputDevices.apk=com.android.inputdevices
package:/system/priv-app/Telecom/Telecom.apk=com.android.server.telecom
package:/system/app/MediaFloat/MediaFloat.apk=com.android.rk.mediafloat
package:/system/priv-app/StressTest/StressTest.apk=com.cghs.stresstest
package:/system/priv-app/Settings/Settings.apk=com.android.settings
package:/system/app/WallpaperBackup/WallpaperBackup.apk=com.android.wallpaperbackup
package:/system/priv-app/FusedLocation/FusedLocation.apk=com.android.location.fused
package:/system/priv-app/DeviceTest/DeviceTest.apk=com.DeviceTest
package:/system/priv-app/FusedLocation/FusedLocation.apk=com.android.location.fused

不仅找到setting 被强制改为32位,还有13个apk也被修改为了32位。其中正好有之前遇到了2个问题:报密钥链错误和语音服务失效。原来这几个问题的根本原因都是我们内置app 使用了32位库,所有apk被判定位32位;而作为系统app,使用了系统的systemuid,由于andorid的机制规定一个进程只能是32位或64位中的一种,所有使用systemuid的apk都因为内置了launcher apk而强制变成32位。由于系统内置的64位apk没有对应的32位库,所有会闪退。

2.2 原理简介

android加载so文件的机制
apk在安装的过程中,系统就会对apk进行解析根据app的primaryCpuAbi值,确定这个apk安装是在32还是64位的虚拟机上,如果是32位虚拟机那么就不能使用64位so,如果是64位虚拟机也不能使用32位so。

而64位设备可以提供32和64位两种虚拟机,根据apk选择开启哪一种,因此说64位设备兼容32的so库。具体来说就是apk在安装的时候,apk解包的时候,就已经确定要加载多少位的库了,如果apk里面放有两种库,实际用的时候,也是只会加载一种库。

apk架构确定顺序

  1. 如果apk包中lib文件夹下有.so库,就根据这个.so库的架构模式,确定app的primaryCpuAbi的值
  2. 2.对于system app, 如果没法通过第一步确定primaryCpuAbi的值,PKMS会根据/system/app/ A P P N A M E / l i b 和 / s y s t e m / a p p / {APP_NAME}/lib和/system/app/ APPNAME/lib/system/app/{APP_NAME}/lib64这两个文件夹是否存在,来确定它的primaryCpuAbi的值
  3. 3.对于还没有确定的app, 在最后还会将自己的primaryCpuAbi值与和他使用相同UID的package的值设成一样
  4. 4.对于到这里还没有确认primaryCpuAbi的app,就会在启动进程时使用ro.product.cpu.abilist这个property的值的第一项作为它关联的ABI

3. 解决方案

基于android加载so文件的机制,我们可以采用一下几种方法来解决该问题

  • apk不使用系统的uid,自己新增一个具有系统权限的uid(比较麻烦)

  • 把我们的apk修改为64位的,将所有使用的32位so替换为64位(可能有些三方so不提供64位版本)

  • 把所有32位库再封装一次,做成jar包,然后使用这些jar包。(需要自己封装)

  • 将所有32位库服务抽离出来,单独运行一个(或多个)进程。(需要提前确定好app的架构,不然需要重构app)

  • 在系统apk(例如:Settings)安装位置system/priv-app/xxx/目录下面建立一个lib/arm64文件夹.(利用apk架构确定顺序强制将系统apk变为64位)

  • 将系统apk编译为32位(可能影响性能)

    		a.在apk对应的android.mk中 LOCAL_DEX_PREOPT := nostripping
    		b./device/rockchip/rk3399/BoardConfig.mk,DEX_PREOPT_DEFAULT := nostripping
    

参考链接:

https://blog.csdn.net/weiqifa0/article/details/88432165

4.其他问题

4.1 系统签名

​ 当一个应用如果想通过sharedUserId的方式与另一个应用运行于同一个进程当中,这两个应用的签名必须保持一致。所以我们内置系统apk的时候需要使用系统签名。

​ apk系统签名可以参考:https://www.jianshu.com/p/63d699cffa1a

4.2 API版本过高

如果我们内置的API版本过高,那么在内置编译的时候会报错,这是由于odex机制的原因。

apk要预置进源码的时候,会对apk进行一个解析,好形成odex文件加速apk的运行,但是基于高版本的sdk开发的apk里面的一些资源是无法被低版本正确的解析

解决方法:

  • 降低apk 的API版本然后重新编译,保持和系统的API版本一致。(这样可能导致app某些功能不可用)
  • 关闭apk odex优化。(导致启动速度变慢)

在对应apk的Android.mk 文件中添加

LOCAL_DEX_PREOPT := false
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页