No toolchains found in the NDK toolchains folder for ABI with prefix: mips64el-linux-android”

转载请标明出处:http://77blogs.com/?p=307

安装完NDK的时候出现了这个错误,网上的办法是下载旧版的NDK,将其中的toolchain复制到新版的NDK中。

但其实不用这么麻烦。

经过对新版NDK的研究,发现NDK的更新记录里有一段话

This version of the NDK is incompatible with the Android Gradle plugin
version 3.0 or older. If you see an error like
No toolchains found in the NDK toolchains folder for ABI with prefix: mips64el-linux-android,
update your project file to [use plugin version 3.1 or newer]. You will also
need to upgrade to Android Studio 3.1 or newer.

 

也就是说新版本的NDK与3.0及以前旧版的Android Gradle plugin插件不兼容,其实解决方法很简单,就是修改build.gradle中的红字部分,改为3.1以上版本即可,另外AS的版本也要升级到3.1或者3.1以上。

dependencies {
classpath ‘com.android.tools.build:gradle:3.2.0’

}

java.lang.UnsatisfiedLinkError:dlopen failed: “**/*/arm/*.so” has unexpected e_machine: 3

转载请标明出处,维权必究:http://77blogs.com/?p=310

今天在做APP的时候使用so库,可结果一加载so库的时候便发生了这个莫名其妙的错误,类似这样:

java.lang.UnsatisfiedLinkError:dlopen failed: “**/*/arm/*.so” has unexpected e_machine: 3

这个问题真是让人头疼,然而谷歌是个好东西,在一篇文章中看到了提示,发生这个错误是因为该so库不支持手机的这个CPU架构,我将信将疑,打算验证一下,于是又各种翻,看看有什么办法能够查看so库所支持的CPU架构,最终还是让我找到了,请看我另一篇文章,真令我好找啊。

http://77blogs.com/?p=311

window系统下如何查看so库的信息

转载请标明出处,维权必究:http://77blogs.com/?p=311

 

linux系统下能够直接用命令行查看so库的信息,但是window系统下咋办好呢?凉拌~

还是找到了办法,这么办:

首先下载cygwin,这个工具到底是啥,其实它能够让我们在window系统下模拟linux系统,执行linux系统的命令,具体如何安装请看我另一篇博客:

https://www.cnblogs.com/tangZH/p/10458366.html

看完链接里面的博客,相信大家已经对cygwin有了一定的了解,那接下来就是查看so库的信息了,举个例子查看so库所支持的CPU架构,我们查看一下libchm4j-native.so这个so库所支持的CPU架构:

这就要说到一个很出名的命令了:readelf命令,这个命令是linux系统下的。

进入cygwin目录,点击Cygwin.bat运行,输入readelf -h xxx.so,查看so文件的头部信息。

 

从中便可以看出该so库所支持的CPU架构了。

若是要查看so库的其他信息,那么可以去搜索一下readelf的用法,这里就不多说啦。

 

findlibrary returned null

转载请标明出处,维权必究:http://77blogs.com/?p=478

该错误是在加载so库的时候出现的,就是找不到so库。

一、检查jinLibs目录下是否有so库

二、gradle的android{}里面是否有设置:


 

三、兼容性是否正确:

我们使用so库,需要设置该so库兼容的cpu架构,通常会在jniLibs文件夹里面新建文件夹:armeabi,armeabi-v7a,x86,然后把so库放在里面。

目前主流的Android设备肯定是armeabi-v7a架构的,然后就是x86和armeabi。

那么Android设备在运行程序时如何选择加载包中的哪个so呢?

X86:

x86设备会在项目中的 libs文件夹寻找是否含有x86文件夹,如果含有x86文件夹,则默认为该项目有x86对应的so可运行的,只有x86文件夹而文件夹下没有so,程序运行也是会出现findlibrary returned null的错误的;如果工程本身不含有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也是无法运行的。

 

armeabi

如果项目只包含了 armeabi,那么在所有Android设备都可以运行

以上就是不同CPU架构运行时加载so的策略。

 

指定app兼容哪种架构:

app.gradle里面


 

指定要ndk需要兼容的架构,这样其他文件夹的依赖包里的so会被过滤掉,指定了之后,除了armeabi其它文件夹里的so包不会被打包进apk。

想知道自己的so包有没有被打包进去,一个简单的方法,就是将软件包的apk后缀改为zip后缀,然后解压,看看有没有。

 

平台的优缺点:

1、打包出的x86的so,总会比armeabi平台的体积更小,若是对这个有要求,可以在打so包的时候支持x86

2、armeabi-v7a 第7代 ARM v7,使用硬件浮点运算,具有高级扩展功能(支持 armeabi 和 armeabi-v7a,目前大部分手机都是这个架构),armeabi-v7a确实是可以兼容armeabi的,而且性能更优,若是对性能有要求,so包可以支持armeabi-v7a