android framework实战之VNDK深入剖析

千里马学框架

已于 2024-01-02 09:06:05 修改

阅读量1.4k

点赞数 21

分类专栏： hal 文章标签： android 车机车载 framework 分屏 hal vndk hidl

于 2023-12-10 13:35:41 首次发布

本文链接：https://blog.csdn.net/learnframework/article/details/134889443

版权

hal 专栏收录该内容

10 篇文章 18 订阅

订阅专栏

参考链接：
https://source.android.google.cn/docs/core/architecture/vndk

什么是VNDK
官方：
The Vendor Native Development Kit (VNDK) is a set of libraries used by other libraries or binaries, in the vendor or product partition, on runtime for dlopen.
解释：
即给vendor分区的native程序提供的开发套件，包含了被vendor的native需要使用的一系列的库

为什么要VNDK
官方：
Why VNDK?
AOSP allows framework-only updates in which the system partition can be upgraded to the latest framework version while vendor partition is left unchanged. Despite being built at different times, binaries in each partition must be able to work with each other.

解释：
aosp允许framework部分在system分区进行单独升级，但同时vendor分区还是以前的版本，尽管在不同时间编译，各自分区的执行程序需要可以正常允许
在这里插入图片描述
需要让framework单独更新会面临以下挑战：

1 框架模块与供应商模块之间的依赖关系。
2 AOSP 库的扩展。

为了应对这些挑战，Android 8.0 引入了一些技术，例如 VNDK、HIDL、hwbinder、设备树叠加层和 sepolicy 叠加层。

VNDK的概念
官方原文：

In an ideal Android 8.0 and higher world, framework processes do not load vendor shared libraries, all vendor processes load only vendor shared libraries (and a portion of framework shared libraries), and communications between framework processes and vendor processes are governed by HIDL and hardware binder.

Such a world includes the possibility that stable, public APIs from framework shared libraries might not be sufficient for vendor module developers (although APIs can change between Android releases), requiring that some portion of framework shared libraries be accessible to vendor processes. In addition, as performance requirements can lead to compromises, some response-time-critical HALs must be treated differently.

The following sections detail how VNDK handles framework shared libraries for vendors and Same-Process HALs (SP-HALs).

Framework shared libraries for vendor
This section describes the criteria for classifying shared libraries that are accessible to vendor processes. There are two approaches to support vendor modules across multiple Android releases:

Stabilize the ABIs/APIs of the framework shared libraries. New framework modules and old vendor modules can use the same shared library to reduce memory footprint and storage size. A unique shared library also avoids several double-loading issues. However, the development cost to maintain stable ABIs/APIs is high and it is unrealistic to stabilize all ABIs/APIs exported by every framework shared library.
Copy old framework shared libraries. Comes with the strong restriction against side channels, defined as all mechanisms to communicate among framework modules and vendor modules, including (but not limited to) binder, socket, pipe, shared memory, shared file, and system properties. There must be no communication unless the communication protocol is frozen and stable (e.g. HIDL through hwbinder). Double-loading shared libraries might cause problems as well; for example, if an object created by the new library is passed into the functions from the old library, an error may occur as these libraries may interpret the object differently.

解释：

framework的库提供给vendor情况：

要让vendor可以适配多个framework版本，那么framework库需要提供给vendor需要以下2个方法：
1、使framework库保持api稳定，framewor和vendor使用同一份共享库，节省空间避免双重加载，但是保持库的接口稳定成本很高，每个库都稳定基本不可能
2、拷贝一份旧版本framework库，这个方式肯定会在运行时候影响vendor和framework通讯，比如binder，socket等,除非通讯的协议一直被冻结或者稳定，不然肯定会有问题，比如framework新库创建对象传递到旧库函数就完全有可能旧库无法使用。

所以根据以上背景，需要把共享库的特性不同进行分类，framework的库一般分为3类提供给vendor：
在这里插入图片描述官方ppt：

上面讲解清楚了framework的共享库给vendor使用的情况，下面就需要讲解vendor库也可能给framework依赖使用的情况。
Same-Process HAL (SP-HAL)
SP-HAL就是一系列的预先确定的hal，作为vendor的共享库进行实现，并且是被framework的进程进行加载的。SP-HAL必须只依赖LL-NDK和VNDK-SP库。
VNDK-SP 是预定义好的一部分VNDK库，VNDK-SP需要被严格审查保证双边加载到framework进程不会有问题，SP-HAL和VNDK-SP都是被google定义好的。

