关于安卓so的兼容性的简单说明

armeabi、armeabi-v7a、mips、x86 、arm64-v8a如何理解？

ABI:指应用基于哪种指令集来进行编译，ABI以前总共有四种，分别是armeabi、armeabi-v7a、mips、x86，它们都是表示cpu的类型，现在又有了arm64-v8a。

（注意：以下所有讨论不包括mips）

先说以前对于so的平台兼容处理方式吧。

以前安卓都是32位系统，运行的进程都是32位，理论上armeabi的so可以被全平台兼容，所以，理论上我们可以只提供一个armeabi的so就能在所有cpu平台运行了。也就是说如果我们引入了A和B两个库，其中A提供了全平台的armeabi、armeabi-v7a、x86三个so，而B只有一个armeabi的so，那么我们可以把B的这个so复制到其他两个文件夹就可以被兼容了。

同时因为现在armeabi的设备比armeabi-v7的要少很多，所以有些应用直接提供了armeabi-v7的so。

现在有了arm64-v8a的CPU以及安卓64位系统，上面的方法就有点例外了。

在安卓64位系统上，同时运行着32位和64位的进程（这点和Windows很像，在64位Windows上也是能同时运行32位和63位的进程的）。

以下讨论是基于64位安卓系统上：

1. 如果一个纯粹的java写的应用，没有使用任何的so，那么默认就应该以64位模式来运行；

2. 如果一个应用中只提供了32位的so，那么这个应用会运行在32位模式，我们之前的拷贝so到其他文件夹的方式依然是可行的。

3. 如果一个应用引入了两个库分别是A和B，其中A提供了armeabi，armeabi-v7，arm64-v8a，x86四个so，而B只提供了armeabi一个so，这样的话，因为应用启动时会检测到arm64-v8a的存在，所以就会以64位模式来运行了，这时需要用到的so必须为64位的，就不能使用armeabi的so来兼容了，也就是说一个进程中一旦使用了64位的so，那么就不能使用32位的so了，这点也和Windows很像。要解决这个问题，要么就是找到B的其他平台的so，要么就是去掉A的64位so，以32位模式来运行。