Extensiones del VNDK

Los fabricantes de dispositivos Android cambian el código fuente de las bibliotecas del AOSP para varias razones. Algunos proveedores vuelven a implementar funciones en las bibliotecas del AOSP para mejoran el rendimiento mientras que otros proveedores agregan hooks, API nuevas o funcionalidades a las bibliotecas del AOSP. En esta sección, se proporcionan pautas para Extender las bibliotecas del AOSP de una manera que no dañe CTS/VTS

Reemplazo directo

Todas las bibliotecas compartidas modificadas deben ser compatibles con objetos binarios. reemplazos directos de su contraparte en AOSP. Todos los existentes Los usuarios del AOSP deben poder usar la biblioteca compartida modificada sin este tipo de recompilaciones. Este requisito implica lo siguiente:

  • No se deben quitar las funciones del AOSP.
  • Las estructuras no deben alterarse si están expuestas a su usuarios.
  • No se debe reforzar la condición previa de las funciones.
  • Las funciones deben proporcionar funcionalidades equivalentes.
  • La condición posterior de las funciones no debe debilitarse.

Clasificaciones de módulos extendidas

Clasificar los módulos según las funcionalidades que definen y utilizar.

Nota: Aquí se usan las funcionalidades. en lugar de API/ABI porque es posible agregar funcionalidad sin cambiar para cualquier API o ABI.

Según las funcionalidades definidas en un módulo, se pueden clasificados en DA-Module y DX-Module:

  • Los módulos AOSP de solo definición (DA-Module) no definen nuevos que no formaban parte del AOSP.
    • Ejemplo 1: Una biblioteca del AOSP intacta y sin modificar Módulo de AD.
    • Ejemplo 2. Si un proveedor vuelve a escribir las funciones en libcrypto.so con instrucciones de SIMD (sin agregar nuevas funciones), el libcrypto.so modificado será un módulo de DA.
  • Los módulos de definición de extensiones (DX-Module) definen no tienen un equivalente del AOSP.
    • Ejemplo 1: Si un proveedor agrega una función auxiliar a libjpeg.so para acceder a algunos datos internos y, luego, libjpeg.so será una DX-Lib y la función recién agregada será la parte extendida de la biblioteca.
    • Ejemplo 2. Si un proveedor define una biblioteca no AOSP llamada libfoo.so, luego, libfoo.so será una DX-Lib.

Según las funcionalidades que use un módulo, estos se pueden clasificar en UA-Module y UX-Module.

  • Los módulos solo del AOSP (UA-Module) solo usan las funciones del AOSP. en sus implementaciones. No dependen de extensiones que no sean del AOSP.
    • Ejemplo 1: Una biblioteca del AOSP intacta y sin modificar Módulo UA.
    • Ejemplo 2. Si se modificó la biblioteca compartida libjpeg.so solo se basa en otras APIs de AOSP, por lo que será un módulo UA.
  • Los módulos de extensión (módulo de UX) dependen de algunos que no pertenecen al AOSP. funcionalidades en sus implementaciones.
    • Ejemplo 1: Si un libjpeg.so modificado depende de otra biblioteca no AOSP llamada libjpeg_turbo2.so, y el el libjpeg.so modificado será un módulo de UX.
    • Ejemplo 2. Si un proveedor agrega una nueva función a su libexif.so y su libjpeg.so modificada usan el función recién agregada desde libexif.so y, luego, su libjpeg.so será un módulo de UX.

Las definiciones y los usos son independientes entre sí:

Funcionalidades usadas
Solo AOSP (UA) Extensión (UX)
Funciones definidas Solo AOSP (DA) DAU DAUX
Extendida (DX) DXUA DXUX

Mecanismo de extensión del VNDK

Los módulos de proveedores que dependen de funcionalidades extendidas no funcionarán porque La biblioteca del AOSP con el mismo nombre no tiene la funcionalidad extendida. Si los módulos de proveedores dependen directa o indirectamente de las funcionalidades extendidas, los proveedores deben copiar las bibliotecas compartidas DAUX, DXUA y DXUX al proveedor partición (los procesos de proveedores siempre buscan bibliotecas compartidas en el proveedor la partición inicial). Sin embargo, las bibliotecas LL-NDK no deben copiarse, por lo que módulos no deben depender de las funcionalidades extendidas definidas por la versión LL-NDK.

Las bibliotecas compartidas DAUA pueden permanecer en la partición del sistema si la la biblioteca del AOSP correspondiente puede proporcionar la misma funcionalidad y el mismo proveedor seguirán funcionando cuando la partición del sistema se reemplace por un imagen del sistema (GSI).

El reemplazo directo es importante porque las bibliotecas de VNDK sin modificar en la GSI se vinculará con las bibliotecas compartidas modificadas ante una colisión de nombres. Si el botón Las bibliotecas del AOSP se modifican de una manera incompatible con la API y con la ABI. las bibliotecas en la GSI podrían no vincularse o generar comportamientos indefinidos.