以下库是经过批准的 SP-HAL：

libGLESv1_CM_${driver}.so
libGLESv2_${driver}.so
libGLESv3_${driver}.so
libEGL_${driver}.so
vulkan.${driver}.so
android.hardware.renderscript@1.0-impl.so
android.hardware.graphics.mapper@2.0-impl.so

在这里插入图片描述每个分区的灰色的库可以被对方分区依赖，红色不可以

官方ppt图：
在这里插入图片描述

在这里插入图片描述

Android.bp识别属于哪一种库

core libraries are used by the system image, on the system image. These libraries can't be used by vendor, vendor_available, vndk, or vndk-sp libraries.

//这种没有任何其他特殊标签，即默认的，那么就是system独有库
cc_library {
    name: "libThatIsCore",
    ...
}


vendor-only (or proprietary) libraries are used by the vendor image, on the vendor image.

//proprietary标签，那么就是vendor独有库，system下面没有
cc_library {
    name: "libThatIsVendorOnly",
    proprietary: true,
    # or: vendor: true, # (for things in AOSP)
    ...
}
vendor_available libraries are used by the vendor image, on the vendor image (may contain duplicates of core).

//只有一个vendor_available标签，那么就是vendor和system都有的库
cc_library {
    name: "libThatIsVendorAvailable",
    vendor_available: true,
    ...
}
vndk libraries are used by the vendor image, on the system image.

//vendor_available标签 +vndk标签 ，那么就是system有这个库，而且vendor分区没有，但属于vndk在system下面的vndk相关路径还有一个库专门给vendor使用
cc_library {
    name: "libThatIsVndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    }
    ...
}
vndk-sp libraries are used by the vendor image, and also by the system image indirectly.
//和上面的vndk情况一样，只不过这类vndk库被sp-hals有使用了叫vndk-sp
cc_library {
    name: "libThatIsVndkSp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    }
    ...
}

VNDK存放位置相关

In Android 10 and lower, modules with vndk.enabled were installed in /system/lib[64]/vndk[-sp]-${VER}. In Android 11 and higher, VNDK libraries are packaged in an APEX format and the name of VNDK APEX is com.android.vndk.v${VER}. Depending on the device configuration, VNDK APEX is flattened or unflattened and is available from the canonical path /apex/com.android.vndk.v${VER}.

经过aosp13实验发现out/target/product/nx563j/system/apex/com.android.vndk.current.apex 文件。这个文件在系统启动阶段会被解压开后挂载在 /apex/com.android.vndk.v${VER}

修改的vendor 中使用的vndk的so时候，需要特别这注意！！

以下技巧基于aosp13，修改一些vndk库后进行编译，编译方式一定要注意：
例如：
修改了ProcessState.cpp这个类
在这里插入图片描述注意代码原来的基础上driver后面加了个1

如果只是想要在system下面程序体现，make libbinder，然后push system/lib64/libbinder.so /system/lib64下面既可以，但是这样无法体现到vendor分区相关的程序，因为他们依赖是vndk相关的库
所以结果如下：

test@test:~/aosp$ adb shell kill 974;adb logcat | grep "lsm Binder"
12-08 23:57:48.289  3045  5563 E ProcessState: lsm Binder driver 1 /dev/binder 
12-08 23:57:55.506  5586  5586 E ProcessState: lsm Binder driver /dev/vndbinder

但如果要在vendor下面程序也体现到这个更新需要如下操作：

1、编译时候不能编译libinder这个库了，应该编译如下apex
make com.android.vndk.current

2、然后push 这个apex文件到相关的目录
adb push out/target/product/nx563j/system/apex/com.android.vndk.current.apex /system/apex/

正确结果如下，vendor和system程序都体现了修改

test@test:~/aosp$ adb shell kill 981;adb logcat | grep "lsm Binder"
12-09 00:06:37.336  3023  5646 E ProcessState: lsm Binder driver 1 /dev/binder 
12-09 00:06:40.730  5665  5665 E ProcessState: lsm Binder driver 1 /dev/vndbinder