写点什么

动态加载 so 注意事项 & 案例

用户头像
Android架构
关注
发布于: 51 分钟前

打包的时候以 app 下 build.gradle 支持的为准。


总之一定要保持 各个库之间对应的架构都是一一对应的。

不同 Android 设备架构的兼容情况

  • armeabi-v7a 设备能够加载 armeabi 指令的 so 文件

  • arm64-v8a 能兼容 armeabi-v7a 和 armeabi 指令集

  • x86_64 兼容 x86

  • mips64 兼容 mips


mips 系 的手机设备数量太少,在项目里基本上不考虑。

Google 提供给用户的 API

android.os.Build.SUPPORTED_ABIS


android.os.Build.CPU_ABI


android.os.Build. CPU_ABI2


这些变量用于查询设备支持的架构,其中 SUPPORTED_ABIS 是 API Level 21 引入来代替 CPU_ABI, CPU_ABI2 的。


  1. 如果目标平台的 API Level 小于 21,只能使用 CPU_ABI 要 CPU_ABI2 来选择了,而 CPU_ABI 要优于 CPU_ABI2。

  2. API Level >=21 的推荐使用 android.os.Build.SUPPORTED_ABIS,但是 21 以下只能使用 CPU_ABI 和 CPU_ABI2


测试下这几个变量的值


针对某一个固定的设备,如 Nexus 9 设备(arm64-v8a CPU 架构)


根据前面说描述 设备的兼容情况


SUPPORTED_ABIS 比较容易理解,返回 arm64-v8a,armeabi-v7a,armeabi


而 CPU_ABI 和 CPU-ABI2 的值不是固定不变的,它会根据 APK 打包的 jniLibs ,并根据设备支持的 abi 选择性安装,返回不同的值



所以 5.0(21)以上,推荐使用 android.os.Build.SUPPORTED_ABIS 判断获取设备支持的架构类型,而 5.0 以下则使用 android.os.Build.CPU_ABI 即可,android.os.Build.CPU_ABI2 的价值也不是很大。


activity.


《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
复制代码


getApplicationInfo().nativeLibraryDir 暂时未用到


4.4-> /data/app-lib/com.less.tplayer.baidu-15.0-> /mnt/asec/com.less.tplayer.baidu-2/lib/arm64

动态加载网络或文件夹下的 so 库

加载某文件夹 -> 相应架构的 so 文件


Apk 文件本身就是一个压缩文件,解压后目录结构大致如下:


某 apk 文件的解压目录

动态加载 so 案例

我先把完整的代码贴出来,然后讲解可能遇到的两个错误。


动态加载的核心类(根据 abi 从本地选择合适的 so 库加载)


public class DynamicSO {


private static final String TAG = DynamicSO.class.getSimpleName();


public static void loadExSo(Context context,String soName, String soFilesDir){


File soFile = choose(soFilesDir,soName);


String destFileName = context.getDir("myso", Context.MODE_PRIVATE).getAbsolutePath() + File.separator + soName;


File destFile = new File(destFileName);


if (soFile != null) {


Log.e(TAG, "最终选择加载的 so 路径: " + soFile.getAbsolutePath());


Log.e(TAG, "写入 so 的路径: " + destFileName);


boolean flag = FileUtil.copyFile(soFile, destFile);


if (flag) {


System.load(destFileName);


}


}


}


/**


  • 在网络或者本地下载过的 so 文件夹: 选择适合当前设备的 so 文件

  • @param soFilesDir so 文件的目录, 如 apk 文件解压后的 Amusic/libs/ 目录 : 包含[arm64-v8a,arm64-v7a 等]

  • @param soName so 库的文件名, 如 libmusic.so

  • @return 最终匹配合适的 so 文件


*/


private static File choose(String soFilesDir,String soName) {


if (Build.VERSION.SDK_INT >= 21) {


String [] abis = Build.SUPPORTED_ABIS;


for (String abi : abis) {


Log.e(TAG, "SUPPORTED_ABIS =============> " + abi);


}


for (String abi : abis) {


File file = new File(soFilesDir,abi + File.separator + soName);


if (file.exists()) {


return file;


}


}


} else {


File file = new File(soFilesDir, Build.CPU_ABI + File.separator + soName);


if (file.exists()) {


return file;


} else {


// 没有找到和 Build.CPU_ABI 匹配的值,那么就委屈设备使用 armeabi 算了.


File finnalFile = new File(soFilesDir, "armeabi" + File.separator + soName);


if (finnalFile.exists()) {


return finnalFile;


}


}


}


return null;


}


}


