Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

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

¿Por qué VNDK?

Android 8.0 y superior habilita actualizaciones solo de marco en las que la partición del sistema se puede actualizar a la última versión mientras 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 de solo marco incluyen los siguientes desafíos:

  • Dependencia entre módulos de marco y módulos de 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 para el desarrollo de módulos marco.
  • Extensiones a bibliotecas AOSP . Android 8.0 y superior requiere que todos los dispositivos Android pasen CTS cuando la partición del sistema se reemplaza con una Imagen del sistema genérico (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, flashear la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. (Para obtener instrucciones 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 (descrito en esta sección), HIDL , hwbinder, superposición de árbol de dispositivos y superposición sepolicy.

Recursos 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.
  • VNDK Build System Support 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 enlaces de bibliotecas compartidas.
  • Directorios, Reglas y sepolicy define la estructura de directorios para dispositivos que ejecutan Android 8.0 y superior, reglas VNDK y sepolicy asociada.
  • La presentación de diseño VNDK ilustra conceptos fundamentales de VDNK utilizados en Android 8.0 y versiones posteriores.

Conceptos de VNDK

En un mundo ideal de Android 8.0 y superior, los procesos de 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.

Tal mundo incluye la posibilidad de que las API públicas estables de las bibliotecas compartidas de framework 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 de framework 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 ser tratados de manera diferente.

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

Framework de bibliotecas compartidas para proveedores

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

  1. Estabilice las ABI / API de las bibliotecas compartidas 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 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 de framework.
  2. Copie las bibliotecas compartidas antiguas del marco . Viene con la fuerte restricción contra los canales laterales, definida como todos los mecanismos para comunicarse entre los módulos del marco y los módulos del proveedor, incluyendo (pero no limitado a) carpeta, socket, tubería, memoria compartida, archivo compartido 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 doble carga 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 producirse 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 de framework se clasifican en tres subcategorías:

  • Las bibliotecas LL-NDK son bibliotecas compartidas de marco que se sabe que son estables. Sus desarrolladores se comprometen 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 de VNDK elegibles (VNDK) son bibliotecas compartidas de Framework que se pueden copiar dos veces de forma segura. Los módulos de marco y los módulos de proveedor 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 a / 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 requiere revisiones legales.
    • El propietario de su código no tiene objeciones a los usos del proveedor.
  • Las bibliotecas solo de marco (SOLO FWK) 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.
    • Los módulos del proveedor no deben acceder a él.
    • Tener ABI / API inestables y no hay 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 por el proveedor 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 de VNDK-SP se revisan cuidadosamente para garantizar que las bibliotecas de VNDK-SP de doble carga en los procesos del marco no causen problemas. Google define los SP-HAL y 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 vendor_available: false también se especifica, entonces estas bibliotecas se denominan VNDK-SP-Private y son invisibles para SP-HALS .

Las siguientes son bibliotecas de solo 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 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:

  • Los ejecutables de Framework se refieren a los ejecutables en /system/bin o /system/xbin .
  • Las bibliotecas compartidas de Framework se refieren a 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 marco son procesos generados a partir de ejecutables de marco (por ejemplo, /system/bin/app_process ).
  • 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 proveedores se refieren tanto a los archivos ejecutables del proveedor como a las bibliotecas compartidas del proveedor .
  • Los procesos de proveedores son procesos generados a partir de ejecutables de proveedores (p. Ej.
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

VNDK versionado

En Android 9, las bibliotecas compartidas 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 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 es elegido por el algoritmo a continuación:

  • Si BOARD_VNDK_VERSION no es igual a la 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 ejecución de VNDK en tiempo de ejecución al BOARD_VNDK_VERSION 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 .

Vendor Test Suite (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 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 correspondientes.

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

Historia del documento

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

Android 9 cambios

  • Agregar sección de versiones de VNDK.
  • Añadir 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 su nombre a VNDK-SP-Private.
    • VNDK-SP-Indirect ha sido eliminado.

Android 8.1 cambios

  • 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. Use libc++.so lugar. Algunas versiones de cadenas de herramientas independientes pueden agregar -lstdc++ a las banderas de enlace predeterminadas. Para deshabilitar los valores predeterminados, agregue -nodefaultlibs -lc -lm -ldl a LDFLAGS .
  • Mueva libz.so de las libz.so LL-NDK a VNDK-SP. En algunas configuraciones, libz.so puede seguir siendo LL-NDK. Sin embargo, no debe haber diferencias observables.