如何解决java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList couldn't find xx so

公司项目的OCR 文档识别的sdk 仅仅提供了armeabi 的so库，然而项目主moudle里的libs里边还有arm64-v8a包，这就造成了64位的手机一调用这个库就会崩溃报：java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/xxx.xxxxx.xxx/base.apk"],nativeLibraryDirectories=[/data/app/xxx.xxxxx.xxx/lib/arm64, /vendor/lib64, /system/lib64]]] couldn't find "AndroidAndIdCard.so";

首先先跟sdk提供商沟通看看他们是否能够提供64位的so库，如果实在不行的话，只能在项目的gradle文件下 的defaultConfig{}里添加如下代码：

  ndk{
       abiFilters "armeabi ","armeabi-v7a"
 
    }
这样项目就只会去armeabi 或者armeabi-v7a下去寻找对应的so库。

原文：https://blog.csdn.net/jefftang2020/article/details/77855645 
 

关于abiFilters的使用

最近项目中遇到了要使用opencv的情况，涉及到了abi兼容的选择。因为如果全部都适配的话，包很大，这样兼容那些用户数极少的cpu就很不划算，所以我只适配了armeabi-v7a这一个。但是今天在x64-v8a的模拟器上看的时候，提示我的library.so文件找不到，我记得这个应该是向下兼容的，但是出现这种情况很奇怪，于是我就在网上找了找答案。

解决方法：abiFilters
在app的gradle的defaultConfig里面加上这么一句

ndk {
    abiFilters  "armeabi-v7a"  // 指定要ndk需要兼容的架构(这样其他依赖包里mips,x86,armeabi,arm-v8之类的so会被过滤掉)
}
这句话的意思就是指定ndk需要兼容的架构，把除了v7a以外的兼容包都过滤掉，只剩下一个v7a的文件夹。用了这个方法之后，确实解决了问题。这就是解决方法。

具体分析
其实这个方法我开始是很奇怪的，我明明没有指定其他的兼容框架，为什么会需要一个过滤。我打来了apk的包，找到了里面的lib目录，发现里面有很多的兼容目录，然后看到里面目录里面的是一个fresco的.so文件。也就是说，fresco做了各个平台的兼容，所以它创建了各个兼容平台的目录。因为只要出现了这个目录，系统就只会在这个目录里找.so文件而不会遍历其他的目录，所以就出现了之前找不到.so文件的情况（因为其他目录没有我的.so文件）。

总结
为了决定最后适配的abi版本，我下载了排行前几名的app，然后打开之后发现，他们基本上只适配了一个armeabi，少数会再加上v7a。我了解到的情况是armeabi性能较差，但是兼容性最好，v7a对于浮点计算的cpu来说性能更好，不兼容不支持浮点运算的cpu。我想到的是目前的手机cpu绝大多数应该是支持浮点运算的，而且安卓从2.2开始就支持v7a，所以v7a的兼容性应该也不是问题。（不知道对不对，谁能明确一下的，恳请指正） 
无论如何，abiFilters还是应该添加的。

原文：https://blog.csdn.net/wove55678/article/details/52313208