动态调用 so 的函数,不需要 System.loadLibrary.


public class Security {


public native String stringFromJNI();


}


测试类,我的需要加载的 so 文件都是放在 sdcard/mylibs 目录下的。


public class TestActivity extends AppCompatActivity {


public void handle(View view) {


DynamicSO.loadExSo(this,"libnative-lib.so", Environment.getExternalStorageDirectory() + "/mylibs");


// JNI 调用


Security security = new Security();


String message = security.stringFromJNI();


Toast.makeText(this, message, Toast.LENGTH_LONG).show();


}


}

常见错误

  1. Exception: dlopen failed: "/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so" has bad ELF magic

  2. E/art: dlopen("/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so", RTLD_LAZY) failed: dlopen failed: "/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so" is 32-bit instead of 64-bit

  3. E/art: dlopen("/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so", RTLD_LAZY) failed: dlopen failed: "/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so" is 64-bit instead of 32-bit


【错误 1】非常简单,但却耗费我一晚上都没找到错误,Google 搜到的也是不相干的,错误提示太坑了,什么是精灵魔法??我还以为是 5.0 版本问题,然后测试 4.0,然后以为 so 的写入目录有问题,然后。。。


byte[] bytes = new byte[1024];


int len = -1;


while ( (len = bufferedInputStream.read(bytes)) != -1) {


bufferedOutputStream.write(bytes, 0, len);


}


拐了一大圈,最后是


bufferedInputStream.read(bytes)


bufferedInputStream.read()


TNN 的,啥时候 bytes 丢了!!!


这个不起眼的小错误差点搞得我放弃这个知识点。


上面的粗心大意的错误终于解决了,却又出现了下面的错误,真坑!


【错误 2】


E/art: dlopen("/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so", RTLD_LAZY) failed: dlopen failed: "/data/data/com.less.tplayer.baidu/app_myso/libnative-lib.so" is 32-bit instead of 64-bit


这个问题在 Google 某位大神尼古拉斯*赵四 的帮助下找到了答案:


我特意用 [vivoX9 照亮你的美 arm64-v8a 架构] 测试了下:


String [] abis = Build.SUPPORTED_ABIS;


for (String abi : abis) {


Log.e(TAG, "SUPPORTED_ABIS =============> " + abi);


}


}


打印结果是:


E/DynamicSO: SUPPORTED_ABIS =============> arm64-v8a


E/DynamicSO: SUPPORTED_ABIS =============> armeabi-v7a


E/DynamicSO: SUPPORTED_ABIS =============> armeabi


这些顺序是按照优先级排列的,最适合的在最上面,兼容的在下面。


前面注意事项中也提到过:说各个 module 之间 so 的架构一定要对应,如果我们的 App 里面包含了 64 位的架构 arm64-v8a 文件夹,那么这时候应用的 ApplicationInfo 的 abi 就是 arm64-v8a 了,就会发送消息给 Zygote64 的进程,创建的也是 64 位的虚拟机了,如果我们的 App 应用里面只包含的是 armeabi-v7a 和 armeabi 的文件夹,那么创建的会是 32 位的虚拟机以兼容模式运行。


我测试的时候,app 里面并没有任何 so 文件,但是动态加载本地 armeabi-v7a 架构 so 的时候却出现这种错误,后来推断:


如果 App 里面没有任何 so 文件,那么默认就以该手机最适合的模式即 arm64-v8a 运行。但是注意了,64 位的虚拟机不能运行 32 位的 so。

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
动态加载 so 注意事项&案例