Se usó la API de Cloud Translation para traducir esta página.

Kit de desarrollo nativo del proveedor (VNDK)

El Vendor Native Development Kit (VNDK) es un conjunto de bibliotecas exclusivamente para que los proveedores implementen sus HAL. El VNDK se envía en system.img y se vincula dinámicamente al código del proveedor en tiempo de ejecución.

¿Por qué VNDK?

Android 8.0 y versiones posteriores permiten actualizaciones solo del marco en las que la partición del sistema se puede actualizar a la última versión mientras que las particiones del proveedor no se modifican. Esto implica que los binarios creados en diferentes momentos deben poder funcionar entre sí; VNDK cubre los cambios de API/ABI en las versiones de Android.

Las actualizaciones solo del marco incluyen los siguientes desafíos:

Dependencia entre los módulos del marco y los módulos del proveedor . Antes de Android 8.0, los módulos de ambos lados podían vincularse con módulos del otro lado. Sin embargo, las dependencias de los módulos del proveedor impusieron restricciones no deseadas al desarrollo de los módulos del marco.
Extensiones a las bibliotecas AOSP . Android 8.0 y versiones posteriores requieren que todos los dispositivos Android pasen CTS cuando la partición del sistema se reemplaza con una imagen genérica del sistema (GSI) estándar. Sin embargo, a medida que los proveedores amplían las bibliotecas AOSP para aumentar el rendimiento o agregar funcionalidades adicionales para sus implementaciones HIDL, actualizar la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. (Para obtener pautas sobre cómo prevenir dichas roturas, consulte las extensiones de VNDK ).

Para abordar estos desafíos, Android 8.0 presenta varias técnicas, como VNDK (descrito en esta sección), HIDL , hwbinder, superposición de árbol de dispositivos y superposición de políticas.

Recursos VNDK

Esta sección incluye los siguientes recursos de VNDK:

Los conceptos de VNDK (a continuación) describen las bibliotecas compartidas del marco, las HAL del mismo proceso (SP-HAL) y la terminología de VNDK.
Las extensiones VNDK clasifican los cambios específicos del proveedor en categorías. Por ejemplo, las bibliotecas con funcionalidades extendidas en las que se basan los módulos del proveedor deben copiarse en la partición del proveedor, pero los cambios incompatibles con ABI están prohibidos.
Compatibilidad con el sistema de compilación de VNDK describe las configuraciones del sistema de compilación y las sintaxis de definición de módulos relacionadas con VNDK.
La herramienta de definición de VNDK ayuda a migrar su árbol fuente a Android 8.0 y versiones posteriores.
Linker Namespace proporciona un control detallado sobre los enlaces de bibliotecas compartidas.
Directorios, reglas y política de seguridad define la estructura de directorios para dispositivos que ejecutan Android 8.0 y versiones posteriores, reglas de VNDK y política de seguridad asociada.
La presentación de VNDK Design ilustra los conceptos fundamentales de VDNK que se usan en Android 8.0 y versiones posteriores.

Conceptos de VNDK

En un mundo ideal con Android 8.0 y superior, los procesos del marco no cargan bibliotecas compartidas del proveedor, todos los procesos del proveedor cargan solo bibliotecas compartidas del proveedor (y una parte de las bibliotecas compartidas del marco) y las comunicaciones entre los procesos del marco y los procesos del proveedor se rigen por HIDL y hardware. aglutinante.

Tal mundo incluye la posibilidad de que las API públicas y estables de las bibliotecas compartidas del marco no sean suficientes para los desarrolladores de módulos de proveedores (aunque las API pueden cambiar entre las versiones de Android), lo que requiere que una parte de las bibliotecas compartidas del marco sea accesible para los procesos del proveedor. Además, dado que los requisitos de rendimiento pueden generar compromisos, algunas HAL críticas para el tiempo de respuesta deben tratarse de manera diferente.

Las siguientes secciones detallan cómo VNDK maneja las bibliotecas compartidas del marco para los proveedores y las HAL del mismo proceso (SP-HAL).

Bibliotecas compartidas del marco para el proveedor

Esta sección describe los criterios para clasificar las bibliotecas compartidas a las que pueden acceder los procesos del proveedor. Existen dos enfoques para admitir módulos de proveedores en varias versiones de Android:

