很长时间没有做三方的so库导入了,今天项目需要导入三方库。按照以前的经验,引入libs、创建jniLibs、功能开发,一切准备就绪。运行时却出现了错误java.lang.UnsatisfiedLinkError: dalvik.system.DexClassLoader 报找不到.so文件。于是又去检查了一下配置,不应该啊,配置完全没有问题啊,这是为什么呢?于是开始排查问题三部曲,百度、google、尝试。
网上基本都是说架构适配原因的,没什么用。

检查APK

网上找不到原因,于是我便去查看打包的APK有什么问题。解压APK,看到解压目录下,导入的.so文件都存在
image.png
这没问题,那么安装后呢?
于是找到安装后的目录查看
image.png
可以看到这里确实没有任何.so文件
image.png

到这里我就搞不懂了,于是继续google,不过google方向调整了下,于是我便看到了android:extractNativeLibs,在AndroidManifest.xml<application>标签里添加android:extractNativeLibs="true",于是我去尝试了下,终于成功了,那么extractNativeLibs有什么作用呢?
于是便去官网查了查
image.png

extractNativeLibs

extractNativeLibs不同版本的默认值

  • minSdkVersion < 23 或 Android Gradle plugin < 3.6.0,打包时android:extractNativeLibs=true
  • minSdkVersion >= 23 并且 Android Gradle plugin >= 3.6.0,打包时android:extractNativeLibs=false

extractNativeLibs不同设置的表现

当设置android:extractNativeLibs=true时,打包时,工程中的.so库会被压缩,那么生成的apk的体积也会减少,但是安装时,需要解压缩到/data/app/那么安装的时间就会变长,而且同一个 so 文件就会有两份,一份在 apk 中压缩存储,一份在 /data/app/ 中未压缩存储,导致多占用了空间。
当设置为false则安装apk时 .so文件不会从apk中解压出来,同时修改System.loadLibrary 直接打开调用 apk 中的 so 文件。

官方建议

从 AGP 4.2.0 开始,DSL 选项useLegacyPackaging取代了extractNativeLibs清单属性。建议使用useLegacyPackaging 来配置原生库的压缩行为。

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}



©超超使用Stellar 1.29.1 创建。

发表了 14 篇文章 · 总计 21.5k 字