Extensiones VNDK

Los fabricantes de dispositivos Android cambian el código fuente de las bibliotecas AOSP por varias razones. Algunos proveedores vuelven a implementar funciones en las bibliotecas AOSP para aumentar el rendimiento, mientras que otros proveedores agregan nuevos enlaces, nuevas API o nuevas funcionalidades a las bibliotecas AOSP. Esta sección proporciona pautas para extender las bibliotecas AOSP de una manera que no rompa CTS/VTS.

Reemplazo directo

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

• Las funciones AOSP no deben eliminarse.
• Las estructuras no deben alterarse si tales estructuras están expuestas a sus usuarios.
• No se debe reforzar la condición previa de las funciones.
• Las funciones deben proporcionar funcionalidades equivalentes.
• La poscondición de las funciones no debe debilitarse.

Clasificaciones de módulos extendidos

Clasifique los módulos por las funcionalidades que definen y usan .

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

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

• Los módulos de solo definición de AOSP (módulo DA) no definen nuevas funcionalidades que no estaban 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 de 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á 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 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 UA-Module y UX-Module .

• Los módulos que usan solo AOSP (módulo UA) solo usan funcionalidades 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, 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 se basa en otra biblioteca no 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 los usos son independientes entre sí:

Mecanismo de extensión VNDK

Los módulos de proveedores que se basan en 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 las funcionalidades extendidas, los proveedores deben copiar las bibliotecas compartidas DAUX, DXUA y DXUX en 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 deben copiarse, por lo que los módulos de proveedores no deben depender de las funcionalidades ampliadas 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 de AOSP se modifican de manera incompatible con API/ABI, es posible que las bibliotecas de AOSP en GSI no se vinculen o den como resultado comportamientos indefinidos.