El kit de desarrollo nativo del proveedor (VNDK) es un conjunto de bibliotecas que utilizan otras bibliotecas. o en objetos binarios, en la partición de producto o proveedor, en el entorno de ejecución para dlopen.
¿Por qué elegir VNDK?
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 no se modifica. A pesar de que se crearon en diferentes los objetos binarios de cada partición deben poder funcionar en conjunto.
Las actualizaciones solo del framework incluyen los siguientes desafíos:
- Dependencia entre los módulos del framework y los módulos de proveedores. En versiones anteriores a Android 8.0, los módulos en la partición del sistema y el proveedor podían vincularse entre sí. Sin embargo, las dependencias de los módulos de proveedores imponían restricciones al desarrollo de los módulos del framework.
- Extensiones para bibliotecas del AOSP. En Android requiere que todos los dispositivos Android pasen el CTS cuando se reemplaza la partición del sistema con una imagen genérica del sistema (GSI) estándar. Sin embargo, a medida que los proveedores extienden el AOSP para mejorar el rendimiento o agregar funcionalidades adicionales a su HIDL implementaciones, escribir en la memoria flash la partición del sistema con una GSI estándar puede dañar la implementación de HIDL de un proveedor. Para conocer los lineamientos evitar dichas fallas, consulta Extensiones del VNDK.
Para abordar estos desafíos, Android incluye varias funciones, como como VNDK (descrito en esta sección), HIDL, hwbinder, la superposición del árbol de dispositivos superposición de sepolicy.
Términos específicos 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 hacen que el tiempo de compilación dependencias.
- Los procesos son tareas del sistema operativo que se generan a partir de archivos ejecutables. Los procesos convierten en tiempo de ejecución dependencias.
- Los términos calificados para framework están relacionados con la partición
system
: - Los ejecutivos del framework hacen referencia a los ejecutables en
/system/bin
o/system/xbin
- Las bibliotecas compartidas de framework se refieren a las bibliotecas compartidas
/system/lib[64]
- Los módulos del framework hacen referencia a ambas bibliotecas compartidas del framework y ejecutables de framework.
- Los procesos del framework son procesos generados a partir del framework
ejecutables, como
/system/bin/app_process
. - Los términos calificados por proveedor se relacionan con
vendor
particiones: - Los ejecutables del proveedor hacen referencia a los ejecutables en
/vendor/bin
- Las bibliotecas compartidas de proveedores hacen referencia a las bibliotecas compartidas
/vendor/lib[64]
- Los módulos de proveedores hacen referencia a los ejecutables y las bibliotecas compartidas del proveedor.
- Los procesos del proveedor son procesos generados por el proveedor.
Ejecutables, como
/vendor/bin/android.hardware.camera.provider@2.4-service
.
Conceptos de VNDK
En un entorno ideal con Android 8.0 y versiones posteriores, los procesos del framework no se 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 framework) y las comunicaciones entre los procesos del framework y los procesos de los proveedores se rigen por el HIDL y el hardware Binder.
Este mundo incluye la posibilidad de que las APIs públicas estables de es posible que 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), por lo que se requiere que de las bibliotecas compartidas del framework sean accesibles para los procesos de los proveedores. Además, como los requisitos de rendimiento pueden generar concretos, algunas tareas esenciales Las HAL deben tratarse de manera diferente.
En las siguientes secciones, se detalla la forma en que VNDK maneja las bibliotecas compartidas del framework para proveedores ni HALs de mismo proceso (SP-HAL).
Armar bibliotecas compartidas para el proveedor
En esta sección, se describen los criterios para clasificar las bibliotecas compartidas que son accesibles para los procesos del proveedor. Hay dos enfoques para apoyar al proveedor módulos en varias versiones de Android:
- Estabiliza las ABI y las APIs de las bibliotecas compartidas del framework. Los módulos nuevos del framework y los módulos de proveedores antiguos pueden usar la misma biblioteca compartida para 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 los niveles estables Las ABI y las APIs son muchas y no es realista estabilizar todas las ABI y APIs exportadas por para cada biblioteca compartida de framework.
- Copia las bibliotecas compartidas del framework anterior. Incluye lo fuerte Restricción para canales laterales, que se definen como todos los mecanismos para comunicarse entre los módulos del marco y los módulos de los proveedores, incluidos, sin limitaciones, Binder, socket, canalización, memoria compartida, archivo compartido y propiedades del sistema. Hay No debe haber comunicación, a menos que el protocolo de comunicación esté congelado y estable. (p.ej., HIDL a través de hwbinder). La carga doble de bibliotecas compartidas puede provocar problemas también; por ejemplo, si un objeto creado por la nueva biblioteca se pasa a las funciones de la biblioteca anterior, es posible que se produzca un error, ya que estas bibliotecas podrían interpretar el objeto de manera diferente.
Se usan diferentes enfoques según las características de la bibliotecas. 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 se comprometen a mantener
Estabilidades de API y ABI
- LL-NDK incluye las siguientes bibliotecas:
libEGL.so
,libGLESv1_CM.so
,libGLESv2.so
,libGLESv3.so
libandroid_net.so
,libc.so
ylibdl.so
liblog.so
,libm.so
,libnativewindow.so
,libneuralnetworks.so
,libsync.so
libvndksupport.so
ylibvulkan.so
,
- LL-NDK incluye las siguientes bibliotecas:
- Bibliotecas de VNDK (VNDK) aptas son Framework compartidos
Bibliotecas que no se pueden copiar dos veces con seguridad. Los módulos del framework
Los módulos de proveedores pueden vincularse con sus propias copias. Un framework compartido
puede convertirse en una biblioteca de VNDK apta solo si cumple con los siguientes requisitos:
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 objeta los usos que hacen los proveedores.
- Las bibliotecas solo de framework (SOLO FWK) son compartidas de framework
Bibliotecas que no pertenecen a las categorías mencionadas anteriormente Estos
bibliotecas:
- Se consideran detalles de implementación internos del framework.
- Los módulos de proveedores no deben acceder a ellos.
- Tener ABI o APIs inestables y ninguna garantía de compatibilidad entre APIs y ABI
- No se copian.
HAL del mismo proceso (SP-HAL)
La HAL del mismo proceso (SP-HAL) es un conjunto de HAL predeterminadas. Se implementan como bibliotecas compartidas por el proveedor y se cargan en un framework Procesos Las SP-HAL están aisladas por un espacio de nombres del vinculador (controla la las bibliotecas y símbolos visibles para las bibliotecas compartidas). Las HAL de SP deben solo dependen de LL-NDK y VNDK-SP.
VNDK-SP es un subconjunto predefinido de bibliotecas de VNDK aptas. Bibliotecas de VNDK-SP se revisan cuidadosamente para garantizar la carga doble de las bibliotecas de VNDK-SP en el framework. procesos no causa problemas. Tanto las SP-HAL como las VNDK-SP se definen según lo siguiente: 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 de VNDK-SP especifican vndk: { support_system_process: true }
en sus archivos Android.bp. Si vndk: {private:true}
también es
especificada, estas bibliotecas se llaman VNDK-SP-Private
y se
invisible para SP-HALS.
Las siguientes son bibliotecas solo de framework con excepciones de RS (FWK-SOLO-RS):
libft2.so
(RenderScript)libmediandk.so
(RenderScript)
Control de versiones del VNDK
Las bibliotecas compartidas del VNDK tienen control de versiones:
- 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 dominio raíz del VNDK.
com.android.vndk.v${ro.vndk.version}
y se activó en/apex/com.android.vndk.v${ro.vndk.version}
El algoritmo elige el valor de ro.vndk.version
a continuación:
- Si
BOARD_VNDK_VERSION
no es igual acurrent
, usaBOARD_VNDK_VERSION
. - Si
BOARD_VNDK_VERSION
es igual acurrent
: - Si
PLATFORM_VERSION_CODENAME
esREL
, usaPLATFORM_SDK_VERSION
(p. ej.,28
) - De lo contrario, usa
PLATFORM_VERSION_CODENAME
(p.ej.,P
).
Conjunto de pruebas de proveedores (VTS)
El Paquete de pruebas del proveedor de Android (VTS) exige una
la propiedad ro.vndk.version
no está vacía. Ambos dispositivos lanzados recientemente
y la actualización de dispositivos deben definir ro.vndk.version
. Algunas pruebas de VNDK
casos (p.ej., VtsVndkFilesTest
y
VtsVndkDependencyTest
) se basan en ro.vndk.version
para cargar los conjuntos de datos de bibliotecas VNDK aptas que coincidan.