Habilitación del VNDK

El VNDK requiere varios cambios en el código base para separar las preocupaciones entre el proveedor y el sistema. Utilice la siguiente guía para habilitar VNDK en una base de código de proveedor/OEM.

Construir bibliotecas del sistema

El sistema de compilación contiene varios tipos de objetos, incluidas bibliotecas (compartidas, estáticas o de encabezado) y archivos binarios.

Figura 1. Construir bibliotecas del sistema

• Las bibliotecas core son utilizadas por la imagen del sistema, en la imagen del sistema. Estas bibliotecas no pueden ser utilizadas por las bibliotecas vendor , vendor_available , vndk o vndk-sp .

  cc_library {
      name: "libThatIsCore",
      ...
  }
  

• Las bibliotecas vendor-only (o proprietary ) se utilizan en la imagen del proveedor, en la imagen del proveedor.

  cc_library {
      name: "libThatIsVendorOnly",
      proprietary: true,
      # or: vendor: true, # (for things in AOSP)
      ...
  }
  

• Las bibliotecas vendor_available son utilizadas por la imagen del proveedor, en la imagen del proveedor (pueden contener duplicados de core ).

  cc_library {
      name: "libThatIsVendorAvailable",
      vendor_available: true,
      ...
  }
  

• Las bibliotecas vndk las utiliza la imagen del proveedor, en la imagen del sistema.

  cc_library {
      name: "libThatIsVndk",
      vendor_available: true,
      vndk: {
          enabled: true,
      }
      ...
  }
  

• Las bibliotecas vndk-sp son utilizadas por la imagen del proveedor y también indirectamente por la imagen del sistema.

  cc_library {
      name: "libThatIsVndkSp",
      vendor_available: true,
      vndk: {
          enabled: true,
          support_system_process: true,
      }
      ...
  }
  

• Las bibliotecas llndk son utilizadas tanto por el sistema como por las imágenes del proveedor.

  cc_library {
      name: "libThatIsLlndk",
      llndk: {
          symbol_file: "libthatisllndk.map.txt"
      }
      ...
  }
  

Cuando una biblioteca está marcada como vendor_available:true , se compila dos veces:

• Una vez para la plataforma (y por lo tanto instalado en /system/lib )
• Una vez para el proveedor (y por lo tanto instalado en /vendor/lib o VNDK APEX)

Las versiones de proveedores de bibliotecas se crean con -D__ANDROID_VNDK__ . Los componentes privados del sistema que pueden cambiar significativamente en futuras versiones de Android están deshabilitados con esta bandera. Además, diferentes bibliotecas exportan un conjunto diferente de encabezados (como liblog ). Las opciones específicas para una variante de proveedor de un objetivo se pueden especificar en un archivo Android.bp en:

target: { vendor: { … } }

Habilitando VNDK para una base de código

Para habilitar el VNDK para una base de código:

1. Determine la elegibilidad calculando los tamaños requeridos de las particiones vendor.img y system.img .
2. Habilite BOARD_VNDK_VERSION=current . Puede agregar a BoardConfig.mk o crear componentes con él directamente (por ejemplo, m -j BOARD_VNDK_VERSION=current MY-LIB ).

Después de habilitar BOARD_VNDK_VERSION=current , el sistema de compilación aplica los siguientes requisitos de dependencia y encabezado.

Gestionar dependencias

Un objeto vendor que depende de un componente core que no existe en vndk o como objeto vendor debe resolverse mediante una de las siguientes opciones:

• La dependencia se puede eliminar.
• Si el componente core es propiedad del vendor , se puede marcar como vendor_available o vendor .
• Es posible que se transmita a Google un cambio que haga que el objeto principal forme parte del vndk .

Además, si un componente core tiene dependencias de un componente vendor , el componente vendor debe convertirse en un componente core o la dependencia debe eliminarse de otra manera (por ejemplo, eliminando la dependencia o moviendo la dependencia a un componente vendor ). ).

Gestionar encabezados

Se deben eliminar las dependencias de encabezados globales para permitir que el sistema de compilación sepa si debe compilar los encabezados con o sin -D__ANDROID_VNDK__ . Por ejemplo, aún se puede acceder a los encabezados de libutils como utils/StrongPointer.h utilizando la biblioteca de encabezados libutils_headers .

Algunos encabezados (como unistd.h ) ya no se pueden incluir de forma transitiva, pero se pueden incluir localmente.

Finalmente, la parte pública de private/android_filesystem_config.h se ha movido a cutils/android_filesystem_config.h . Para administrar estos encabezados, realice una de las siguientes acciones:

• Elimine la dependencia de private/android_filesystem_config.h reemplazando todas las macros AID_* con llamadas getgrnam / getpwnam si es posible. Por ejemplo:
  • (uid_t)AID_WIFI se convierte en getpwnam("wifi")->pw_uid .
  • (gid_t)AID_SDCARD_R se convierte en getgrnam("sdcard_r")->gr_gid .
  Para obtener más información, consulte private/android_filesystem_config.h .
• Para AIS codificado, incluya cutils/android_filesystem_config.h .