Android-HAL (三) VNDK

原创已于 2025-12-19 08:34:47 修改 · 87 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#其他

于 2025-12-17 13:40:42 首次发布

VNDK 是什么

vendor分区native开发需要使用的一系列库

https://source.android.google.cn/docs/core/architecture/vndk?hl=zh-cn#vndk-deprecation-details

为了解耦，system 分区进程不可以加载 vendor 分区中的库，

vendor 分区进程仅加载 vendor 分区中的库和部分 system 分区中的库

framework 和 vendor 之间按照 HIDL/AIDL 方式，通过 IPC/hwbinder 的方式来通信

现在的问题是 framework 和 vendor 的 modules（包括了 so 和 bin），依赖于同一份公共的库，系统升级时一旦这些库的 ABI/API 发生变化，那么framework 和 vendor 都要同步升级。

所以改造的核心就是 framework modules 和 vendor modules 都依赖的那份公共的库。也就是下图中的那个 Dependencies。这些 Dependencies 就是在引入 Treble 设计之前原先 framework 维护的那组 framework modules

LL-NDK

Low Level NDK，Dependencies 中的一类库 API/ABI 相对稳定的，它们的开发者致力于保持其 API/ABI 稳定性，不会因为 AOSP 的升级而轻易改变。这都是一些非常底层的基础库，仍然保持一份，framework 和 vendor 共享同一套

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

VNDK | FWK-ONLY

注意 FWK-ONLY 和 VNDK 这两部分还都在system image 中

Dependencies 中另一些会被 framework 和 vendor 访问。会将其做成两份。

如下图，libcamera_metadata.so 这个库既会被 Framework 访问，又会被 vendor （图上是 camera.provider@2.4-impl.so）访问。

那么对于这样的库，在编译时会将其做成两份，

一份给 Framework用，即图中的 libcamera_metadata.so (FWK-ONLY) "core variant"

一份给 vendor用，即图中的 libcamera_metadata.so (VNDK) "vendor variant"

假设需要升级版本，采用的 Framework 和 VNDK 版本都是 26，结合上图

libcamera_metadata.so (FWK-ONLY) 属于 Framework-26 部分

libcamera_metadata.so (VNDK) 属于 VNDK-26，

camera.provider@2.4-impl.so 属于 Vendor-26 部分。那么 vendor module 构建时都是基于 VNDK-26 的，工作正常。

升级系统时，system image升级新的 Framework-27，其中 libcamera_metadata.so (FWK-ONLY) 升级到新的 27，而 VNDK 部分保留 VNDK-26。

这样新系统启动后，Vendor-26 部分的 camera.provider@2.4-impl.so 依然会链接 VNDK-26 版本的libcamera_metadata.so (VNDK)，

framework 会链接 27 版本的 libcamera_metadata.so (FWK-ONLY)。

VNDK-SP

VNDK-SP 是服务于SP-HAL的VNDK中的某几个库

如图libGLES_${chipset}.so 是一个 SP-HAL。surfaceflinger 这个system 进程要进行 GPU 合成的时候，需要访问位于 vendor 分区的 GPU 驱动（libvendor_gpu.so），此时需要通过 libGLES_${chipset}.so 这个 HAL 代理，和普通 HAL 通过 IPC 方式不同，SP-HAL 是将该 so 直接 dlopen 加载到 surfaceflinger 进程。

属于 framework的 surfaceflinger 和 vendor 的 libGLES_${chipset}.so 都要依赖 libcutils.so，同样要遵循 VNDK 的要求，将 libcutils.so 一式两份，其中libcutils.so为 VNDK-SP。

普通 VNDK 中 HAL的service 和 client 之间采用 IPC，所以 libcamera_metadata.so (FWK-ONLY) 和 libcamera_metadata.so (FWK-VNDK) 实际加载在两个不同的进程中，不存在名字冲突的问题。

但是在 VNDK-SP 中 libcutils.so (FWK-ONLY) 和 libcutils.so (VNDK-SP) 两个 so 都会被加载到 surfaceflinger 这个进程中，为了解决加载冲突的问题，Google 又引入了 linker namespace