首先我们谈谈Android Studio在导入第三方的.so文件的方法。
1.首先我们需要把相应的.so文件拷贝到app中的lib文件夹中 
2.在build.gradle中配置下资源信息 
其实还可以用另一种方法，就是在main文件夹中新建资源包，然后将build.gradle配置中做相应的更改也是可以起到相同作用的。 
我们即使做了如此充分的准备，在编译的时候仍然可能会遇到编译失败的情况，比如显示找不到改so文件，或者在你引入了JNI方法之后显示找不到改JNI方法。
那我们就先谈谈找不到so文件的情况，有人会问我们不是已经导入了so文件么，而且也配置了相应的路径啊。那么问题就来了，为什么会出现这种情况？
原因其实很简单，因为android系统的CPU架构现在有以下七中：ARMv5，ARMv7，x86,MIPS,ARMv8,MIPS64和x86_64。每一种CPU类型都对应一种ABI（Application Binary Interface），“armeabi-v7a”文件夹前面的“armeabi”指的就是ARM这种类型的ABI，后面的“v7a”指的是ARMv7。这7种CPU类型对应的so库文件夹名是：armeabi，armeabi-v7a，x86,mips，arm64-v8a，mips64，x86_64。
然而不同的移动设备在运行APP时，是需要加载自己支持的类型的so库，不然就会提示找不到该so库。 
还有就是我们导入了相应的so文件，并且也正确配置了资源引入方法。在初始化的时候我们也通过了，但是我们在使用第三方提供的JNI方法的时候却报错了，显示找不到该方法。这个时候很多人就纳闷了，这是什么鬼？不应该啊，我也遇到过这种情况，而且经常遇到的就是这种找不到方法。因为网上大多数都提示你可能是路径导入不对，或者说是资源引入错误之类的，我可以明确告诉你统统都不是，而是你的so文件跟你的JNI文件所在的包名不一致。
如果你的JNI文件是从官方demo里面拿出来的，那么就在使用它们的so库的同时，需要把JNI文件的路径改成跟demo里面一样的JNI包名路径，而并不能直接放入到自己的项目包名路径中，因为so文件里面是写入了该JNI文件的包名路径，如果路径不一致，在调用方法的时候就会提示找不到方法。 