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

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

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.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);

}

}

}

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。

【错误3】

64位的so文件也不能运行在32位的虚拟机中。

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

虽然动态加载so的时候，我本地放入arm64-v8a就不会报错

加载64位的so

但是，如果后期想动态加载第三方的库（如极光推送），这些库里面没有arm64-v8a，或者有的手机不支持arm64-v8a，那么一加载程序就崩了。

根据上面的推论：

我想到的一种方式是：本地保留的 >= 宿主App（但至少有一个）用于欺骗Android设备。

本地保留的 >= 宿主App（但至少有一个）

宿主建立一个空的32位版的空so

这样系统发现该App含有armeabi-v7a的文件夹（里面需要有空so文件），那么就会以兼容模式启动32位虚拟机，然后根据本地目录文件夹，结合上面给出代码 选择so的顺序逻辑加载 需要的so文件。