Esta página se ha traducido con Cloud Translation API.

Descripción general del kit de desarrollo nativo del proveedor (VNDK)

El kit de desarrollo nativo del proveedor (VNDK) es un conjunto de bibliotecas utilizadas por otras bibliotecas o archivos binarios, en la partición del proveedor o del producto, en tiempo de ejecución para dlopen.

¿Por qué VNDK?

AOSP permite actualizaciones solo del marco en las que la partición del sistema se puede actualizar a la última versión del marco mientras la partición del proveedor se deja sin cambios. A pesar de haberse creado en diferentes momentos, los archivos binarios de cada partición deben poder funcionar entre sí.

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

Dependencia entre módulos de marco y módulos de proveedores . Antes de Android 8.0, los módulos de la partición del proveedor y del sistema podían vincularse entre sí. Sin embargo, las dependencias de los módulos de proveedores impusieron restricciones no deseadas al desarrollo de módulos de marco.
Extensiones a las bibliotecas AOSP . Android requiere 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 mejorar 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 del proveedor. Para obtener pautas sobre cómo prevenir este tipo de roturas, consulte Extensiones VNDK .

Para abordar estos desafíos, Android contiene varias funciones, como VNDK (descrita en esta sección), HIDL , hwbinder, superposición de árbol de dispositivos y superposición de sepolicy.

Términos específicos de VNDK

Los documentos relacionados con VNDK utilizan la siguiente terminología:

Los módulos se refieren a bibliotecas compartidas o ejecutables. Los módulos crean dependencias en el tiempo de construcción.
Los procesos son tareas del sistema operativo generadas a partir de ejecutables. Los procesos crean dependencias en tiempo de ejecución.
Los términos calificados del marco están relacionados con la partición system :

Los ejecutables del marco se refieren a ejecutables en /system/bin o /system/xbin .
Las bibliotecas compartidas del marco se refieren a las bibliotecas compartidas en /system/lib[64] .
Los módulos del marco se refieren tanto a bibliotecas compartidas del marco como a ejecutables del marco.
Los procesos del marco son procesos generados a partir de ejecutables del marco, como /system/bin/app_process .

Los términos calificados por el proveedor están relacionados con las particiones vendor :

Los ejecutables del proveedor se refieren a los ejecutables en /vendor/bin
Las bibliotecas compartidas del proveedor se refieren a las bibliotecas compartidas en /vendor/lib[64] .
Los módulos de proveedor se refieren tanto a los ejecutables del proveedor como a las bibliotecas compartidas del proveedor.
Los procesos de proveedor son procesos generados a partir de ejecutables de proveedor, como /vendor/bin/android.hardware.camera.provider@2.4-service .

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

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

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

Bibliotecas compartidas de framework para proveedores

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

Estabilizar 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 el uso de memoria y el tamaño de almacenamiento. Una biblioteca compartida única también evita varios problemas de doble carga. 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 del marco.
Copie las bibliotecas compartidas del marco antiguo . Viene con una 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) carpetas, sockets, tuberías, memoria compartida, archivos compartidos y 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 según 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 marco que se sabe que son estables. Sus desarrolladores están comprometidos a mantener la estabilidad de 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 marco que se pueden copiar dos veces de forma segura. 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 una 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 de solo 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 marco.
- No deben acceder los módulos del proveedor.
- Tienen ABI/API inestables y no tienen garantías de compatibilidad API/ABI.
- No se copian.

HAL del mismo proceso (SP-HAL)

HAL del mismo proceso ( SP-HAL ) es un conjunto de HAL predeterminados implementados como bibliotecas compartidas de proveedores y cargados en procesos marco . 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). Los 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 los SP-HAL como los 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 vndk: {private:true} , estas bibliotecas se denominan VNDK-SP-Private y son invisibles para SP-HALS.

Las siguientes son bibliotecas exclusivas del marco con excepciones RS (FWK-ONLY-RS) :

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

Versiones VNDK

Las bibliotecas compartidas de VNDK tienen versiones:

La propiedad del sistema ro.vndk.version se agrega automáticamente a /vendor/default.prop .
Las bibliotecas compartidas VNDK y VNDK-SP se instalan como VNDK apex com.android.vndk.v${ro.vndk.version} y se montan en /apex/com.android.vndk.v${ro.vndk.version} .

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

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

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

Conjunto de pruebas de proveedores (VTS)

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