text

两个核心难题：

1. 符号冲突问题
   SP-HAL 共享库加载到框架进程时
   可能与系统库产生符号冲突

2. 运行时依赖不可见问题
   dlopen() 引入的依赖在构建时无法静态分析检测

text

┌─────────────────────────────────────────────────────────┐
│                   动态链接器 (linker)                     │
│                                                          │
│  命名空间 A                    命名空间 B                 │
│  /system/lib/libcutils.so     /system/lib/vndk-sp/       │
│                               libcutils.so               │
│                                                          │
│  ← 框架模块依赖                ← SP-HAL 依赖 →           │
│                                                          │
│  同名库，不同符号，互相隔离，不冲突                        │
└─────────────────────────────────────────────────────────┘

公共库示例：/system/lib/libc.so
  → 由一个命名空间导出
  → 被导入到多个命名空间
  → 其依赖项(libnetd_client.so)对其他命名空间不可见

text

dlopen() / DT_NEEDED 触发加载
         │
         ▼
  找出调用方所在的命名空间
         │
         ▼
  尝试在同一命名空间中加载依赖
         │
    ┌────┴────┐
   成功      失败
    │         │
    ▼         ▼
  完成    向关联命名空间
        索取导出的共享库
              │
         ┌────┴────┐
        找到      找不到
         │         │
         ▼         ▼
       完成      报错

Bash

Android 8/9:   /system/etc/ld.config.txt
Android 11+:   /linkerconfig/ld.config.txt  # 运行时动态生成

ini

# ① 目录-区段映射（决定哪个可执行文件用哪套配置）
dir.system = /system/bin
dir.system = /system/xbin
dir.vendor = /vendor/bin

# ② system 进程的命名空间配置
[system]
additional.namespaces = sphal,vndk   # 除default外还有2个命名空间

# default 命名空间
namespace.default.isolated = true
namespace.default.search.paths = /system/${LIB}
namespace.default.permitted.paths = /system/${LIB}/hw

# sphal 命名空间（SP-HAL）
namespace.sphal.isolated = true
namespace.sphal.visible = true
namespace.sphal.search.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.permitted.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.links = default,vndk              # 回退顺序
namespace.sphal.link.default.shared_libs = libc.so:libm.so
namespace.sphal.link.vndk.shared_libs = libbase.so:libcutils.so

# vndk 命名空间
namespace.vndk.isolated = true
namespace.vndk.search.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.links = default
namespace.vndk.link.default.shared_libs = libc.so:libm.so

# ③ vendor 进程的命名空间配置
[vendor]
namespace.default.isolated = false   # vendor不隔离
namespace.default.search.paths = /vendor/${LIB}:/system/${LIB}

text

属性                                    含义
─────────────────────────────────────────────────────────
isolated = true/false                  是否启用路径隔离检查
search.paths                           库搜索目录（不含子目录）
permitted.paths                        允许加载的目录（含子目录）
asan.search.paths                      ASan模式下的搜索路径
links                                  回退命名空间列表（有序）
link.X.shared_libs                     回退时允许的库名白名单
link.X.allow_all_shared_libs = true    回退时允许所有库（与上互斥）
visible = true/false                   是否可被android_get_exported_namespace()获取

注意：${LIB} 占位符
  32位进程 → lib
  64位进程 → lib64

text

PRODUCT_TREBLE_        BOARD_VNDK_
LINKER_NAMESPACES      VERSION        配置类型      适用场景
─────────────────────────────────────────────────────────
true                   current        VNDK          Android 9+ 必须
true                   空             VNDK Lite     Android 8.x 必须
false                  空             Legacy        不支持Treble的设备

text

框架进程命名空间：
  default  ← 系统共享库
  vndk     ← VNDK-SP 库
  sphal    ← SP-HAL 库
  rs       ← RenderScript

供应商进程命名空间：
  default  ← 供应商共享库
  vndk     ← VNDK/VNDK-SP 库
  system   ← LL-NDK 及依赖

