Extensiones del VNDK

Los fabricantes de dispositivos Android cambian el código fuente de las bibliotecas de AOSP por varios motivos. Algunos proveedores vuelven a implementar funciones en las bibliotecas de AOSP para mejorar el rendimiento, mientras que otros agregan hooks, APIs o funciones nuevas a las bibliotecas de AOSP. En esta sección, se proporcionan lineamientos para extender las bibliotecas de AOSP de una manera que no rompa CTS/VTS.

Reemplazo directo

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

  • No se deben quitar las funciones de AOSP.
  • Las estructuras no deben alterarse si están expuestas a sus usuarios.
  • No se debe fortalecer 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 extendidos

Clasifica los módulos según las funciones que definen y usan.

Nota: Aquí se usa Funciones en lugar de API/ABI porque es posible agregar funciones sin cambiar ninguna API/ABI.

Según las funciones definidas en un módulo, los módulos se pueden clasificar en DA-Module y DX-Module:

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

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

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

Las definiciones y los usos son independientes entre sí:

Funciones utilizadas
Solo AOSP (UA) Extendido (UX)
Funcionalidades definidas Solo AOSP (DA) DAUA DAUX
Extendido (DX) DXUA DXUX

Mecanismo de extensión de VNDK

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

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

El reemplazo directo es importante porque las bibliotecas de VNDK no modificadas en el 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 la API o ABI, es posible que las bibliotecas de AOSP en el GSI no se vinculen o que se generen comportamientos no definidos.