平台：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架构确定顺序
- 如果apk包中lib文件夹下有.so库，就根据这个.so库的架构模式，确定app的primaryCpuAbi的值
- 2.对于system app, 如果没法通过第一步确定primaryCpuAbi的值，PKMS会根据/system/app/
{APP_NAME}/lib64这两个文件夹是否存在，来确定它的primaryCpuAbi的值
- 3.对于还没有确定的app, 在最后还会将自己的primaryCpuAbi值与和他使用相同UID的package的值设成一样
- 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
网友评论