转载请标明出处，维权必究：https://www.cnblogs.com/tangZH/p/10181330.html
更多查看：http://77blogs.com/?p=478
该错误是在加载so库的时候出现的，就是找不到so库。
一、检查jinLibs目录下是否有so库
二、gradle的android{}里面是否有设置：
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}三、兼容性是否正确：
我们使用so库，需要设置该so库兼容的cpu架构，通常会在jniLibs文件夹里面新建文件夹：armeabi，armeabi-v7a，x86，然后把so库放在里面。
目前主流的Android设备肯定是armeabi-v7a架构的，然后就是x86和armeabi。
那么Android设备在运行程序时如何选择加载包中的哪个so呢？
X86：
x86设备会在项目中的 libs文件夹寻找是否含有x86文件夹，如果含有x86文件夹，则默认为该项目有x86对应的so可运行的，只有x86文件夹而文件夹下没有so，程序运行也是会出现findlibrary returned null的错误的；如果工程本身不含有x86文件夹，则会寻找armeabi或者armeabi-v7a文件夹，兼容运行。
armeabi-v7a：
现在大多数设备都是armeabi-v7a架构的，该Android设备当然优先寻找libs目录下的armeabi-v7a文件夹，同样，如果只有armeabi-v7a文件夹而没有 so会报错；如果找不到armeabi-v7a文件夹，则寻找armeabi文件夹，兼容运行该文件夹下的so，但是不能兼容运行x86的so。所以项目中如果只含有x86的so，在armeabi和armeabi-v7a也是无法运行的。
armeabi
如果项目只包含了 armeabi，那么在所有Android设备都可以运行
以上就是不同CPU架构运行时加载so的策略。
指定app兼容哪种架构：
app.gradle里面
android{
...
defaultConfig{
...
ndk {
abiFilters "armeabi"
}
}
}指定要ndk需要兼容的架构，这样其他文件夹的依赖包里的so会被过滤掉,指定了之后，除了armeabi其它文件夹里的so包不会被打包进apk。
想知道自己的so包有没有被打包进去，一个简单的方法，就是将软件包的apk后缀改为zip后缀，然后解压，看看有没有。
平台的优缺点：
1、打包出的x86的so，总会比armeabi平台的体积更小，若是对这个有要求，可以在打so包的时候支持x86
2、armeabi-v7a 第7代 ARM v7，使用硬件浮点运算，具有高级扩展功能（支持 armeabi 和 armeabi-v7a，目前大部分手机都是这个架构），armeabi-v7a确实是可以兼容armeabi的，而且性能更优，若是对性能有要求，so包可以支持armeabi-v7a