分析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.
参考：
