Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

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 mejorar 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 utilizar la biblioteca compartida modificada sin recompilaciones. Este requisito implica lo siguiente:

  • Las funciones de AOSP no deben eliminarse.
  • Las estructuras no se deben alterar si tales estructuras están expuestas a sus usuarios.
  • No se deben fortalecer las condiciones previas de las funciones.
  • Las funciones deben proporcionar funcionalidades equivalentes.
  • La condición posterior de las funciones no debe debilitarse.

Clasificaciones de módulos extendidas

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

Nota : Aquí se usa Functionalities 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 definición solo de AOSP (módulo DA) no definen nuevas funcionalidades que no estaban en la contraparte de AOSP.
    • Ejemplo 1. Una biblioteca AOSP intacta 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 no AOSP llamada libfoo.so , 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 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 sin modificar es un módulo UA.
    • Ejemplo 2. Si una biblioteca compartida libjpeg.so modificada solo se basa en 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 de 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í:

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

Mecanismo de extensión VNDK

Los módulos del proveedor 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 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 se deben copiar, por lo que los módulos de los proveedores 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 de sistema genérica (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 lugar a comportamientos no definidos.