Estabilice las ABI/API de las bibliotecas compartidas del marco . Los nuevos módulos de marco y los módulos de proveedores antiguos pueden usar la misma biblioteca compartida para reducir la huella de memoria y el tamaño de almacenamiento. Una biblioteca compartida única también evita varios problemas de carga doble. Sin embargo, el costo de desarrollo para mantener ABI/API estables es alto y no es realista estabilizar todas las ABI/API exportadas por cada biblioteca compartida de framework.
Copie las bibliotecas compartidas del marco antiguo . Viene con la fuerte restricción contra los canales laterales, definidos como todos los mecanismos para comunicarse entre los módulos del marco y los módulos del proveedor, incluidos (entre otros) el enlazador, el zócalo, la canalización, la memoria compartida, el archivo compartido y las propiedades del sistema. No debe haber comunicación a menos que el protocolo de comunicación esté congelado y estable (por ejemplo, HIDL a través de hwbinder). La carga doble de bibliotecas compartidas también puede causar problemas; por ejemplo, si un objeto creado por la nueva biblioteca se pasa a las funciones de la biblioteca anterior, puede ocurrir un error ya que estas bibliotecas pueden interpretar el objeto de manera diferente.

Se utilizan diferentes enfoques dependiendo de las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas del marco se clasifican en tres subcategorías:

Las bibliotecas LL-NDK son bibliotecas compartidas de Framework que se sabe que son estables. Sus desarrolladores están comprometidos a mantener sus estabilidades API/ABI.
- LL-NDK incluye las siguientes bibliotecas: 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 y libvulkan.so ,
Las bibliotecas VNDK elegibles (VNDK) son bibliotecas compartidas de Framework que se pueden copiar dos veces con seguridad. Los módulos de marco y los módulos de proveedores pueden vincularse con sus propias copias. Una biblioteca compartida de marco puede convertirse en una biblioteca VNDK elegible solo si cumple con los siguientes criterios:
- No envía/recibe IPC hacia/desde el marco.
- No está relacionado con la máquina virtual ART.
- No lee/escribe archivos/particiones con formatos de archivo inestables.
- No tiene licencia de software especial que requiera revisiones legales.
- El propietario de su código no tiene objeciones a los usos de los proveedores.
Las bibliotecas solo de marco (FWK-ONLY) son bibliotecas compartidas de marco que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
- Se consideran detalles de implementación interna del framework.
- No debe ser accedido por módulos de proveedores.
- Tener ABI/API inestables y sin garantías de compatibilidad API/ABI.
- No se copian.

Mismo proceso HAL (SP-HAL)

HAL del mismo proceso ( SP-HAL ) es un conjunto de HAL predeterminadas implementadas como bibliotecas compartidas de proveedores y cargadas en Framework Processes . Los SP-HAL están aislados por un espacio de nombres de vinculador (controla las bibliotecas y los símbolos que son visibles para las bibliotecas compartidas). Las SP-HAL deben depender únicamente de LL-NDK y VNDK-SP .

VNDK-SP es un subconjunto predefinido de bibliotecas VNDK elegibles. Las bibliotecas VNDK-SP se revisan cuidadosamente para garantizar que la carga doble de bibliotecas VNDK-SP en los procesos del marco no cause problemas. Tanto SP-HAL como VNDK-SP están definidos por Google.

Las siguientes bibliotecas son SP-HAL aprobadas:

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

Las bibliotecas VNDK-SP especifican vndk: { support_system_process: true } en sus archivos Android.bp. Si también se especifica vendor_available: false , estas bibliotecas se denominan VNDK-SP-Private y son invisibles para SP-HALS .

Las siguientes son bibliotecas solo de marco con excepciones RS (FWK-ONLY-RS) :

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

Terminología VNDK

Los módulos se refieren a bibliotecas compartidas o ejecutables .
Los procesos son tareas del sistema operativo generadas a partir de Executables .
Marco : los términos calificados se refieren a los conceptos relacionados con la partición del sistema .
Los términos calificados por el proveedor se refieren a los conceptos relacionados con las particiones del proveedor .

Por ejemplo:

