摘要许多厂商 APK 并不是单纯的 Java/Dex 文件而是同时携带大量 JNI 动态库。EShareServer APK 内包含多个armeabi/*.so集成时需要处理 APK 内部库目录、目标 ABI、32/64 位配置以及构建系统对 APK 的重新处理。本文解释LOCAL_PREBUILT_JNI_LIBS和LOCAL_MULTILIB : 32的作用并分析zip I/O error: Permission denied的真实原因。1. APK 内部的 JNI 目录一个包含原生库的 APK通常具有类似结构EShareServer.apk ├── AndroidManifest.xml ├── classes.dex └── lib/ └── armeabi/ ├── libeshareplayer.so ├── libeshareloader.so └── ...这些.so不是系统公共库而是随 APK 一起交付由应用运行时加载。项目中的模块配置为LOCAL_PREBUILT_JNI_LIBS : \ lib/armeabi/*.so LOCAL_MULTILIB : 32其中lib/armeabi/*.so表示使用 APK 内lib/armeabi目录中的原生库LOCAL_MULTILIB : 32表示该 APK 按 32 位目标处理。2. 为什么需要声明LOCAL_MULTILIB如果目标系统是 32 位而 APK 中只有armeabi库通常需要明确告诉构建系统使用 32 位配置。否则可能出现构建系统按 64 位处理模块ABI 检查不通过APK 安装成功但启动时找不到库出现UnsatisfiedLinkErrorJNI 库依赖的其他库位数不一致。因此集成前应确认三件事系统支持的 ABI APK 中实际存在的 ABI APK 内所有 JNI 库的位数可以检查 APK 内容unzip -l EShareServer.apk | grep lib/检查 ELF 位数readelf -h libeshareplayer.so输出中的Class可以判断是 ELF32 还是 ELF64。3. 为什么 PRESIGNED 仍可能触发 ZIP 错误集成过程中遇到过zip I/O error: Permission denied这并不一定意味着 APK 损坏。APK 本质上是 ZIP 文件。构建系统处理预编译 APK 时可能需要读取 APK 内容提取其中的 JNI 库生成临时 APK重组 ZIP 目录写入中间产物。如果源 APK 文件是只读的或者构建目录权限不足就可能在写入阶段失败。因此PRESIGNED只表示不替换签名不表示构建流程完全不会读写 APK。处理此类问题时不要直接修改供应商原始文件。更稳妥的方式是将 APK 复制到可写的中间目录 ↓ 确认文件权限 ↓ 重新执行构建同时检查ls -l EShareServer.apk ls -ld out/soong ls -ld out/target/product/product4. JNI 集成后的验证构建后检查最终 APKunzip -l out/.../EShareServer.apk | grep lib/armeabi板端检查应用启动日志adb logcat | grep -iE linker|UnsatisfiedLinkError|dlopen|eshare重点关注library not found wrong ELF class cannot locate symbol permission denied如果出现wrong ELF class通常是 32/64 位不匹配如果出现cannot locate symbol则可能是 JNI 库依赖的其他库版本不一致。