findlibrary returned null

转载请标明出处，维权必究：https://www.cnblogs.com/tangzh/p/10181330.html 

该错误是在加载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