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

El Vendor Native Development Kit (VNDK) es un conjunto de bibliotecas que otras bibliotecas o archivos binarios usan en la partición del proveedor o del producto en el tiempo de ejecución para dlopen.

Baja

El NDK del proveedor se introdujo en Android 8.0 para proporcionar APIs entre el framework y el código del proveedor. Si bien el VNDK se ha usado con éxito durante muchos años, tiene algunos inconvenientes:
  • Almacenamiento
    • Un solo paquete APEX del VNDK incluye todas las bibliotecas del VNDK, ya sea que se usen desde el dispositivo o no.
    • La GSI contiene varias versiones de APEX de VNDK para admitir varias versiones de imágenes del proveedor.
  • Capacidad de actualización
    • Es difícil actualizar los APEX de VNDK por separado de la actualización de la plataforma.
    • Las imágenes del proveedor se actualizan con frecuencia de forma inalámbrica (OTA), lo que reduce los beneficios de tener el VNDK empaquetado dentro de la imagen del sistema.
Debido a estos problemas, decidimos desaprobar VNDK a partir de Android 15.

Detalles sobre la baja del VNDK

Todas las bibliotecas del VNDK se empaquetan en el APEX del VNDK y se instalan en la imagen del sistema (-ext). Con la baja del VNDK, las bibliotecas anteriores del VNDK se instalan en la imagen del proveedor (o del producto), al igual que otras bibliotecas disponibles para el proveedor. Estas funciones se quitan junto con la baja de VNDK:
  • APEX del VNDK para Android 15
  • Se quitan las propiedades del sistema que indican la versión del VNDK de destino si las particiones del proveedor o del producto se compilan para Android 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • Las optimizaciones de VNDK no estarán disponibles porque no hay VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT para dispositivos Android Go
    • use_vndk_as_stable para APEX de proveedores
  • Es una instantánea del proveedor que depende en gran medida del VNDK.

Excepciones a la baja

Estas funciones no cambiarán con la obsolescencia del VNDK:
  • APEX de VNDK con la versión 14 o anterior de VNDK, que se requieren para admitir imágenes de proveedores existentes.
  • El LL-NDK no forma parte del VNDK.

¿Por qué VNDK?

El AOSP permite actualizaciones solo del framework, en las que la partición del sistema se puede actualizar a la versión más reciente del framework, mientras que la partición del proveedor permanece sin cambios. A pesar de que se compilan en diferentes momentos, los archivos binarios de cada partición deben poder trabajar entre sí.

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

  • Dependencia entre los módulos del framework y los módulos del proveedor Antes de Android 8.0, los módulos de las particiones del proveedor y del sistema podían vincularse entre sí. Sin embargo, las dependencias de los módulos del proveedor impusieron restricciones no deseadas al desarrollo de los módulos del framework.
  • Extensiones para las bibliotecas del AOSP. Android requiere que todos los dispositivos Android pasen el CTS cuando la partición del sistema se reemplaza por una imagen genérica del sistema (GSI) estándar. Sin embargo, a medida que los proveedores extienden las bibliotecas del AOSP para mejorar el rendimiento o agregar funcionalidades adicionales a sus implementaciones de HIDL, es posible que la escritura de la partición del sistema con una GSI estándar interrumpa la implementación de HIDL de un proveedor. Para obtener instrucciones sobre cómo evitar este tipo de interrupciones, consulta Extensiones del VNDK.

Para abordar estos desafíos, Android incluye varias funciones, como el VNDK (que se describe en esta sección), el HIDL, hwbinder, la superposición del árbol de dispositivos y la superposición de sepolicy.

Condiciones específicas del VNDK

En los documentos relacionados con el VNDK, se usa la siguiente terminología:
  • Los módulos hacen referencia a bibliotecas compartidas o ejecutables. Los módulos crean dependencias en el tiempo de compilación.
  • Los procesos son tareas del sistema operativo que se generan a partir de archivos ejecutables. Los procesos crean dependencias de tiempo de ejecución.
  • Los términos aptos para el marco de trabajo se relacionan con la partición system:
    • Los ejecutables del framework hacen referencia a los ejecutables en /system/bin o /system/xbin.
    • Las bibliotecas compartidas del framework hacen referencia a las bibliotecas compartidas en /system/lib[64].
    • Los módulos de framework hacen referencia tanto a las bibliotecas compartidas del framework como a los ejecutables del framework.
    • Los procesos del framework son procesos derivados de ejecutables del framework, como /system/bin/app_process.
  • Los términos calificados por el proveedor se relacionan con las particiones de vendor:
    • 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 del proveedor son procesos derivados de ejecutables del proveedor, como /vendor/bin/android.hardware.camera.provider@2.4-service.

Conceptos del VNDK

