Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Kit de desarrollo nativo de proveedor (VNDK)

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 está vinculado dinámicamente al código del proveedor en tiempo de ejecución.

¿Por qué VNDK?

Android 8.0 y versiones posteriores permiten actualizaciones de solo 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 construidos en diferentes momentos deben poder trabajar 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 los módulos del otro lado. Sin embargo, las dependencias de los módulos de los proveedores imponen restricciones no deseadas al desarrollo de los módulos del marco.
  • Extensiones a 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 de sistema genérica (GSI) estándar. Sin embargo, a medida que los proveedores amplían las bibliotecas AOSP para mejorar el rendimiento o para agregar funcionalidades adicionales para sus implementaciones de HIDL, actualizar la partición del sistema con un GSI estándar podría romper la implementación de HIDL de un proveedor. (Para obtener pautas sobre cómo prevenir tales roturas, consulte las extensiones de VNDK ).

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

Recursos de VNDK

Esta sección incluye los siguientes recursos de VNDK:

  • Los conceptos de VNDK (a continuación) describen bibliotecas compartidas de marco, HAL del mismo proceso (SP-HAL) y 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.
  • El soporte del sistema de compilación de VNDK describe las configuraciones del sistema de compilación y las sintaxis de definición de módulo que están relacionadas con VNDK.
  • La herramienta de definición de VNDK ayuda a migrar su árbol de origen a Android 8.0 y superior.
  • Linker Namespace proporciona un control detallado sobre los vínculos de bibliotecas compartidas.
  • Directorios, reglas y sepolicy definen la estructura de directorios para dispositivos que ejecutan Android 8.0 y superior, reglas VNDK y sepolicy asociadas.
  • La presentación de VNDK Design ilustra los conceptos fundamentales de VDNK utilizados en Android 8.0 y versiones posteriores.

Conceptos de VNDK

En un mundo ideal con Android 8.0 y versiones posteriores, los procesos del marco no cargan las bibliotecas compartidas del proveedor, todos los procesos del proveedor cargan solo las 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 de marcos no sean 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 de marcos sean accesibles para los procesos de los proveedores. Además, como los requisitos de rendimiento pueden generar compromisos, algunas HAL de tiempo de respuesta crítico 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 las bibliotecas compartidas que son accesibles a los procesos del proveedor. Hay dos enfoques para admitir módulos de proveedores en varias versiones de Android:

  1. Estabilizar las ABI / API de las bibliotecas compartidas del marco . Los módulos de marco nuevos 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 estables ABI / API es alto y no es realista estabilizar todas las ABI / API exportadas por cada biblioteca compartida de framework.
  2. 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 (pero no limitados a) carpetas, conectores, 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). Las bibliotecas compartidas de doble carga también pueden 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 en función de las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas de framework 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 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 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 del código no tiene objeciones a los usos de los proveedores.
  • Las Bibliotecas de Framework-Only (FWK-ONLY) son Bibliotecas Compartidas de Framework que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
    • Se consideran detalles de implementación interna del marco.
    • Los módulos del proveedor no deben acceder a él.
    • Tienen ABI / API inestables y no tienen garantías de compatibilidad API / ABI.
    • No se copian.

Mismo proceso HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) es un conjunto de HAL predeterminadas implementadas como bibliotecas compartidas de proveedores y cargadas en procesos de marco . Los SP-HAL están aislados por un espacio de nombres de enlazador (controla las bibliotecas y los símbolos que son visibles para las bibliotecas compartidas). Los SP-HAL deben depender solo 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 doble carga de las bibliotecas VNDK-SP en los procesos del marco no cause problemas. Google define tanto los SP-HAL como los VNDK-SP.

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 de solo marco con excepciones de RS (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (renderizado)

Terminología VNDK

  • Los módulos se refieren a bibliotecas compartidas o ejecutables .
  • Los procesos son tareas del sistema operativo generadas a partir de ejecutables .
  • Los términos calificados por el marco 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:

  • Framework Executables se refiere a ejecutables en /system/bin o /system/xbin .
  • Las bibliotecas compartidas de Framework se refieren a las bibliotecas compartidas en /system/lib[64] .
  • Los módulos de marco se refieren tanto a las bibliotecas compartidas de marco como a los ejecutables de marco .
  • Los procesos de Framework son procesos generados a partir de Framework Executables (por ejemplo, /system/bin/app_process ).
  • Vendor Executables se refiere a ejecutables en /vendor/bin
  • Las bibliotecas compartidas de proveedores se refieren a las bibliotecas compartidas en /vendor/lib[64] .
  • Los módulos de proveedores se refieren tanto a los ejecutables de proveedores como a las bibliotecas compartidas de proveedores .
  • Los procesos de proveedor son procesos generados a partir de ejecutables de proveedor (p. Ej.
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Control de versiones de VNDK

En Android 9, 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 de VNDK se instalan en /system/lib[64]/vndk-${ro.vndk.version} .
  • Las bibliotecas compartidas 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 algoritmo siguiente:

  • 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 , use PLATFORM_SDK_VERSION (por ejemplo, 28 ).
    • De lo contrario, use PLATFORM_VERSION_CODENAME (por ejemplo, P ).

Actualización de dispositivos

Si un dispositivo Android 8.x deshabilitó la aplicación de VNDK en tiempo de ejecución al ser construido 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 /system/etc/ld.config.vndk_lite.txt 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)

El conjunto de pruebas de proveedores de Android 9 (VTS) exige una propiedad ro.vndk.version no vacía. Tanto los dispositivos recién lanzados como los dispositivos de actualización 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 realiza un seguimiento de los cambios en la documentación de VNDK.

Cambios en Android 9

  • Agregue la sección de control de versiones de VNDK.
  • Agregue la sección VTS.
  • Algunas categorías de VNDK han cambiado de nombre:
    • LL-NDK-Indirect ha cambiado de nombre a LL-NDK-Private.
    • VNDK-Indirect ha cambiado de nombre a VNDK-Private.
    • VNDK-SP-Indirect-Private ha cambiado de nombre a VNDK-SP-Private.
    • Se ha eliminado VNDK-SP-Indirect.

Cambios en Android 8.1

  • Las bibliotecas SP-NDK se han fusionado 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.
  • Elimine libstdc++.so So de las bibliotecas LL-NDK. Utilice libc++.so lugar. Algunas versiones de cadenas de herramientas independientes pueden agregar -lstdc++ a los indicadores predeterminados del vinculador. Para deshabilitar los valores predeterminados, agregue -nodefaultlibs -lc -lm -ldl a LDFLAGS .
  • Mueva libz.so de LL-NDK a bibliotecas VNDK-SP. En algunas configuraciones, libz.so puede seguir siendo LL-NDK. Sin embargo, no debería haber diferencias observables.