非常多朋友在开发Android JNI的的时候，会遇到findlibrary returned null的错误，由于某种原因，so没有打包到apk中。以下浅析下引起该错误的原因以及平台兼容性问题。
Android设备载入so怎样选择
眼下主流的Android设备肯定是armeabi-v7a架构的，然后就是x86和armeabi了。那么Android设备在执行程序时怎样选择载入包中的哪个so呢?
x86设备肯定优先寻找x86目录下的so。armeabi-v7a架构的设备肯定优先选择寻找项目中armeabi-v7a目录下的so。那假设项目中没有相应的目录和so呢?
我们以x86设备为例，x86设备会在项目中的 libs目录寻找是否含有x86目录，假设含有x86目录，则默觉得该项目有x86相应的so可执行的，仅仅有x86目录而目录下没有so。程序执行也是会出现findlibrary returned null的错误的。假设project本身不含有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也是无法执行的。 以上就是不同CPU架构执行时载入so的策略。
没有将so打包到apk中的原因。
当你发现到findlibrary returned null的错误时。根本原因是so没有放到相应的目录中去，事实上最直接的解决的方法就是解压apk，看看apk中的x86、armeabi、armeabi-v7a目录中是否有相应的so。此时你可能在相应的目录下发现少了so，然后再去查原因就可以。
一般有双方面的原因:
1.apk中有相应平台的目录，可是目录里却没有相应的so。
举个样例，apk中lib以下一旦出现x86目录，程序执行的时候就会去载入x86相应的库，可是假设此时x86目录没有将so放进来，则会遇到报错。
2.第三方对平台的兼容策略与自己不一致。
可能第三方选择了仅仅支持armeabi（如果某支付sdk）。可是我们的游戏在Application.mk中配置了APP_ABI := all，如此，我们的游戏打包出 了全部平台的so，可是第三方却仅仅有armeabi目录相应的so，造成程序执行异常，这样的情况在开发期间最常见，一些小公司因为測试人员不足或者測试设备不足，上线后才发现这个问题也不奇怪。
对于平台的支持，我们应该怎样选择。
armeabi-v7a确实是能够兼容armeabi的。而v7a的CPU支持硬件浮点运算，眼下绝大对数设备已经是v7a了，所以为了性能上的更优，就不要为了兼容放到armeabi。x86是能够兼容armeabi平台执行的，不管是armeabi-v7a还是armeabi。同一时候带来的也是性能上的损耗。另外须要指出的是，打包出的x86的so，总会比armeabi平台的体积更小，对于性能有洁癖的童鞋们。还是建议在打包so的时候支持x86。详细会有如何的性能损耗，作者还不能说的很清楚。能够訪问下intel官方在csdn的博客。
总结一下在项目中的表现就是: 假设项目仅仅包括了 armeabi，那么在全部Android设备都能够执行； 假设项目仅仅包括了 armeabi-v7a。除armeabi架构的设备外都能够执行； 假设项目仅仅包括了 x86，那么armeabi架构和armeabi-v7a的Android设备是无法执行的。 假设同一时候包括了 armeabi， armeabi-v7a和x86，全部设备都能够执行，程序在执行的时候去载入不同平台相应的so，这是较为完美的一种解决方式，同一时候也会导致包变大。