显然,这是由于读取不到so文件导致的异常。
我尝试了如下方法:
- 检查了
jniLibs
目录下的文件结构和so文件
,都稳稳的躺在那儿; - 试图使用如下方式重新指定目录,依然无果;
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}
- 请教提供
so文件
的开发同学是否与targetSdkVersion
等有关系,并且试图配置了和他们一样的version
-
Clean Project
和Rebuild Project
- 反编译查看
apk
中的libs目录
下确实也存在so文件
然而,并无卵用!
奇怪的是这个异常在真机(OnePlus2,HUAWEI MATE8
)上有,而在模拟器上却安然无恙。
于是乎,查看到OnePlus
2的CPU架构
是CPU_ABI=arm64-v8a
。翻阅到一篇文章描述到:
对于一个
cpu
是arm64-v8a
架构的手机,它运行app
时,进入jnilibs
去读取库文件时,先看有没有arm64-v8a
文件夹:
如果没有该文件夹,去找armeabi-v7a
文件夹,如果没有,再去找armeabi
文件夹,如果连这个文件夹也没有,就抛出异常
如果有arm64-v8a
文件夹,那么就去找特定名称的.so文件
,注意:如果没有找到,不会再往下(armeabi-v7a文件夹
)找了,而是直接抛出异常
如上图jniLibs
目录结构,本地并不存在arm64-v8a文件夹
,反编译apk
后发现竟然存在此目录,显然是由于其他aar
的引入会生成此目录,用于存放其相关so文件
。
过滤掉此目录:
defaultConfig {
//省略其余配置
ndk {
//这句话的意思是指定ndk需要兼容的架构,其余文件夹so文件全部过滤掉
abiFilters "armeabi", "armeabi-v7a", "x86"
}
}```
这么个问题,两天的光景没了!蓝瘦,香菇。
[关于abiFilters的使用](http://blog.csdn.net/wove55678/article/details/52313208)