Extensiones VNDK

Los fabricantes de dispositivos Android cambian el código fuente de las bibliotecas AOSP por varios motivos. Algunos proveedores reimplementan funciones en las bibliotecas AOSP para mejorar el rendimiento, mientras que otros agregan nuevos enlaces, nuevas API o nuevas funcionalidades a las bibliotecas AOSP. Esta sección proporciona pautas para ampliar las bibliotecas AOSP de una manera que no interrumpa CTS/VTS.

Reemplazo directo

Todas las bibliotecas compartidas modificadas deben ser compatibles con binarios y ser reemplazos directos de su contraparte AOSP. Todos los usuarios de AOSP existentes deben poder utilizar la biblioteca compartida modificada sin recompilaciones. Este requisito implica lo siguiente:

• Las funciones de AOSP no deben eliminarse.
• Las estructuras no deben modificarse si dichas estructuras están expuestas a sus usuarios.
• No se deben reforzar las condiciones previas de funciones.
• Las funciones deben proporcionar funcionalidades equivalentes.
• No se debe debilitar la poscondición de funciones.

Clasificaciones de módulos extendidos

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

Nota : Aquí se utilizan funcionalidades en lugar de API/ABI porque es posible agregar funcionalidades sin cambiar ninguna API/ABI.

Dependiendo de las funcionalidades definidas en un módulo, los módulos se pueden clasificar en Módulo DA y Módulo DX :

• Los módulos AOSP de solo definición (módulo DA) no definen nuevas funcionalidades que no estuvieran en la contraparte de AOSP.
  • Ejemplo 1. Una biblioteca AOSP intacta y sin modificar es un módulo DA.
  • Ejemplo 2. Si un proveedor reescribe las funciones en libcrypto.so con instrucciones SIMD (sin agregar nuevas funciones), entonces el libcrypto.so modificado será un módulo DA.
• Los módulos de extensión de definición (módulo DX) definen nuevas funcionalidades o no tienen una contraparte AOSP.
  • Ejemplo 1. Si un proveedor agrega una función auxiliar a libjpeg.so para acceder a algunos datos internos, entonces el libjpeg.so modificado será un DX-Lib y la función recién agregada será la parte extendida de la biblioteca.
  • Ejemplo 2. Si un proveedor define una biblioteca que no es AOSP llamada libfoo.so , entonces libfoo.so será una DX-Lib.

Dependiendo de las funcionalidades utilizadas por un módulo, los módulos se pueden clasificar en Módulo UA y Módulo UX .

• Los módulos de uso exclusivo de AOSP (módulo UA) solo utilizan funcionalidades de AOSP en sus implementaciones. No dependen de ninguna extensión que no sea AOSP.
  • Ejemplo 1. Una biblioteca AOSP intacta y sin modificar es un módulo UA.
  • Ejemplo 2. Si una biblioteca compartida modificada libjpeg.so solo depende de otras API de AOSP, entonces será un módulo UA.
• Los módulos de extensión de uso (módulo UX) se basan en algunas funcionalidades que no son AOSP en sus implementaciones.
  • Ejemplo 1. Si un libjpeg.so modificado depende de otra biblioteca que no sea AOSP llamada libjpeg_turbo2.so , entonces el libjpeg.so modificado será un módulo UX.
  • Ejemplo 2. Si un proveedor agrega una nueva función a su libexif.so modificado y su libjpeg.so modificado usa la función recién agregada de libexif.so , entonces su libjpeg.so modificado será un módulo UX.

Las definiciones y usos son independientes entre sí:

Mecanismo de extensión VNDK

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

Las bibliotecas compartidas de DAUA pueden permanecer en la partición del sistema si la biblioteca AOSP correspondiente puede proporcionar la misma funcionalidad y los módulos del proveedor continúan funcionando cuando la partición del sistema se sobrescribe con una imagen genérica del sistema (GSI).

El reemplazo directo es importante porque las bibliotecas VNDK no modificadas en GSI se vincularán con las bibliotecas compartidas modificadas en caso de colisión de nombres. Si las bibliotecas AOSP se modifican de manera incompatible con API/ABI, es posible que las bibliotecas AOSP en GSI no se vinculen o generen comportamientos indefinidos.