错误提示部分代码：

java.lang.UnsatisfiedLinkError: Couldn’t load from loader dralvik.system.PathClassLoade[Dex

错误原因分析

可能原因1

自己项目中的.so库分配不全，例如项目中有armeabi，armeabi-v7a存放so文件的文件夹，如果armeabi中有a.so，那么armeabi-v7a也必须有a.so，CPU架构为armeabi-v7a才找得到a.so。

可能原因2

AndroidStudio使用jcenter或者maven关联第三方项目生成的.so时，由于自己项目存放的.so的路径和第三方的不一样，导致冲突。

本篇文章主要讲的是可能原因2

　　AndroidStudio 2.0出来后，在这里吐槽下，有点卵用，那就是2.0的虚拟机。至于Instant Run，由于项目minSDKVersion是9，达不到15，基本用不上； Gradle 2.10编译速度尝试了，跟Gradle2.8没啥鸟差别，要不是自己怀有对以后会出更好的Gradle版本或者Android Gradle插件用在AndroidStudio2.0上，还是会选用AndroidStudio 1.5的，吐槽到此为止。
　　
　　最近在做Eclipse的Android项目迁移到AndroidStudio上的事。起初，项目中的一个主Android应用和3个依赖库项目的项目结构还是保留了ANT的结构。集成完之后，发现主Android应用的项目的libs中的.so库存储和使用jcenter动态加载的.so库不兼容，所以导致编译后，程序找不到对应.so文件的问题。
　　
　　以下是两种尝试解决问题的方法，但最后还是失败：
　　尝试1：在module的Gradle中添加：
　　

android {
    sourceSets {
        main { 
            jniLibs.srcDirs = ['libs']
        }
     }
}

　　结果：虽然对自己放在项目底下libs文件夹.so库加载有效，但是对从jcenter或者maven库加载的.so库无效；
　　
　　尝试2：自己在保留ANT项目结构的同时，手动在src/main下新建jniLibs文件夹，然后将自己的.so文件拷贝进去。
　　结果：最后编译后，运行时，连自己的.so文件都找不到。

最后笔者解决问题的办法

　　第一步：将Android项目结构改变成Gradle要求结构，其他依赖库项目可以保留ANT项目结构。然后在src/main下建立jniLibs文件夹，把自己项目原本libs中的.so包括各个cpu结构文件夹（例如：armeabi）拷贝到jniLibs下，如下图所示：

找不到外部程序 CLASS TO JAVA_armeabi


　　这时编译项目运行并测试成功。（这一步一定要保证编译.so库测试成功，假如之前你集成了百度推送，关联百度推送库就有.so文件，这时测试推送是否正常）

　　

　　第二步：下载第三方库后（比如github上的master），其项目底下有类似libs的目录，或者其他存储.so文件的目录（你也可以将第三方demo的apk包解压获取里面的.so文件），将得到的.so文件拷贝到我们自己项目jniLibs中各个存储.so文件夹下。

　　

　　经过以上两步，第一种方案已完成。

扩展办法，笔者未尝试

　　第一步：在module的Gradle中添加：

android {
    sourceSets {
        main { 
            jniLibs.srcDirs = ['libs']
        }
     }
}

　　第二步：下载第三方库后（比如github上的master），其项目底下有类似libs的目录，或者其他存储.so文件的目录（你也可以将第三方demo的apk包解压获取里面的.so文件），将得到的.so文件拷贝到我们自己项目libs中各个存储.so文件夹下。
　　
　　经过以上两步，第二种方案已完成，这种方案未测试，不过原理和方案1类似，应该行得通。