本文详解 Android 7.0 及以上版本中，系统级 Service 加载 JNI 共享库（.so）时出现 UnsatisfiedLinkError: dlopen failed: library "xxx.so" not found 的根本原因，并聚焦于 AOSP 构建环境下因 vendor: true 标签误配导致的加载路径失效问题，提供可复现的诊断流程与精准修复方案。
本文详解 android 7.0 及以上版本中，系统级 service 加载 jni 共享库（.so）时出现 `unsatisfiedlinkerror: dlopen failed: library "xxx.so" not found` 的根本原因，并聚焦于 aosp 构建环境下因 `vendor: true` 标签误配导致的加载路径失效问题，提供可复现的诊断流程与精准修复方案。
在 Android 系统级开发（如基于 AOSP 的定制 ROM 或车载/工业固件）中，为 Service 组件集成 JNI 功能是常见需求。然而自 Android 7.0（Nougat）起，系统引入了严格的 私有库访问限制 和 ABI 隔离机制，导致原本在用户应用中可行的 System.loadLibrary("javanativetestservice_jni") 调用，在系统服务上下文中频繁抛出 java.lang.UnsatisfiedLinkError: dlopen failed: library "libjavanativetestservice_jni.so" not found ——即使 .so 文件已正确部署至 vendor/lib64/ 且已添加至 vendor/etc/public.libraries.txt。
该错误表面是“找不到库”，实则源于 Android 运行时（ART）对 库可见性策略 的精细化控制。关键在于：public.libraries.txt 仅对标记为 vendor 层且被明确声明为“公共可访问” 的原生库生效；而 AOSP 构建系统中，.so 文件的可见性由其 Android.bp（或旧版 Android.mk）中的模块属性严格决定。
以提问者环境为例（ARPI13 / RPi4 AOSP 分支），其 libjavanativetestservice_jni.so 的 Android.bp 中存在如下配置：
cc_library_shared {
name: "libjavanativetestservice_jni",
vendor: true, // ← 问题根源：强制绑定为 vendor 私有模块
srcs: ["jni/native-lib.cpp"],
shared_libs: ["liblog", "libutils"],
}虽然 vendor: true 表明该库属于 vendor 分区，但 它同时隐式启用了 proprietary: true 行为，导致 ART 在加载时跳过 public.libraries.txt 的白名单校验，直接按“私有 vendor 库”路径查找 —— 即只认 vendor/lib64/ 下的同名库，且要求调用方（Service APK）本身也必须是 vendor 签名/特权应用。而实际中，该 Service 的 PRODUCT_PACKAGES 定义未同步赋予 vendor 权限，造成权限不匹配，最终触发 dlopen failed。
✅ 正确修复方式（非 hack）：
移除 vendor: true，改用显式、安全的可见性声明：
cc_library_shared {
name: "libjavanativetestservice_jni",
// 删除 vendor: true
// 添加显式 vendor 公共声明（推荐）
vendor_available: true,
apex_available: ["com.android.runtime"],
srcs: ["jni/native-lib.cpp"],
shared_libs: ["liblog", "libutils"],
}? 验证要点：
- vendor_available: true 表示该库可被 vendor 分区应用使用，且允许通过 public.libraries.txt 白名单暴露给系统服务；
- apex_available 确保兼容 Android 10+ 的 APEX 模块化运行时；
- 构建后检查 out/target/product/<device>/vendor/lib64/ 确认 .so 存在，且 vendor/etc/public.libraries.txt 已包含 libjavanativetestservice_jni.so。
? 其他必要配套检查（缺一不可）：
- ABI 匹配：确认 libjavanativetestservice_jni.so 编译目标 ABI（如 arm64-v8a）与设备 CPU 架构一致（adb shell getprop ro.product.cpu.abi）；
- 路径规范：System.loadLibrary("javanativetestservice_jni") → 自动映射为 libjavanativetestservice_jni.so，命名必须严格匹配（含下划线，无大小写偏差）；
- SELinux 策略：若服务运行在 vendor_file 域，需确保 SELinux 允许其 dlopen 访问 vendor_file 类型文件（可通过 adb logcat -b avc 查看拒绝日志）；
- 初始化时机：在 Service.onCreate() 之前完成 System.loadLibrary()，建议置于 static 块中，避免多线程竞争。
? 总结：Android 7.0+ 的 JNI 加载失败，90% 以上并非路径或打包问题，而是构建属性与运行时策略的错配。vendor: true 是一个高风险标签——它不等于“放在 vendor 分区就自动可用”，而是触发更严格的隔离策略。真正可控的方案是：用 vendor_available: true 替代 vendor: true，配合 public.libraries.txt 白名单，并通过 aapt dump badging 和 adb shell ls vendor/lib64/ 双重验证部署状态。此模式已在 ARPI13、Android 13 LTS 及多个车规级 AOSP 项目中稳定运行。
