android应用自升级的时候so损坏

Android应用自升级的时候so损坏的原因可能是：

1. 由于应用的更新版本中有新增加的so文件，但是之前的版本中没有，而且当前系统中没有该so文件，所以在更新的时候就会报错，导致so损坏；

2. 当前系统中有该so文件，但是和应用更新版本中的so文件不一致，所以就会出现so损坏的情况；

3. 应用初始化时，需要调用so文件，但是由于系统中没有该so文件，所以就会出现so损坏的情况；

4. 应用更新的时候没有更新so文件，但是当前系统中的so文件和应用更新版本中的so文件不一致，所以就会出现so损坏的情况；

5. 应用更新的时候，so文件被意外损坏或者删除，也会导致so损坏的情况。

总之，so损坏的原因可能有很多，所以在开发者进行应用更新时，应该特别注意so文件的更新，以免出现so损坏的情况。

关键点：

JAVA编译不分32bit和64bit（APK，JAR）

可执行文件，默认编译64位

动态库和静态库，默认同时编译32bit和64bit版本

通过LOCAL_MULTILIB可以指定特定模块编译32bit或64bit或都编译

JAVA加载JNI库（so文件）的规则：

如果APP需要加载的所有so都是32bit，则使用32bit方式加载so库；如果APP需要加载的so库中只要有一个so是64bit的，则必须以64bit方式加载so库；不能同时加载32bit和64bit的so库。

实际工程中，我们通常会遇到下面这样的场景：

A. APK有源码，SO库有源码 - 应用及so库我们都能自己编译出来

B. APK有源码，SO库没有源码 - 我们开发的应用使用了第三方的so库，如ScanService

C. APK和SO库都没有源码 - 预置第三方的应用（应用中包括so库）

对于场景A：

只要我们编译默认对应的APP和SO库（32bit+64bit）即可。

此种场景最为普通，本文不做详细讲解。

对于场景B：

如果APK需要加载的库里面有64bit的，则需要全部的库都使用64bit。

如果APK调用的第三方so库中有32bit的，则：要么让第三方提供64bit版本的so库，要么强制使所以的so库都使用32bit版本。

对于场景C：

使用特定的预置规则即可。

---