VNDK (一) OverView

VNDK (一) OverView

Vendor Native Development Kit (VNDK)

The Vendor Native Development Kit (VNDK) is a set of libraries exclusively for vendors to implement their HALs. The VNDK ships in system.img and is dynamically linked to vendor code at runtime.

VNDK是一组专用于供应商实现其HALs的库。VNDK在系统中ship。并在运行时动态链接到供应商代码。

Why VNDK?

Android 8.0 and higher enables framework-only updates in which the system partition can be upgraded to the latest version while vendor partitions are left unchanged. This implies that binaries built at different times must be able to work with each other; VNDK covers API/ABI changes across Android releases.

Android 8.0及更高版本只支持框架更新，其中系统分区可以升级到最新版本，而供应商分区保持不变。这意味着在不同时间构建的二进制文件必须能够相互协作;VNDK涵盖了Android版本中API/ABI的变化。

Framework-only updates include the following challenges:
Dependency between framework modules and vendor modules. Before Android 8.0, modules from both sides could link with modules from the other side. However, dependencies from vendor modules imposed undesired restrictions to framework modules development.
Extensions to AOSP libraries. Android 8.0 and higher requires all Android devices to pass CTS when the system partition is replaced with a standard Generic System Image (GSI). However, as vendors extend AOSP libraries to boost performance or to add extra functionalities for their HIDL implementations, flashing the system partition with a standard GSI might break a vendor’s HIDL implementation. (For guidelines on preventing such breakages, see VNDK extensions.)
To address these challenges, Android 8.0 introduces several techniques such as VNDK (described in this section), HIDL, hwbinder, device tree overlay, and sepolicy overlay.

框架更新设计以下问题:
框架模块和供应商模块之间的依赖关系。在Android 8.0之前，来自双方的模块可以链接到另一方的模块。然而，来自供 应商模块的依赖关系对框架模块开发施加了不必要的限制。
对AOSP库的扩展。Android 8.0及更高版本要求所有Android设备在使用标准通用系统映像(GSI)替换系统分区时都要通过CTS。然而，当供应商扩展AOSP库以提高性能或为他们的HIDL实现添加额外的功能时，使用标准GSI显示系统分区可能会破坏供应商的HIDL实现。(避免这样的破坏，请参阅VNDK扩展。)
为了解决这些挑战，Android 8.0引入了几种技术，如VNDK(本节将介绍)、HIDL、hwbinder、设备树覆盖和sepolicy覆盖。

VNDK resources

This section includes the following VNDK resources:
VNDK concepts (below) describes framework shared libraries, same-process HALs (SP-HALs), and VNDK terminology.
VNDK extensions classifies vendor-specific changes into categories. For example, libraries with extended functionalities on which vendor modules rely must be copied into the vendor partition, but ABI-incompatible changes are prohibited.
VNDK Build System Support describes the build system configurations and module definition syntaxes that are related to VNDK.
The VNDK Definition Tool helps migrate your source tree to Android 8.0 and higher.
Linker Namespace provides fine-grained control over shared library linkages.
Directories, Rules, and sepolicy defines the directory structure for devices running Android 8.0 and higher, VNDK rules, and associated sepolicy.
The VNDK Design presentation illustrates fundamental VDNK concepts used in Android 8.0 and higher.

这段包含以下的VNDK资源：
VNDK概念(以下)描述了框架共享库、相同进程HALs (SP-HALs)和VNDK术语。
VNDK扩展把vendor相关的修改分成很多类别，例如，vendor模块依赖的库文件必须拷贝到vendor分区，但是禁止ABI不兼容的修改；
VNDK构建系统支持描述与VNDK相关的构建系统配置和模块定义语法；
VNDK定义工具帮助您将源代码树迁移到Android 8.0或更高版本。VNDK构建系统支持描述与VNDK相关的构建系统配置和模块定义语法；
链接器名称空间提供对共享库链接的精细控制；
目录、规则和sepolicy为运行Android 8.0及更高版本的设备、VNDK规则和相关的sepolicy定义了目录结构；
VNDK设计演示说明了在Android 8.0及更高版本中使用的基本VDNK概念；

VNDK concepts

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).

android 8.0 以上版本 ，framwork 进程不在加载vendor共享库，所有的vendor 进程加载vendor共享库；framwork 和 vendor进程通过HIDL和binder通信；
这样的系统带来一种可能：对于模块开发者来说没有足够的API和共享库，这要求框架共享库的某些部分可以被供应商进程访问。此外，由于性能需求可能导致折衷，因此必须以不同的方式处理一些响应及时的HAL模块；

这里是引用
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.

Different approaches are used depending on the characteristics of the shared libraries. As a result, framework shared libraries are classified into three sub-categories:

LL-NDK Libraries are Framework Shared Libraries that are known to be stable. Their developers are committed to maintain their API/ABI stabilities.
LL-NDK includes the following libraries: 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, and libvulkan.so,
Eligible VNDK Libraries (VNDK) are Framework Shared Libraries that are safe to be copied twice. Framework Modules and Vendor Modules can link with their own copies. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
It does not send/receive IPCs to/from the framework.
It is not related to ART virtual machine.
It does not read/write files/partitions with unstable file formats.
It does not have special software license which requires legal reviews.
Its code owner does not have objections to vendor usages.
Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
Are considered framework internal implementation details.
Must not be accessed by vendor modules.
Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL (SP-HAL) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes. SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP.

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved SP-HALs:

libGLESv1_CM_KaTeX parse error: Expected group after '_' at position 26: …o libGLESv2_̲{driver}.so
libGLESv3_KaTeX parse error: Expected group after '_' at position 23: …}.so libEGL_̲{driver}.so
vulkan.${driver}.so
android.hardware.renderscript@1.0-impl.so
android.hardware.graphics.mapper@2.0-impl.so

The following libraries are VNDK-SP libraries that are accessible by SP-HALs:

android.hardware.graphics.common@1.0.so
android.hardware.graphics.mapper@2.0.so
android.hardware.renderscript@1.0.so (Renderscript)
libRS_internal.so (Renderscript)
libbase.so
libc++.so
libcutils.so
libhardware.so
libhidlbase.so
libhidltransport.so
libhwbinder.so
libion.so
libutils.so
libz.so

The following VNDK-SP dependencies (VNDK-SP-Private) are invisible to SP-HALs:

libRSCpuRef.so (Renderscript)
libRSDriver.so (Renderscript)
libbacktrace.so
libblas.so (Renderscript)
libbcinfo.so (Renderscript)
liblzma.so
libunwind.so

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS):

libft2.so (Renderscript)
libmediandk.so (Renderscript)