关于Java.lang.UnsatisfiedLinkError的错误解决办法

把原本一直在魅蓝metal测试的android地面站换到S6 edge中运行就报java.lang.UnsatisfiedLinkError: No implementation found for void com.mmc.groundstation.activities.activity.GroundStationActivity.startVideoStream(java.lang.Object) (tried Java_com_mmc_groundstation_activities_activity_GroundStationActivity_startVideoStream and Java_com_mmc_groundstation_activities_activity_GroundStationActivity_startVideoStream__Ljava_lang_Object_2)

其实在Android开发中，我发现通常引用了一些第三方的sdk的so库之后，不同机型之间就会发生这样一个错误，

Java.lang.UnsatisfiedLinkError！

举个例子：

你原先的项目中只使用了A公司提供的so包，他只提供了armeabi这个架构的so包，后来项目需要又引用了B公司的提供的sdk，里面提供的so包还挺全的，arm64-v8a，armeabi-v7a，mips，mips64，x86等等，结果你就全放进去了， 后来发现突然某手机就出现了崩溃，然后一般都是因为这个问题

Java.lang.UnsatisfiedLinkError

所以呢，为了解决这个问题，也有人提出了解决办法：

这种情况一般是由于libinet.x.x.x so(x.x.x代表版本号，比如libinet.1.6.2)文件未加载成功导致的，解决方法有两种：  

方法一：  

首先确认libs目录下每个存放so文件的目录是否包含了libinet.x.x.x.so文件。  

比如armeabi和armeabi-v7a,但是armeabi-v7a中没有libinet.x.x.x.so，这是不允许的，请从armeabi中复制。  

比如x86_64没有libinet.x.x.x.so，请从我们提供的demo中对应的x86_64目录复制（不能从demo的armeabi目录复制，因为平台类型不一致，保证从demo中同名的目录复制文件）。  

方法二：  

仅仅保留armeabi和x86目录，删除其它多余的目录(比如arm64-v8a,x86_64等)，同时确认armeabi和x86目录有libinet.x.x.x.so文件。  

注意，这里所说的仅仅保留armeabi和x86目录是指主工程和所有依赖工程都只能仅仅保留armeabi和x86目录，若主工程或者某一个依赖工程中包含了其他目录(例如x86_64)，还是会存在问题的。  

如果用这种方法处理后没有解决该问题，请用解压软件解压apk，然后看一下lib目录下是否只有armeabi和x86目录，如果有armeabi和x86目录以外的目录，说明你一定没有删除干净，一定没有删除干净，一定没有删除干净，重要的事情说三遍，自己再仔细检查一下！  

另外，删除其他工程中armeabi-v7a, arm64_v8a，x86_64目录不会影响这些工程的功能的，也不会在其他手机上产生适配问题，所以放心的删除吧！  

另外，删除其他工程中armeabi-v7a, arm64_v8a，x86_64目录不会影响这些工程的功能的，也不会在其他手机上产生适配问题，所以放心的删除吧！  

另外，删除其他工程中armeabi-v7a, arm64_v8a，x86_64目录不会影响这些工程的功能的，也不会在其他手机上产生适配问题，所以放心的删除吧！  

重要的事情说三遍！！！  

so加载原理可以参考： http://www.jianshu.com/p/cb05698a1968

然后呢，我也找了一些瘦身APK的资料，发现好像只保留armeabi这个文件就可以了，别问为什么，微信就只有这一个文件夹，要是觉得自己apk太大了， 就删掉其他的吧，保留这一个就ok了。

参考见：

http://blog.csdn.net/a774838634/article/details/52758096

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，这是较为完美的一种解决方案，同时也会导致包变大。

参考见：

http://blog.csdn.net/duguang77/article/details/38512957