Los ejecutables de Framework se refieren a ejecutables en /system/bin o /system/xbin .
Las bibliotecas compartidas de Framework hacen referencia a las bibliotecas compartidas en /system/lib[64] .
Los módulos de Framework hacen referencia tanto a las bibliotecas compartidas de Framework como a los ejecutables de Framework.
Los Procesos de Framework son procesos generados a partir de Ejecutables de Framework (por ejemplo /system/bin/app_process ).
Los ejecutables del proveedor hacen referencia a los ejecutables en /vendor/bin
Las bibliotecas compartidas de proveedores hacen referencia a las bibliotecas compartidas en /vendor/lib[64] .
Los módulos de proveedores hacen referencia tanto a los ejecutables de proveedores como a las bibliotecas compartidas de proveedores .
Los procesos de proveedores son procesos generados a partir de ejecutables de proveedores (por ejemplo,

/vendor/bin/android.hardware.camera.provider@2.4-service

Versionado de VNDK

En Android 9, las bibliotecas compartidas de VNDK están versionadas:

La propiedad del sistema ro.vndk.version se agrega automáticamente a /vendor/default.prop .
Las bibliotecas compartidas de VNDK se instalan en /system/lib[64]/vndk-${ro.vndk.version} .
Las bibliotecas compartidas de VNDK-SP se instalan en /system/lib[64]/vndk-sp-${ro.vndk.version} .
El archivo de configuración del vinculador dinámico se instala en /system/etc/ld.config.${ro.vndk.version}.txt .

El valor de ro.vndk.version se elige mediante el siguiente algoritmo:

Si BOARD_VNDK_VERSION no es igual al current , use BOARD_VNDK_VERSION .
Si BOARD_VNDK_VERSION es igual a current :

Si PLATFORM_VERSION_CODENAME es REL , utilice PLATFORM_SDK_VERSION (por ejemplo, 28 ).
De lo contrario, utilice PLATFORM_VERSION_CODENAME (por ejemplo, P ).

Actualización de dispositivos

Si un dispositivo con Android 8.x inhabilitó la aplicación de tiempo de ejecución de VNDK al compilarse sin BOARD_VNDK_VERSION , puede agregar PRODUCT_USE_VNDK_OVERRIDE := false a BoardConfig.mk mientras se actualiza a Android 9.

Si PRODUCT_USE_VNDK_OVERRIDE es false , la propiedad ro.vndk.lite se agregará automáticamente a /vendor/default.prop y su valor será true . En consecuencia, el vinculador dinámico cargará la configuración del espacio de nombres del vinculador desde /system/etc/ld.config.vndk_lite.txt , que aísla solo SP-HAL y VNDK-SP.

Para actualizar un dispositivo Android 7.0 o inferior a Android 9, agregue PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false a BoardConfig.mk .

Conjunto de pruebas de proveedores (VTS)

Android 9 Vendor Test Suite (VTS) exige una propiedad ro.vndk.version no vacía. Tanto los dispositivos recién lanzados como los dispositivos actualizados deben definir ro.vndk.version . Algunos casos de prueba de VNDK (por ejemplo VtsVndkFilesTest y VtsVndkDependencyTest ) se basan en la propiedad ro.vndk.version para cargar los conjuntos de datos de bibliotecas VNDK elegibles coincidentes.

Si la propiedad ro.product.first_api_level es mayor que 27, no se debe definir la propiedad ro.vndk.lite . VtsTreblePlatformVersionTest fallará si se define ro.vndk.lite en un dispositivo Android 9 recién lanzado.

Historia del documento

Esta sección rastrea los cambios en la documentación de VNDK.

Cambios en Android 9

Agregue la sección de control de versiones de VNDK.
Agregar sección VTS.
Se ha cambiado el nombre de algunas categorías de VNDK:

Se cambió el nombre de LL-NDK-Indirect a LL-NDK-Private.
Se cambió el nombre de VNDK-Indirect a VNDK-Private.
Se cambió el nombre de VNDK-SP-Indirect-Private a VNDK-SP-Private.
Se eliminó VNDK-SP-Indirect.

Cambios en Android 8.1

Las bibliotecas SP-NDK se fusionaron en bibliotecas LL-NDK.
Reemplace libui.so con libft2.so en la sección de espacio de nombres RS. Fue un error incluir libui.so .
Agregue libGLESv3.so y libandroid_net.so a las bibliotecas LL-NDK.
Agregue libion.so a las bibliotecas VNDK-SP.
Elimina libstdc++.so de las bibliotecas LL-NDK. Utilice libc++.so en su lugar. Algunas versiones de cadenas de herramientas independientes pueden agregar -lstdc++ a los indicadores predeterminados del enlazador. Para deshabilitar los valores predeterminados, agregue -nodefaultlibs -lc -lm -ldl a LDFLAGS .
Mueva libz.so de las bibliotecas LL-NDK a VNDK-SP. En algunas configuraciones, libz.so puede seguir siendo LL-NDK. Sin embargo, no debería haber diferencias observables.