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

Se usó la API de Cloud Translation para traducir esta página.

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

El kit de desarrollo nativo del proveedor (VNDK) es un conjunto de bibliotecas utilizadas por otras bibliotecas o archivos binarios, en la partición del proveedor o del producto, en tiempo de ejecución para dlopen.

¿Por qué VNDK?

AOSP permite actualizaciones solo del marco en las que la partición del sistema se puede actualizar a la última versión del marco mientras que la partición del proveedor permanece sin cambios. A pesar de que se construyeron en diferentes momentos, los archivos binarios en cada partición deben poder funcionar entre sí.

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 en la partición 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 marco.
Extensiones a las bibliotecas AOSP . Android requiere que todos los dispositivos Android pasen CTS cuando la partición del sistema se reemplaza con una imagen genérica del sistema (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, actualizar la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. Para obtener pautas sobre cómo prevenir dichas roturas, consulte Extensiones VNDK .

Para hacer frente a estos desafíos, Android contiene varias funciones, como VNDK (descrito en esta sección), HIDL , hwbinder, superposición de árbol de dispositivos y superposición de políticas.

Términos específicos de VNDK

Los documentos relacionados con VNDK utilizan la siguiente terminología:

Los módulos se refieren a bibliotecas compartidas o ejecutables. Los módulos crean dependencias en tiempo de compilación.
Los procesos son tareas del sistema operativo generadas a partir de ejecutables. Los procesos crean dependencias en tiempo de ejecución.
Marco : los términos calificados están relacionados con la partición system :

Los ejecutables del marco se refieren a los ejecutables en /system/bin o /system/xbin .
Las bibliotecas compartidas del marco se refieren a las bibliotecas compartidas en /system/lib[64] .
Los módulos del marco se refieren tanto a las bibliotecas compartidas del marco como a los ejecutables del marco.
Los procesos del marco son procesos generados a partir de ejecutables del marco, como /system/bin/app_process .

Los términos calificados por el proveedor están relacionados con las particiones vendor :

Los ejecutables del proveedor hacen referencia a los ejecutables en /vendor/bin
Las bibliotecas compartidas del proveedor 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 de proveedores son procesos generados a partir de ejecutables de proveedores, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceptos de VNDK

En un mundo ideal con Android 8.0 y superior, los procesos del marco 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 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 y estables de las bibliotecas compartidas del marco 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 del marco sea accesible para los procesos del proveedor. Además, dado que los requisitos de rendimiento pueden generar compromisos, algunas HAL críticas para el tiempo de respuesta deben tratarse de manera diferente.

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

Bibliotecas compartidas del marco para el proveedor

Esta sección describe 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:

Estabilice las ABI/API de las bibliotecas compartidas del 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 carga doble. 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.
Copie las bibliotecas compartidas del marco antiguo . Viene con la 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) el enlazador, el zócalo, la canalización, 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é congelado y estable (por ejemplo, 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 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 dependiendo de las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas del marco 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 Framework que se pueden copiar dos veces con seguridad. 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 con 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 licencia de software especial que requiera revisiones legales.
- El propietario de su código no tiene objeciones a los usos de los proveedores.
Las bibliotecas solo de marco (FWK-ONLY) son bibliotecas compartidas de marco que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
- Se consideran detalles de implementación interna del framework.
- No debe ser accedido por módulos de proveedores.
- Tener ABI/API inestables y sin garantías de compatibilidad API/ABI.
- No se copian.

Mismo proceso HAL (SP-HAL)

HAL del mismo proceso ( SP-HAL ) es un conjunto de HAL predeterminadas implementadas como bibliotecas compartidas de proveedores y cargadas en Framework Processes . Los SP-HAL están aislados por un espacio de nombres de vinculador (controla las bibliotecas y los símbolos que son visibles para las bibliotecas compartidas). Las 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 carga doble de bibliotecas VNDK-SP en los procesos del marco no cause problemas. Tanto SP-HAL como VNDK-SP están definidos por Google.

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 vndk: {private:true} , estas bibliotecas se denominan VNDK-SP-Private y son invisibles para SP-HALS.

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

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

Versionado de VNDK

Las bibliotecas compartidas de VNDK están versionadas:

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

El valor de ro.vndk.version se elige mediante el siguiente algoritmo:

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

Conjunto de pruebas de proveedores (VTS)

Android Vendor Test Suite (VTS) exige una propiedad ro.vndk.version no vacía. Tanto los dispositivos recién lanzados como los dispositivos actualizados 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.

¿Por qué VNDK?

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 en la partición 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 marco.
Extensiones a las bibliotecas AOSP . Android requiere que todos los dispositivos Android pasen CTS cuando la partición del sistema se reemplaza con una imagen genérica del sistema (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, actualizar la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. Para obtener pautas sobre cómo prevenir dichas roturas, consulte Extensiones VNDK .

Términos específicos de VNDK

Los documentos relacionados con VNDK utilizan la siguiente terminología:

Los módulos se refieren a bibliotecas compartidas o ejecutables. Los módulos crean dependencias en tiempo de compilación.
Los procesos son tareas del sistema operativo generadas a partir de ejecutables. Los procesos crean dependencias en tiempo de ejecución.
Marco : los términos calificados están relacionados con la partición system :

Los ejecutables del marco se refieren a los ejecutables en /system/bin o /system/xbin .
Las bibliotecas compartidas del marco se refieren a las bibliotecas compartidas en /system/lib[64] .
Los módulos del marco se refieren tanto a las bibliotecas compartidas del marco como a los ejecutables del marco.
Los procesos del marco son procesos generados a partir de ejecutables del marco, como /system/bin/app_process .

Los términos calificados por el proveedor están relacionados con las particiones vendor :

Los ejecutables del proveedor hacen referencia a los ejecutables en /vendor/bin
Las bibliotecas compartidas del proveedor 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 de proveedores son procesos generados a partir de ejecutables de proveedores, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceptos de VNDK

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

Bibliotecas compartidas del marco para el proveedor

Estabilice las ABI/API de las bibliotecas compartidas del 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 carga doble. 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.
Copie las bibliotecas compartidas del marco antiguo . Viene con la 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) el enlazador, el zócalo, la canalización, 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é congelado y estable (por ejemplo, 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 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 dependiendo de las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas del marco 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 Framework que se pueden copiar dos veces con seguridad. 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 con 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 licencia de software especial que requiera revisiones legales.
- El propietario de su código no tiene objeciones a los usos de los proveedores.
Las bibliotecas solo de marco (FWK-ONLY) son bibliotecas compartidas de marco que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
- Se consideran detalles de implementación interna del framework.
- No debe ser accedido por módulos de proveedores.
- Tener ABI/API inestables y sin garantías de compatibilidad API/ABI.
- No se copian.

Mismo proceso HAL (SP-HAL)

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

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

Versionado de VNDK

Las bibliotecas compartidas de VNDK están versionadas:

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

El valor de ro.vndk.version se elige mediante el siguiente algoritmo:

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, utilice PLATFORM_VERSION_CODENAME (por ejemplo, P ).

Conjunto de pruebas de proveedores (VTS)

¿Por qué VNDK?

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 en la partición 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 marco.
Extensiones a las bibliotecas AOSP . Android requiere que todos los dispositivos Android pasen CTS cuando la partición del sistema se reemplaza con una imagen genérica del sistema (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, actualizar la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. Para obtener pautas sobre cómo prevenir dichas roturas, consulte Extensiones VNDK .

Términos específicos de VNDK

Los documentos relacionados con VNDK utilizan la siguiente terminología:

Los módulos se refieren a bibliotecas compartidas o ejecutables. Los módulos crean dependencias en tiempo de compilación.
Los procesos son tareas del sistema operativo generadas a partir de ejecutables. Los procesos crean dependencias en tiempo de ejecución.
Marco : los términos calificados están relacionados con la partición system :

Los ejecutables del marco se refieren a los ejecutables en /system/bin o /system/xbin .
Las bibliotecas compartidas del marco se refieren a las bibliotecas compartidas en /system/lib[64] .
Los módulos del marco se refieren tanto a las bibliotecas compartidas del marco como a los ejecutables del marco.
Los procesos del marco son procesos generados a partir de ejecutables del marco, como /system/bin/app_process .

Los términos calificados por el proveedor están relacionados con las particiones vendor :

Los ejecutables del proveedor hacen referencia a los ejecutables en /vendor/bin
Las bibliotecas compartidas del proveedor 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 de proveedores son procesos generados a partir de ejecutables de proveedores, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceptos de VNDK

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

Bibliotecas compartidas del marco para el proveedor

Estabilice las ABI/API de las bibliotecas compartidas del 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 carga doble. 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.
Copie las bibliotecas compartidas del marco antiguo . Viene con la 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) el enlazador, el zócalo, la canalización, 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é congelado y estable (por ejemplo, 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 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 dependiendo de las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas del marco 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 Framework que se pueden copiar dos veces con seguridad. 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 con 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 licencia de software especial que requiera revisiones legales.
- El propietario de su código no tiene objeciones a los usos de los proveedores.
Las bibliotecas solo de marco (FWK-ONLY) son bibliotecas compartidas de marco que no pertenecen a las categorías mencionadas anteriormente. Estas bibliotecas:
- Se consideran detalles de implementación interna del framework.
- No debe ser accedido por módulos de proveedores.
- Tener ABI/API inestables y sin garantías de compatibilidad API/ABI.
- No se copian.

Mismo proceso HAL (SP-HAL)

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

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

Versionado de VNDK

Las bibliotecas compartidas de VNDK están versionadas:

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

El valor de ro.vndk.version se elige mediante el siguiente algoritmo:

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, utilice PLATFORM_VERSION_CODENAME (por ejemplo, P ).

Conjunto de pruebas de proveedores (VTS)

¿Por qué VNDK?

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 en la partición 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 marco.
Extensiones a las bibliotecas AOSP . Android requiere que todos los dispositivos Android pasen CTS cuando la partición del sistema se reemplaza con una imagen genérica del sistema (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, actualizar la partición del sistema con un GSI estándar podría romper la implementación HIDL de un proveedor. Para obtener pautas sobre cómo prevenir dichas roturas, consulte Extensiones VNDK .

Términos específicos de VNDK

Los documentos relacionados con VNDK utilizan la siguiente terminología:

Los módulos se refieren a bibliotecas compartidas o ejecutables. Los módulos crean dependencias en tiempo de compilación.
Los procesos son tareas del sistema operativo generadas a partir de ejecutables. Los procesos crean dependencias en tiempo de ejecución.
Marco : los términos calificados están relacionados con la partición system :

Los ejecutables del marco se refieren a los ejecutables en /system/bin o /system/xbin .
Las bibliotecas compartidas del marco se refieren a las bibliotecas compartidas en /system/lib[64] .
Los módulos del marco se refieren tanto a las bibliotecas compartidas del marco como a los ejecutables del marco.
Los procesos del marco son procesos generados a partir de ejecutables del marco, como /system/bin/app_process .

Los términos calificados por el proveedor están relacionados con las particiones vendor :

Los ejecutables del proveedor hacen referencia a los ejecutables en /vendor/bin
Las bibliotecas compartidas del proveedor 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 de proveedores son procesos generados a partir de ejecutables de proveedores, como /vendor/bin/android.hardware.camera.provider@2.4-service .

Conceptos de VNDK

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

Bibliotecas compartidas del marco para el proveedor

Estabilice las ABI/API de las bibliotecas compartidas del 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 carga doble. 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.
Copie las bibliotecas compartidas del marco antiguo . Viene con la 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) el enlazador, el zócalo, la canalización, 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é congelado y estable (por ejemplo, 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 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 dependiendo de las características de las bibliotecas compartidas. Como resultado, las bibliotecas compartidas del marco 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 Framework que se pueden copiar dos veces con seguridad. Los módulos de marco y los módulos de proveedores pueden vincularse con sus propias copias. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
- It does not send/receive IPCs to/from the framework.
- It is not related to ART virtual machine.
- It does not read/write files/partitions with unstable file formats.
- It does not have special software license which requires legal reviews.
- Its code owner does not have objections to vendor usages.
Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
- Are considered framework internal implementation details.
- Must not be accessed by vendor modules.
- Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
- Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes . SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP .

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved SP-HALs:

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

VNDK-SP libraries specify vndk: { support_system_process: true } in their Android.bp files. If vndk: {private:true} is also specified, then these libraries are called VNDK-SP-Private and they are invisible to SP-HALS.

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS) :

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

VNDK versioning

VNDK shared libraries are versioned:

The ro.vndk.version system property is automatically added to /vendor/default.prop .
VNDK and VNDK-SP shared libraries are installed as a VNDK apex com.android.vndk.v${ro.vndk.version} and mounted to /apex/com.android.vndk.v${ro.vndk.version} .

The value of ro.vndk.version is chosen by the algorithm below:

If BOARD_VNDK_VERSION is not equal to current , use BOARD_VNDK_VERSION .
If BOARD_VNDK_VERSION is equal to current :

If PLATFORM_VERSION_CODENAME is REL , use PLATFORM_SDK_VERSION (eg 28 ).
Otherwise, use PLATFORM_VERSION_CODENAME (eg P ).

Vendor Test Suite (VTS)

The Android Vendor Test Suite (VTS) mandates a non-empty ro.vndk.version property. Both newly-launched devices and upgrading devices must define ro.vndk.version . Some VNDK test cases (eg VtsVndkFilesTest and VtsVndkDependencyTest ) rely on the ro.vndk.version property to load the matching eligible VNDK libraries data sets.