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

El kit de desarrollo nativo del proveedor (VNDK) es un conjunto de bibliotecas que usan otras bibliotecas o objetos binarios, en la partición del proveedor o del producto, en el entorno 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 VNDK se usa correctamente durante muchos años, presenta algunas desventajas:
  • Almacenamiento
    • Un solo APEX de VNDK empaqueta todas las bibliotecas de VNDK, ya sea que se usen desde el dispositivo o no.
    • El 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 en la imagen del sistema.
En función de estos problemas, decidimos dar de baja VNDK a partir de Android 15.

Detalles sobre la baja del VNDK

Todas las bibliotecas de VNDK se empaquetan en el APEX de VNDK y se instalan en la imagen (-ext) del sistema. Con la baja del VNDK, las bibliotecas anteriores del VNDK se instalan en la imagen del proveedor (o producto), al igual que otras bibliotecas disponibles del proveedor. Estas funciones se quitan junto con la baja del VNDK:
  • VNDK APEX para Android 15
  • Las propiedades del sistema que indican la versión del VNDK de destino se quitan 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 un VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT para dispositivos Android Go
    • use_vndk_as_stable para APEX de proveedores
  • Resumen del proveedor, que depende en gran medida del VNDK

Excepciones a la baja

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

¿Por qué elegir VNDK?

AOSP permite actualizaciones solo de 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 no se modifica. A pesar de compilarse en momentos diferentes, los objetos binarios de cada partición deben poder funcionar entre sí.

Las actualizaciones solo de 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 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 los módulos del framework.
  • Extensiones para bibliotecas del AOSP. Android requiere que todos los dispositivos Android pasen el CTS cuando se reemplaza la partición del sistema por una imagen genérica del sistema (GSI) estándar. Sin embargo, a medida que los proveedores extienden las bibliotecas de AOSP para mejorar el rendimiento o agregar funcionalidades adicionales para sus implementaciones de HIDL, el restablecimiento de la partición del sistema con un GSI estándar podría dañar la implementación de HIDL de un proveedor. Para obtener lineamientos sobre cómo evitar este tipo de fallas, consulta Extensiones de VNDK.

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

Condiciones específicas del VNDK

En los documentos relacionados con el VNDK, se usa la siguiente terminología:
  • Los módulos se refieren a bibliotecas compartidas o ejecutables. Los módulos generan 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 calificados para framework están relacionados con la partición system:
    • Los ejecutables del framework se refieren a los ejecutables en /system/bin o /system/xbin.
    • Las bibliotecas compartidas de framework hacen referencia a las bibliotecas compartidas en /system/lib[64].
    • Los módulos de framework se refieren a las bibliotecas compartidas y a los ejecutables del framework.
    • Los procesos del framework son procesos generados a partir de ejecutables del framework, como /system/bin/app_process.
  • Los términos calificados por el Proveedor se relacionan 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 proveedores se refieren a los ejecutables y las bibliotecas compartidas de los proveedores.
    • Los procesos del proveedor son procesos generados a partir de ejecutables del proveedor, como /vendor/bin/android.hardware.camera.provider@2.4-service.

Conceptos de VNDK

En un mundo ideal de Android 8.0 y versiones posteriores, los procesos del framework no cargan bibliotecas compartidas del proveedor, todos los procesos del proveedor solo cargan 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 están regidas por HIDL y el vinculador de hardware.

En este mundo, se incluye la posibilidad de que las APIs públicas estables de las bibliotecas compartidas del framework no sean suficientes para los desarrolladores de módulos de proveedores (aunque las APIs pueden cambiar entre versiones de Android), lo que requiere que los procesos de los proveedores puedan acceder a una parte de las bibliotecas compartidas del framework. Además, como los requisitos de rendimiento pueden generar vulnerabilidades, algunos HAL críticos en 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 los HAL de mismo proceso (SP-HAL).

Armar bibliotecas compartidas 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 de proveedores en varias versiones de Android:

  1. Estabiliza las ABI o APIs de las bibliotecas compartidas del framework. Los módulos de framework nuevos y los módulos de proveedores anteriores pueden usar la misma biblioteca compartida para reducir el espacio en 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 ABIs o APIs estables es alto y no es realista estabilizar todas las ABIs o APIs que exporta cada biblioteca compartida del framework.
  2. Copia las bibliotecas compartidas del framework anterior. 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, entre otros, el Binder, el socket, el canal, la memoria compartida, el archivo compartido y las propiedades del sistema. No debe haber comunicación, a menos que el protocolo de comunicación esté inmovilizado y estable (p.ej., HIDL a través de hwbinder). La carga doble de bibliotecas compartidas también puede causar problemas. Por ejemplo, si se pasa un objeto creado por la biblioteca nueva a las funciones de la biblioteca anterior, es posible que se produzca 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 de framework que se sabe que son estables. Sus desarrolladores están comprometidos a mantener la estabilidad de sus APIs y 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 aptas (VNDK) son bibliotecas compartidas del framework que se pueden copiar dos veces de forma segura. Los módulos de framework y los módulos de proveedores pueden vincularse con sus propias copias. Una biblioteca compartida del framework puede convertirse en una biblioteca de VNDK apta solo si cumple con los siguientes criterios:
    • No envía ni recibe IPC hacia/desde el framework.
    • No está relacionado con la máquina virtual de ART.
    • No lee ni escribe archivos ni particiones con formatos de archivo inestables.
    • No posee una licencia de software especial que requiera revisiones legales.
    • El propietario del código no tiene objeciones con respecto al uso por parte de los proveedores.
  • Las bibliotecas solo de framework (FWK-ONLY) son bibliotecas compartidas del framework que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
    • Se consideran detalles de implementación internos del framework.
    • Los módulos de proveedores no deben acceder a ella.
    • Tienen ABI o APIs inestables y no tienen garantías de compatibilidad con las APIs o ABI.
    • No se copian.

HAL de mismo proceso (SP-HAL)

El HAL del mismo proceso (SP-HAL) es un conjunto de HAL predeterminados que se implementan como bibliotecas compartidas del proveedor y se cargan en los procesos del framework. Los SP-HAL se aíslan con un espacio de nombres de vinculador (controla las bibliotecas y los símbolos que son visibles para las bibliotecas compartidas). Los SP-HAL solo deben depender de LL-NDK y VNDK-SP.

VNDK-SP es un subconjunto predefinido de bibliotecas de VNDK aptas. Las bibliotecas de VNDK-SP se revisan cuidadosamente para garantizar que la carga doble de bibliotecas de VNDK-SP en los procesos del framework no cause problemas. Google define las SP-HAL y las 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 denominan VNDK-SP-Private y son invisibles para los SP-HAL.

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

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

Control de versiones de VNDK

Las bibliotecas compartidas de VNDK tienen control de versiones:

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

El siguiente algoritmo 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 nuevos como los que se actualizan deben definir ro.vndk.version. Algunos casos de prueba de VNDK (p.ej., VtsVndkFilesTest y VtsVndkDependencyTest) dependen de la propiedad ro.vndk.version para cargar los conjuntos de datos de bibliotecas de VNDK aptos que coincidan.