分析Android ：java.lang.UnsatisfiedLinkError: dlopen failed * is 32-bit instead of 64-bit

Crash 日志：

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/data/com.ireader.plug.sdk/ireader_plugins/lib/armeabi/lib***.so"

 is 32-bit instead of 64-bit

        at java.lang.Runtime.loadLibrary0(Runtime.java:1016)

        at java.lang.System.loadLibrary(System.java:1657)

问题分析：

首先看log, 报错为：so打开失败，因为lib***.so 是32位的so,而不是64位的。

补充：

Android 程序运行起来，要么只加载32位的so，要么只加载64 位的so. 是不能混合加载的。

常见的两种情况如下：

第一种情况：

对于一个android程序，如果程序没有用到任何so，假如程序跑在64位的手机上，虚拟机默认加载64位的so。这时候，如果你加载了32位的so，就会报错。反之，如果程序跑在32位的手机上，虚拟机默认只加载32位的so.

可能有同学有疑问，既然我的程序里面没有任何的so, 跑在了64位的手机上，这种情况下怎么会加载32位的so呢？我的程序里面是没有so 的啊。没错，你的apk 里面是没有任何的so,但是如果你的项目中使用了插件技术，插件apk 里面有32 位的so，这时候就会挂掉了。

解决方法：

在你的项目里面建立一个armeabi 的文件夹，里面放一个文件。文件名字叫做fix.so。这个so 可以是0kb,但是一定要有。这样，程序跑在64位的手机上，发现你只有armeabi 的文件夹，那么就会使用32 位的虚拟机，这时候，加载你插件里面的so，就不会有问题了。

第二种情况：

如果程序里面有so, 并且有arm64-v8a 或者x64 的文件夹，也有armeabi 的文件夹，运行在64位的手机上，会默认使用arm64-v8a 或者x64 文件夹里面的so. 这时候，如果有些so 没有arm64-v8a ，就会报错找不到so。虽然你在armeabi 文件夹里面有。

如果是这种情况，那么直接把 arm64-v8a 的so 删除掉，只留下armeabi 的so。因为armebai 兼容所有类型的处理器。当然你也可以把缺少的64位的so 编译一下。

我们项目具体场景：

我们是做插件sdk 给第三方接入的。我们会让第三方接入一个apk文件，里面只有armeabi 的so.

还有一个libmerge.so 用于插件增量更新。但是有些厂商不愿意动态更新，我们定的方案是如果不需要增量更新这个功能，程序里面可以没有libmerge.so 。

早期的时候，手机还都是32位的，所以，没有问题。但是现在都是64位的手机，有的厂商自己apk 没有任何的so, 跑在64为手机上，上来就挂。java.lang.UnsatisfiedLinkError: dlopen failed * is 32-bit instead of 64-bit

他们反馈在有些手机会出现，有些手机可以正常运行。当然，可以运行的都是32位手机，不可以的都是64位的手机。

这时候，我们让厂商放在armeabi 文件夹下一个fix.so。虽然是一个空文件，但是程序就可以跑起来。这样，程序跑在64位的手机上，发现你只有armeabi 的文件夹，那么就会去加载32 位的so，这时候，加载你插件里面的so，就不会有问题了。

知识补充：

如何查看android cpu是32位还是64位？

adb shell getprop ro.product.cpu.abi

C:\Users\zy>adb shell getprop ro.product.cpu.abi

arm64-v8a

C:\Users\zy>adb shell getprop ro.product.cpu.abi

armeabi-v7a

可以看到手机默认的so 文件夹。arm64-v8a 是64位的。另外，一般手机内存超过4G 都是64位的，因为32支持的最大内存是4G.

参考：

https://www.cnblogs.com/janehlp/p/7473240.html