En un mundo ideal con Android 8.0 y versiones posteriores, los procesos del framework 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 framework), y las comunicaciones entre los procesos del framework y los procesos del proveedor se rigen por HIDL y el binder de hardware.

En un mundo así, existe la posibilidad de que las APIs públicas y estables de las bibliotecas compartidas del framework no sean suficientes para los desarrolladores de módulos del proveedor (aunque las APIs pueden cambiar entre las versiones de Android), lo que requiere que los procesos del proveedor puedan acceder a una parte de las bibliotecas compartidas del framework. Además, como los requisitos de rendimiento pueden generar concesiones, algunos HAL que son críticos para el tiempo de respuesta deben tratarse de manera diferente.

En las siguientes secciones, se detalla cómo el VNDK controla las bibliotecas compartidas del framework para los proveedores y las HAL del mismo proceso (SP-HAL).

Bibliotecas compartidas del framework para el proveedor

En esta sección, se describen los criterios para clasificar las bibliotecas compartidas a las que pueden acceder los procesos del proveedor. Existen dos enfoques para admitir módulos del proveedor en varias versiones de Android:

  1. Estabiliza las ABIs/APIs de las bibliotecas compartidas del framework. Los módulos nuevos del framework y los módulos antiguos del proveedor pueden usar la misma biblioteca compartida para reducir el espacio 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 las ABIs/APIs estables es alto, y no es realista estabilizar todas las ABIs/APIs que exporta cada biblioteca compartida del framework.
  2. Copy old framework shared libraries: Incluye una restricción estricta contra los canales laterales, definidos como todos los mecanismos para comunicarse entre los módulos del framework y los módulos del proveedor, incluidos (sin limitaciones) Binder, 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 sea estable (p.ej., 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 biblioteca nueva 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 usan diferentes enfoques según las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas del framework se clasifican en tres subcategorías:

  • Las bibliotecas LL-NDK son bibliotecas compartidas del framework que se sabe que son estables. Sus desarrolladores se comprometen a mantener la estabilidad de la API/ABI.
    • El 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 aptas para el VNDK son bibliotecas compartidas del framework que se pueden copiar dos veces sin problemas. Los módulos de framework y los módulos de proveedores pueden vincularse con sus propias copias. Una biblioteca compartida de framework puede convertirse en una biblioteca del VNDK apta solo si satisface los siguientes criterios:
    • No envía ni recibe IPCs hacia o desde el framework.
    • No está relacionado con la máquina virtual de ART.
    • No lee ni escribe archivos o 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 al uso por parte de proveedores.
  • Las bibliotecas solo de framework (FWK-ONLY) son bibliotecas compartidas de framework que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
    • Se consideran detalles internos de la implementación del framework.
    • Los módulos del proveedor no deben acceder a ella.
    • Tienen APIs o ABIs inestables y no ofrecen garantías de compatibilidad de APIs o ABIs.
    • No se copian.

HAL de mismo proceso (SP-HAL)

El HAL de mismo proceso (SP-HAL) es un conjunto de HAL predeterminados implementados como bibliotecas compartidas del proveedor y cargados en procesos del framework. Los SP-HAL están aislados por un espacio de nombres del vinculador (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 del VNDK aptas. Las bibliotecas del VNDK-SP se revisan cuidadosamente para garantizar que la carga doble de bibliotecas del VNDK-SP en procesos del framework 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 de VNDK-SP especifican vndk: { support_system_process: true } en sus archivos Android.bp. Si también se especifica vndk: {private:true}, estas bibliotecas se llaman VNDK-SP-Private y son invisibles para los SP-HAL.

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

  • libft2.so (RenderScript)
  • libmediandk.so (RenderScript)

Control de versiones del VNDK

Las bibliotecas compartidas del VNDK tienen versiones:

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

El algoritmo que se muestra a continuación elige el valor de ro.vndk.version:

  • Si BOARD_VNDK_VERSION no es igual a current, usa BOARD_VNDK_VERSION.
  • Si BOARD_VNDK_VERSION es igual a current:
    • Si PLATFORM_VERSION_CODENAME es REL, usa PLATFORM_SDK_VERSION (p.ej., 28).
    • De lo contrario, usa PLATFORM_VERSION_CODENAME (p.ej., P).

Conjunto de pruebas de proveedores (VTS)

El Conjunto de pruebas de proveedores de Android (VTS) exige una propiedad ro.vndk.version no vacía. Tanto los dispositivos recién lanzados como los que se actualizan deben definir ro.vndk.version. Algunos casos de prueba del VNDK (p.ej., VtsVndkFilesTest y VtsVndkDependencyTest) dependen de la propiedad ro.vndk.version para cargar los conjuntos de datos de las bibliotecas del VNDK aptas correspondientes.