Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Kit de desarrollo nativo del proveedor (VNDK)

Vendor Native Development Kit (VNDK) es un conjunto de bibliotecas exclusivamente para que los proveedores implementen sus HAL. Las naves VNDK en system.img y se vinculan dinámicamente a código de 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 de los proveedores 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 módulos de marco y de módulos de proveedores. 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 de los proveedores imponían restricciones no deseadas al desarrollo de los módulos del marco.
  • Las extensiones a las 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 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 HIDL, actualizar la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. (Para obtener instrucciones sobre la prevención de este tipo de roturas, ver extensiones VNDK ).

Para hacer frente a estos retos, Android 8.0 incorpora varias técnicas como VNDK (que se describe en esta sección), HIDL , hwbinder, superposición árbol de dispositivos , y la superposición sepolicy.

Recursos de VNDK

Esta sección incluye los siguientes recursos de VNDK:

  • Conceptos VNDK (abajo) describe bibliotecas marco compartido, Hals mismo proceso (SP-HAL), y la terminología VNDK.
  • VNDK extensiones clasifica específica del proveedor cambia 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 construcción de soporte del sistema se describen las configuraciones del sistema de acumulación y sintaxis de definición de módulos que están relacionados con VNDK.
  • La definición VNDK herramienta de ayuda a migrar su árbol de fuentes de Android 8.0 y superior.
  • Espacio de nombres enlazador proporciona un control preciso sobre los vínculos de bibliotecas compartidas.
  • Directorios, reglas y sepolicy define la estructura de directorios para los dispositivos con Android 8.0 y superiores, reglas VNDK y sepolicy asociado.
  • El VNDK Diseño presentación ilustra los conceptos fundamentales utilizados en VDNK Android 8.0 y superior.

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, dado que 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 los ABIs / API del marco de bibliotecas compartidas. 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. Copiar las bibliotecas compartidas marco de edad. 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, 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:

  • LL-NDK Las bibliotecas son Framework bibliotecas compartidas que son conocidos por ser estable. 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 ,
  • Bibliotecas VNDK elegibles (VNDK) son Framework bibliotecas compartidas que son seguros para ser copiado dos veces. Módulos marco y los módulos de proveedores pueden enlazar 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.
  • Marco de sólo bibliotecas (FWK-ONLY) son Framework bibliotecas compartidas 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 proveedores bibliotecas compartidas y cargados en los procesos del 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). SP-HAL deben depender sólo 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

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-privada y que son invisibles a SP-HALS.

Las siguientes son las bibliotecas marco de sólo con excepciones (RS FWK-only-RS):

  • libft2.so (renderScript)
  • libmediandk.so (renderScript)

Terminología VNDK

  • Los módulos se refieren a cualquiera de bibliotecas compartidas o ejecutables.
  • Procesos están operando tareas del sistema generados a partir ejecutables.
  • Marco Calificado términos se refieren a los conceptos relacionados con la partición del sistema.
  • Calificado términos de proveedores se refieren a los conceptos relacionados con las particiones de los proveedores.

Por ejemplo:

  • Marco Ejecutables se refiere a los ejecutables en /system/bin o /system/xbin .
  • Marco de bibliotecas compartidas se refieren a las bibliotecas compartidas bajo /system/lib[64] .
  • Módulos marco se refieren tanto a Marco bibliotecas compartidas y el Marco de ejecutables.
  • Procesos marco son procesos generados a partir de Marco ejecutables (por ejemplo, /system/bin/app_process ).
  • Ejecutables de proveedores se refieren a los ejecutables en /vendor/bin
  • Proveedores bibliotecas compartidas se refieren a las bibliotecas compartidas bajo /vendor/lib[64] .
  • Los módulos se refieren a los proveedores tanto de proveedores ejecutables y bibliotecas compartidas de los proveedores.
  • Procesos de proveedores son procesos generados del proveedor ejecutables (por ejemplo,
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Control de versiones de VNDK

En Android 9, las bibliotecas compartidas de VNDK tienen versiones:

  • El ro.vndk.version propiedad del sistema se añade automáticamente a /vendor/default.prop .
  • VNDK bibliotecas compartidas se instalan en /system/lib[64]/vndk-${ro.vndk.version} .
  • VNDK-SP bibliotecas compartidas se instalan en /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • El archivo de configuración enlazador dinámico está instalado a /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 current , el uso BOARD_VNDK_VERSION .
  • Si BOARD_VNDK_VERSION es igual a current :
    • Si PLATFORM_VERSION_CODENAME es REL , el uso PLATFORM_SDK_VERSION (por ejemplo 28 ).
    • De lo contrario, el uso PLATFORM_VERSION_CODENAME (por ejemplo, P ).

Actualización de dispositivos

Si un discapacitado VNDK la aplicación en tiempo de ejecución dispositivo 8.x Android por ser construido sin BOARD_VNDK_VERSION , puede añadir PRODUCT_USE_VNDK_OVERRIDE := false a BoardConfig.mk mientras que la actualización a Android 9.

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

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

Conjunto de pruebas de proveedores (VTS)

El androide 9 Vendor Test Suite (VTS) mandatos que un no vacío ro.vndk.version propiedad. Ambos dispositivos recién lanzado y la actualización de dispositivos deben definir ro.vndk.version . Algunos casos de prueba (por ejemplo VNDK VtsVndkFilesTest y VtsVndkDependencyTest ) se basan en el ro.vndk.version propiedad para cargar las bibliotecas que coinciden elegibles VNDK conjuntos de datos.

Si el ro.product.first_api_level propiedad es mayor que 27, el ro.vndk.lite propiedad no debe ser definido. VtsTreblePlatformVersionTest fallará si ro.vndk.lite se define en un dispositivo Android 9 lanzado recientemente.

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.
  • Reemplazar libui.so con libft2.so en RS sección de espacio de nombres. Fue un error para incluir libui.so .
  • Añadir libGLESv3.so y libandroid_net.so a las bibliotecas LL-NDK.
  • Añadir libion.so a las bibliotecas VNDK-SP.
  • Retire libstdc++.so de las bibliotecas LL-NDK. Utilice libc++.so lugar. Algunas versiones de cadenas de herramientas independientes pueden añadir -lstdc++ a las banderas de enlazador predeterminado. Para desactivar los valores por defecto, añadir -nodefaultlibs -lc -lm -ldl a LDFLAGS .
  • Mover libz.so de LL-NDK a las bibliotecas VNDK-SP. En algunas configuraciones, libz.so puede seguir siendo LL-NDK. Sin embargo, no debería haber diferencias observables.