Android JNI SO库和对应的CPU架构详解

一、前言

Android JNI生成的so库有很多不同架构类型，比如：armeabi、armeabi-v7a、arm64-v8a、x86；

Android 系统不同的cpu架构就要使用不同类型的so库，如果不考虑内存大小，放全套也是没有问题的；

但是实际使用中，很多时候只会放一套或者两套就可以了。

本文介绍Android cpu不同架构的so库区别，以及如何查看当前系统是什么cpu架构，

以便在实际场景中做出最优选择。

二、Android CPU架构

1、Android系统支持的CPU架构

armeabi:第五代、第六代ARM处理器，使用软件浮点运算，很古老的手机是这架构， 出现在2000年左右 。

armeabi-v7a:第七代ARM处理器，使用硬件浮点运算，2018年以前手机主流架构， 2007年开始出现 。

arm64-v8a：第八代64位处理器，当前主流架构， 2014年左右出现。

x86/x86-64：Intel处理器，Android模拟器用得比较多。 X86_64与X64都是讲的同一个东西 。

每一种CPU架构对应一个ABI，ABI定义了二进制文件（比如SO）如何运行在相应的系统平台。

不同的CPU架构平台需要不同的so才能正常执行相应的逻辑代码。

2、如查查看手机的CPU架构

通过prop属性ro.product.cpu.abi就可以查看当前cpu的架构类型。

adb shell   getprop ro.product.cpu.abi

Android9或者更新的版本 手机和平板：arm64-v8a

AndroidStudio自带模拟器： x86

（1）Android13 大屏AML厂商的cpu信息：

130|console:/ # getprop | grep cpu
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
...
[ro.system.product.cpu.abilist64]: [arm64-v8a]
console:/ # 

（2）电脑Android Studio模拟器上的cpu信息：

C:\Users\As520>adb shell
generic_x86:/ $ getprop | grep cpu
[ro.product.cpu.abi]: [x86]
[ro.product.cpu.abilist]: [x86,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [x86,armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: []
generic_x86:/ $
C:\Users\As520>

电脑是window10 64位的，处理器x64，这里Android模拟器显示x86，

估计现在新的模拟器都是x86，可能没有x86-64 的说法的了，也可能是Intel做了合并。

（3）Android Studio生成不同类型so库

生成不同类型的so库，需要在app同级目录的build.gradle定义abiFilters和对应的so类型。

1、使用ndk或者cmake里面的 abiFilters定义生成不同so类型 都是可以的；

2、如果不写是默认生成全部四个类型的so集成到apk中，Studio Analyze可以查看apk文件里面的lib包；

3、如果只声明一个so类型，就会只集成一种so到apk中，减少了内存；

4、默认是生成的debug版本so，如果要生成release版本的so，点击右边build里面的assemble就会生成正式版的；

（4）Android Studio加载so库

加载别人提供的so库，需要在app同级目录定义jniLibs目录放置对应类型的文件夹和so库。

如下图所示：

同时要在app下的build.gradle文件写入加载的jni目录代码：

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

这里的jni目录名称："jniLibs"是可以随便改的，只要和创建的目录对应就行，

但是x86、arm64-v8a 这些类型文件夹的名称是固定的。

值得注意的是，使用别人提供的so文件，还要知道定义so对应的native方法的包名和类型，否则无法形成映射关系。

三、其他

1、在电脑模拟器x86架构中，JniLibs放置其他类型文件和so夹，未放置x86文件和so，报错：

java.lang.UnsatisfiedLinkError: dlopen failed: library "libnative-lib.so" not found

在真机中，JniLibs放置其他类型文件和so夹，未放置arm64-v8a文件和so，同样是报上面的错误。

Android Studio 环境换各种类型的so文件夹都报错情况：

Unable to determine application id: com.android.tools.idea.run.ApkProvisionException: The currently selected variant "debug" uses split APKs, but none of the 1 split apks are compatible with the current device with ABIs "x86, armeabi-v7a, armeabi".

ApkProvisionException 表示 APK 供应异常，这里指的是在尝试为当前选定的 “debug” 变体生成 APK 时出现问题。

Studio 模拟器重启就好了。

2、Android 版本和对应发布时间

Android 1.0: 发布于2008年9月23日。
Android 1.1 (Petit Four): 发布于2009年2月9日。
Android 1.5 (Cupcake): 发布于2009年4月27日。
Android 1.6 (Donut): 发布于2009年9月15日。
Android 2.0-2.1 (Eclair): 发布于2009年10月26日。
Android 2.2 (Froyo): 发布于2010年5月20日。
Android 2.3 (Gingerbread): 发布于2010年12月6日。
Android 3.0-3.2 (Honeycomb): 发布于2011年2月22日。
Android 4.0 (Ice Cream Sandwich): 发布于2011年10月18日。
Android 4.1-4.3 (Jelly Bean): 发布于2012年7月9日。
Android 4.4 (KitKat): 发布于2013年10月31日。
Android 5.0-5.1 (Lollipop): 发布于2014年11月12日。
Android 6.0 (Marshmallow): 发布于2015年10月5日。
Android 7.0-7.1 (Nougat): 发布于2016年8月22日。
Android 8.0-8.1 (Oreo): 发布于2017年8月21日。
Android 9.0 (Pie): 发布于2018年8月6日。
Android 10: 发布于2019年9月3日。
Android 11: 发布于2020年9月8日。
Android 12: 发布于2021年10月4日。
Android 13: 发布于2022年8月16日。
Android 14: 发布于2023年5月11日。

可以看到Android发布的等级版本，每年升级一版雷打不动。

但是过程中有可能有Bate版本，或者多个API版本，比如AndroidAPI 33 和API 32都是Android13。

armeabi-v7a:2018年以前手机主流架构，arm64-v8a：2014年左右出现，当前主流架构 。

2015年到2018年，cpu的架构在armeabi-v7a和arm64-v8a 都有使用，2019年后基本都只使用arm64-v8a。

所以Android9 或者更新的Android手机系统正常情况只需要适配 arm64-v8a 就可以了。

3、如果正式版的应用，使用debug版的so 会有问题吗？或者debug版应用使用正式版so会有问题吗？

Android Studio直接跑的就是debug应用。添加签名文件后，就可以生成正式版本。

对比了两种so大小，确实有差异，但是测试上面两种情况都是可以正常运行的。

所以debug版本和release版本应该只是针对apk校验，对so相关的底层实现影响不大。

4、使用so库的架构小结

对于新版本系统（Android9以上）的Android手机系统只需要适配 arm64-v8a 就可以了；

如果要适配模拟器，可以加 x86，有些模拟器可能要x86-64.非必要一般不加x86模拟器的so。

如果不确定设备cpu架构类型可以使用adb shell 命令查询： getprop | grep cpu。