核心保证：system分区模块不依赖vendor库，反之亦然

text

只隔离 SP-HAL 和 VNDK-SP 共享库
符号不与其他框架共享库冲突

text

Android 7.0 之前：
  dlopen("/system/lib/libandroid_runtime.so") ✅ 成功

Android 7.0 之后：
  dlopen("/system/lib/libandroid_runtime.so") ❌ 失败

text

库类型              targetSdkVersion    Android 7.0 行为
─────────────────────────────────────────────────────
公开 NDK 库         任何                ✅ 正常运行
私有暂时可访问库     ≤ 23               ⚠️ 可访问但有 logcat 警告
私有暂时可访问库     ≥ 24               ❌ 运行时错误，崩溃
其他私有库          任何                ❌ 运行时错误，崩溃

text

libandroid_runtime.so
libcutils.so
libcrypto.so
libssl.so

text

# 警告（targetSdk ≤ 23）
W linker: library "libandroid_runtime.so" needed or dlopened by
"/data/app/com.example/lib/arm/libapp.so" is not accessible
for the namespace "classloader-namespace" - the access is
temporarily granted as a workaround for http://b/26394120

# 崩溃（targetSdk ≥ 24）
java.lang.UnsatisfiedLinkError: dlopen failed:
library "libcutils.so" is not accessible
for the namespace "classloader-namespace"

text

libEGL.so          libGLESv1_CM.so    libGLESv2.so
libGLESv3.so       libc.so            libdl.so
liblog.so          libm.so            libvulkan.so
libnativewindow.so libsync.so         libvndksupport.so
libandroid_net.so  libneuralnetworks.so

text

libbase.so         libc++.so          libcutils.so
libhidlbase.so     libhidltransport.so libhwbinder.so
libutils.so        libz.so            libion.so
libhardware.so     libhidlmemory.so
android.hardware.graphics.common@1.0.so
android.hardware.graphics.mapper@2.0.so
...

text

Android 7.0 (N)
  └─ 首次引入命名空间隔离
  └─ 禁止应用访问私有平台库
  └─ 使用静态 ld.config.txt 文件

Android 8.0 (O)
  └─ 引入 VNDK Lite 配置
  └─ SP-HAL / VNDK-SP 隔离

Android 8.1 (O MR1)
  └─ VNDK 完整配置成为默认
  └─ system ↔ vendor 完全隔离

Android 9 (P)
  └─ vendor 进程增加 vndk 命名空间
  └─ VNDK 库与默认命名空间隔离
  └─ 重命名配置文件
  └─ 添加 product / odm 分区支持

Android 11 (R)
  └─ 移除静态 ld.config.*.txt
  └─ LinkerConfig 在启动时动态生成
  └─ 根据运行时环境（APEX等）自动适配

text

问题                          解决方案
──────────────────────────────────────────────────────
使用私有平台库                 ① 使用公开 NDK API 替代
                              ② 将库副本打包进 APK

使用访问私有符号的第三方库      联系库作者更新

libandroid_runtime.so         使用 <jni.h> 标准函数：
的 getJavaVM/getJNIEnv         GetJavaVM / JavaVM::GetEnv

libcutils.so 的               使用 __system_property_get
property_get                  #include <sys/system_properties.h>

libcrypto.so 的 SSL_ctrl      静态链接 libcrypto.a
                              或打包 BoringSSL/OpenSSL

检测是否使用私有库             aarch64-linux-android-readelf
                              -dW libMyLibrary.so

text

命名空间隔离 = 动态链接器强制执行的库访问边界

目的：
  防止符号冲突 + 强制 System/Vendor 分区解耦

实现：
  ld.config.txt 定义命名空间 → 
  每个进程只能访问其命名空间内或被显式导出的库

结果：
  应用/vendor 无法随意使用私有系统库
  system 和 vendor 分区可以独立更新（Treble 基础）