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/$AP{P}_{N}AME/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