Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Compatibilidad con el sistema de compilación VNDK

En Android 8.1 y superior, el sistema de compilación tiene compatibilidad con VNDK incorporada. Cuando la compatibilidad con VNDK está habilitada, el sistema de compilación verifica las dependencias entre los módulos, crea una variante específica del proveedor para los módulos del proveedor e instala automáticamente esos módulos en los directorios designados.

Ejemplo de soporte de compilación de VNDK

En este ejemplo, el Android.bp definición de módulo define una biblioteca denominada libexample . El vendor_available propiedad indica módulos de marco y módulos vendedor puede depender de libexample :

libexample vendor_available: true y vndk.enabled: true

Apoyo Figura 1. VNDK activar

Tanto el marco ejecutable /system/bin/foo y el ejecutable proveedor /vendor/bin/bar dependerá de libexample y tienen libexample en sus shared_libs propiedades.

Si libexample es utilizado por los dos módulos de marco y de los módulos de proveedores, dos variantes de libexample se construyen. La variante de núcleo (el nombre de libexample ) se utiliza por módulos de marco y de la variante vendedor (el nombre de libexample.vendor ) se utiliza por módulos de proveedores. Las dos variantes se instalan en diferentes directorios:

  • La variante de núcleo se instala en /system/lib[64]/libexample.so .
  • La variante proveedor se instala en VNDK APEX porque vndk.enabled es true .

Para más detalles, véase Definición de módulo .

Configurar el soporte de compilación

Para habilitar el soporte de sistema de construcción completo para un dispositivo de producto, añadir BOARD_VNDK_VERSION a BoardConfig.mk :

BOARD_VNDK_VERSION := current

Esta configuración tiene un efecto global: Cuando se define en BoardConfig.mk , todos los módulos se comprueban. Como no existe un mecanismo a la lista negra o lista blanca de un módulo que no funciona, debe limpiar todas las dependencias innecesarias antes de añadir BOARD_VNDK_VERSION . Puede probar y compilar un módulo mediante el establecimiento de BOARD_VNDK_VERSION en las variables de entorno:

$ BOARD_VNDK_VERSION=current m module_name.vendor

Cuando BOARD_VNDK_VERSION está activado, varias rutas de búsqueda por defecto mundial cabecera se eliminan. Éstos incluyen:

  • frameworks/av/include
  • frameworks/native/include
  • frameworks/native/opengl/include
  • hardware/libhardware/include
  • hardware/libhardware_legacy/include
  • hardware/ril/include
  • libnativehelper/include
  • libnativehelper/include_deprecated
  • system/core/include
  • system/media/audio/include

Si un módulo depende de las cabeceras de estos directorios, debe especificar (explícitamente) las dependencias con header_libs , static_libs , y / o shared_libs .

VNDK APEX

En Android 10 e inferiores, módulos con vndk.enabled fueron instalados en /system/lib[64]/vndk[-sp]-${VER} . En Android 11 y superior, bibliotecas VNDK están empaquetados en un formato APEX y el nombre de VNDK APEX es com.android.vndk.v${VER} . Dependiendo de la configuración del dispositivo, VNDK APEX es aplanada o sin aplanar y está disponible de la ruta canónica /apex/com.android.vndk.v${VER} .

VNDK APEX

Figura 2. VNDK APEX

Definición de módulo

Para construir Android con BOARD_VNDK_VERSION , debe revisar la definición del módulo, ya sea en Android.mk o Android.bp . Esta sección describe diferentes tipos de definiciones de módulo, varias propiedades de módulo relacionadas con VNDK y verificaciones de dependencia implementadas en el sistema de compilación.

Módulos de proveedores

Los módulos de proveedor son archivos ejecutables específicos de cada proveedor o bibliotecas compartidas que deben instalarse en una partición de proveedor. En Android.bp archivos, módulos proveedores deben establecer vendedor o propiedad exclusiva de true . En Android.mk archivos, módulos proveedores deben establecer LOCAL_VENDOR_MODULE o LOCAL_PROPRIETARY_MODULE de true .

Si BOARD_VNDK_VERSION está definido, el sistema de construcción no permite dependencias entre módulos y módulos de proveedores marco y emite errores si:

  • un módulo sin vendor:true depende de un módulo con vendor:true o
  • un módulo con vendor:true depende de un no llndk_library módulo que no tiene ni vendor:true ni vendor_available:true .

La comprobación de dependencia se aplica a header_libs , static_libs y shared_libs en Android.bp , y para LOCAL_HEADER_LIBRARIES , LOCAL_STATIC_LIBRARIES y LOCAL_SHARED_LIBRARIES en Android.mk .

LL-NDK

Las bibliotecas compartidas LL-NDK son bibliotecas compartidas con ABI estables. Tanto el marco como los módulos del proveedor comparten la misma implementación y la más reciente. Para cada LL-NDK biblioteca compartida, Android.bp contiene una llndk_library definición de módulo:

llndk_library {
    name: "libvndksupport",
    symbol_file: "libvndksupport.map.txt",
}

Esta definición de módulo especifica un nombre de módulo y un archivo de símbolo que describe los símbolos visibles para los módulos del proveedor. Por ejemplo:

LIBVNDKSUPPORT {
  global:
    android_load_sphal_library; # llndk
    android_unload_sphal_library; # llndk
  local:
    *;
};

Basado en el archivo de símbolos, el sistema de construcción genera una biblioteca compartida de código auxiliar para los módulos de proveedores, que enlazan con estas bibliotecas cuando BOARD_VNDK_VERSION está activado. Un símbolo se incluye en la biblioteca compartida de stub solo si:

  • No está definido en la sección final con _PRIVATE o _PLATFORM ,
  • No tiene #platform-only etiqueta, y
  • No tienen #introduce* etiquetas o los partidos de la etiqueta con el objetivo.

VNDK

En Android.bp archivos, cc_library , cc_library_static , cc_library_shared y cc_library_headers módulo de definiciones apoyan tres propiedades relacionadas con VNDK: vendor_available , vndk.enabled y vndk.support_system_process .

Si vendor_available o vndk.enabled es true , dos variantes (básicos y de proveedores) pueden ser construidos. La variante principal debe tratarse como un módulo de marco y la variante de proveedor debe tratarse como un módulo de proveedor. Si algunos módulos del marco dependen de este módulo, se construye la variante principal. Si algunos módulos de proveedor dependen de este módulo, se crea la variante de proveedor. El sistema de compilación aplica las siguientes comprobaciones de dependencia:

  • La variante principal siempre es solo marco y es inaccesible para los módulos de los proveedores.
  • La variante del proveedor siempre es inaccesible para los módulos del marco.
  • Todas las dependencias de la variante de proveedor, que se especifican en header_libs , static_libs , y / o shared_libs , deben ser o bien una llndk_library o un módulo con vendor_available o vndk.enabled .
  • Si vendor_available es true , la variante vendedor es accesible a todos los módulos de proveedores.
  • Si vendor_available es false , la variante de vendedor es accesible sólo a otros módulos VNDK-SP VNDK o (es decir, módulos con vendor:true lata no enlace vendor_available:false módulos).

La ruta de instalación por defecto para cc_library o cc_library_shared está determinada por las reglas siguientes:

  • La variante de núcleo se instala en /system/lib[64] .
  • La ruta de instalación de la variante del proveedor puede variar:
    • Si vndk.enabled es false , la variante de proveedor se instala en /vendor/lib[64] .
    • Si vndk.enabled es true , la variante proveedor se instala en VNDK APEX ( com.android.vndk.v${VER} ).

La siguiente tabla resume cómo el sistema de compilación maneja las variantes del proveedor:

vendor_available vndk
activado
vndk
support_same_process
Descripciones de variantes de proveedores
true false false Las variantes son proveedores de dong-ONLY. Las bibliotecas compartidas se instalan en /vendor/lib[64] .
true No válido (error de generación)
true false Las variantes de los proveedores son VNDK. Las bibliotecas compartidas se instalan en VNDK APEX.
true Las variantes de los proveedores son VNDK-SP. Las bibliotecas compartidas se instalan en VNDK APEX.

false

false

false

Sin variantes de proveedor. Este módulo es FWK-ONLY.

true No válido (error de generación)
true false Las variantes de los proveedores son VNDK-privada. Las bibliotecas compartidas se instalan en VNDK APEX. Estos no deben ser utilizados directamente por módulos de proveedores.
true Las variantes de los proveedores son VNDK-SP-privada. Las bibliotecas compartidas se instalan en VNDK APEX. Estos no deben ser utilizados directamente por módulos de proveedores.

Extensiones VNDK

Las extensiones de VNDK son bibliotecas compartidas de VNDK con API adicionales. Las extensiones se instalan en /vendor/lib[64]/vndk[-sp] (sin sufijo de versión) y anulan la VNDK original de bibliotecas compartidas en tiempo de ejecución.

Definición de extensiones VNDK

En Android 9 y superior, Android.bp forma nativa soporta extensiones VNDK. Para construir una extensión VNDK, definir otro módulo con un vendor:true y un extends propiedad:

cc_library {
    name: "libvndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    },
}

cc_library {
    name: "libvndk_ext",
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libvndk",
    },
}

Un módulo con vendor:true , vndk.enabled:true , y extends propiedades define la extensión VNDK:

  • El extends propiedad debe especificar una base VNDK nombre de la biblioteca compartida (o VNDK-SP compartió nombre de la biblioteca).
  • Las extensiones VNDK (o extensiones VNDK-SP) reciben el nombre de los nombres del módulo base desde el que se extienden. Por ejemplo, el binario de salida de libvndk_ext es libvndk.so en lugar de libvndk_ext.so .
  • Extensiones VNDK se instalan en /vendor/lib[64]/vndk .
  • Extensiones VNDK-SP se instalan en /vendor/lib[64]/vndk-sp .
  • Las bibliotecas de base compartido deben tener tanto vndk.enabled:true y vendor_available:true .

Una extensión VNDK-SP debe extenderse desde una biblioteca VNDK-SP compartido ( vndk.support_system_process debe ser igual):

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

cc_library {
    name: "libvndk_sp_ext",
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libvndk_sp",
        support_system_process: true,
    },
}

Las extensiones VNDK (o extensiones VNDK-SP) pueden depender de las bibliotecas compartidas de otros proveedores:

cc_library {
    name: "libvndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    },
}

cc_library {
    name: "libvndk_ext",
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libvndk",
    },
    shared_libs: [
        "libvendor",
    ],
}

cc_library {
    name: "libvendor",
    vendor: true,
}

Usando extensiones VNDK

Si un módulo proveedor depende de APIs adicionales definidos por las extensiones VNDK, el módulo debe especificar el nombre de la extensión VNDK en su shared_libs propiedad:

// A vendor shared library example
cc_library {
    name: "libvendor",
    vendor: true,
    shared_libs: [
        "libvndk_ext",
    ],
}

// A vendor executable example
cc_binary {
    name: "vendor-example",
    vendor: true,
    shared_libs: [
        "libvndk_ext",
    ],
}

Si un módulo proveedor depende de extensiones VNDK, esas extensiones VNDK se instalan en /vendor/lib[64]/vndk[-sp] automáticamente. Si un módulo ya no depende de una extensión VNDK, agregar un paso limpio para CleanSpec.mk para eliminar la biblioteca compartida. Por ejemplo:

$(call add-clean-step, rm -rf $(TARGET_OUT_VENDOR)/lib/libvndk.so)

Compilación condicional

En esta sección se describe cómo hacer frente a las diferencias sutiles (por ejemplo, adición o eliminación de una característica de una de las variantes) entre los tres siguientes VNDK bibliotecas compartidas:

  • Variante Core (por ejemplo /system/lib[64]/libexample.so )
  • Variante del vendedor (por ejemplo /apex/com.android.vndk.v${VER}/lib[64]/libexample.so )
  • Extensión VNDK (por ejemplo /vendor/lib[64]/vndk[-sp]/libexample.so )

Indicadores del compilador condicional

El sistema de construcción Android define __ANDROID_VNDK__ para las variantes de los proveedores y las extensiones VNDK de forma predeterminada. Puede proteger el código con las protecciones del preprocesador C:

void all() { }

#if !defined(__ANDROID_VNDK__)
void framework_only() { }
#endif

#if defined(__ANDROID_VNDK__)
void vndk_only() { }
#endif

Además de __ANDROID_VNDK__ , diferentes cflags o cppflags pueden especificarse en Android.bp . Los cflags o cppflags especificados en target.vendor es específico de la variante vendedor.

Por ejemplo, el siguiente Android.bp define libexample y libexample_ext :

cc_library {
    name: "libexample",
    srcs: ["src/example.c"],
    vendor_available: true,
    vndk: {
        enabled: true,
    },
    target: {
        vendor: {
            cflags: ["-DLIBEXAMPLE_ENABLE_VNDK=1"],
        },
    },
}

cc_library {
    name: "libexample_ext",
    srcs: ["src/example.c"],
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libexample",
    },
    cflags: [
        "-DLIBEXAMPLE_ENABLE_VNDK=1",
        "-DLIBEXAMPLE_ENABLE_VNDK_EXT=1",
    ],
}

Y este es el listado de código de src/example.c :

void all() { }

#if !defined(LIBEXAMPLE_ENABLE_VNDK)
void framework_only() { }
#endif

#if defined(LIBEXAMPLE_ENABLE_VNDK)
void vndk() { }
#endif

#if defined(LIBEXAMPLE_ENABLE_VNDK_EXT)
void vndk_ext() { }
#endif

Según estos dos archivos, el sistema de compilación genera bibliotecas compartidas con los siguientes símbolos exportados:

Ruta de instalación Símbolos exportados
/system/lib[64]/libexample.so all , framework_only
/apex/com.android.vndk.v${VER}/lib[64]/libexample.so all , vndk
/vendor/lib[64]/vndk/libexample.so all , vndk , vndk_ext

Requisitos de los símbolos exportados

El corrector VNDK ABI compara el proveedor ABI de VNDK variantes y extensiones VNDK a la referencia ABI vertederos bajo prebuilts/abi-dumps/vndk .

  • Símbolos exportados por variantes de proveedores VNDK (por ejemplo /apex/com.android.vndk.v${VER}/lib[64]/libexample.so ) deben ser idénticos a (no los supersets de) los símbolos definidos en ABI vertederos.
  • Símbolos exportados por extensiones VNDK (por ejemplo /vendor/lib[64]/vndk/libexample.so ) deben ser superconjuntos de los símbolos definidos en ABI vertederos.

Si VNDK proveedor variantes o extensiones VNDK no siguen los requisitos anteriores, VNDK ABI emite comprobador de errores se acumulan y se detiene la construcción.

Excluir archivos de origen o bibliotecas compartidas de variantes de proveedores

Para excluir archivos de origen de la variante proveedor, ellos añadir a la exclude_srcs propiedad. Del mismo modo, las bibliotecas compartidas para asegurar que no están vinculados con la variante proveedor, agregar esas bibliotecas a la exclude_shared_libs propiedad. Por ejemplo:

cc_library {
    name: "libexample_cond_exclude",
    srcs: ["fwk.c", "both.c"],
    shared_libs: ["libfwk_only", "libboth"],
    vendor_available: true,
    target: {
        vendor: {
            exclude_srcs: ["fwk.c"],
            exclude_shared_libs: ["libfwk_only"],
        },
    },
}

En este ejemplo, la variante de núcleo de libexample_cond_exclude incluye el código de fwk.c y both.c y depende de las bibliotecas compartidas libfwk_only y libboth . La variante proveedor de libexample_cond_exclude incluye sólo el código de both.c porque fwk.c se excluye por el exclude_srcs propiedad. Del mismo modo, depende solamente de la biblioteca compartida libboth porque libfwk_only está excluido por el exclude_shared_libs propiedad.

Exportar encabezados de extensiones VNDK

Una extensión VNDK puede agregar nuevas clases o nuevas funciones a una biblioteca compartida VNDK. Se sugiere mantener esas declaraciones en encabezados independientes y evitar cambiar los encabezados existentes.

Por ejemplo, un nuevo archivo de cabecera include-ext/example/ext/feature_name.h se crea para la extensión VNDK libexample_ext :

  • Android.bp
  • include-ext / example / ext / feature_name.h
  • incluir / ejemplo / ejemplo.h
  • src / example.c
  • src / ext / feature_name.c

En el siguiente Android.bp , libexample exportaciones solamente include , mientras que libexample_ext exportaciones tanto include y include-ext . Esto asegura feature_name.h no serán incluidos de forma incorrecta por los usuarios de libexample :

cc_library {
    name: "libexample",
    srcs: ["src/example.c"],
    export_include_dirs: ["include"],
    vendor_available: true,
    vndk: {
        enabled: true,
    },
}

cc_library {
    name: "libexample_ext",
    srcs: [
        "src/example.c",
        "src/ext/feature_name.c",
    ],
    export_include_dirs: [
        "include",
        "include-ext",
    ],
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libexample",
    },
}

Si la separación de las extensiones de los ficheros de cabecera independientes no es factible, una alternativa es añadir #ifdef guardias. Sin embargo, asegúrese de que todos los usuarios de la extensión VNDK agreguen las banderas de definición. Es posible definir cc_defaults añadir definir banderas a cflags y bibliotecas de enlace compartida con shared_libs .

Por ejemplo, para agregar una nueva función miembro Example2::get_b() a la extensión VNDK libexample2_ext , debe modificar el archivo de cabecera existente y añadir un #ifdef guardia:

#ifndef LIBEXAMPLE2_EXAMPLE_H_
#define LIBEXAMPLE2_EXAMPLE_H_

class Example2 {
 public:
  Example2();

  void get_a();

#ifdef LIBEXAMPLE2_ENABLE_VNDK_EXT
  void get_b();
#endif

 private:
  void *impl_;
};

#endif  // LIBEXAMPLE2_EXAMPLE_H_

A cc_defaults nombrados libexample2_ext_defaults se define para los usuarios de libexample2_ext :

cc_library {
    name: "libexample2",
    srcs: ["src/example2.cpp"],
    export_include_dirs: ["include"],
    vendor_available: true,
    vndk: {
        enabled: true,
    },
}

cc_library {
    name: "libexample2_ext",
    srcs: ["src/example2.cpp"],
    export_include_dirs: ["include"],
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libexample2",
    },
    cflags: [
        "-DLIBEXAMPLE2_ENABLE_VNDK_EXT=1",
    ],
}

cc_defaults {
    name: "libexample2_ext_defaults",
    shared_libs: [
        "libexample2_ext",
    ],
    cflags: [
        "-DLIBEXAMPLE2_ENABLE_VNDK_EXT=1",
    ],
}

Los usuarios de libexample2_ext pueden incluir simplemente libexample2_ext_defaults en su defaults la propiedad:

cc_binary {
    name: "example2_user_executable",
    defaults: ["libexample2_ext_defaults"],
    vendor: true,
}

Paquetes de productos

En el sistema de construcción de Android, las variables PRODUCT_PACKAGES especifica el ejecutables, bibliotecas compartidas, o paquetes que deben ser instalados en el dispositivo. Las dependencias transitivas de los módulos especificados también se instalan implícitamente en el dispositivo.

Si BOARD_VNDK_VERSION está activado, los módulos con vendor_available o vndk.enabled reciben un tratamiento especial. Si un módulo de marco depende de un módulo con vendor_available o vndk.enabled , la variante de núcleo está incluido en el conjunto de instalación transitiva. Si un módulo proveedor depende de un módulo con vendor_available , la variante proveedor está incluido en el conjunto de instalación transitiva. Sin embargo, las variantes proveedor de módulos con vndk.enabled están instalados si son o no son utilizados por los módulos de proveedores.

Cuando las dependencias son invisibles para el sistema de construcción (por ejemplo, las bibliotecas compartidas que se pueden abrir con dlopen() en tiempo de ejecución), debe especificar los nombres de los módulos en PRODUCT_PACKAGES para instalar los módulos de forma explícita.

Si un módulo tiene vendor_available o vndk.enabled , el nombre del módulo se destaca por su variante núcleo. Para especificar explícitamente la variante proveedor en PRODUCT_PACKAGES , anexar una .vendor sufijo al nombre del módulo. Por ejemplo:

cc_library {
    name: "libexample",
    srcs: ["example.c"],
    vendor_available: true,
}

En este ejemplo, libexample significa /system/lib[64]/libexample.so y libexample.vendor significa /vendor/lib[64]/libexample.so . Para instalar /vendor/lib[64]/libexample.so , añadir libexample.vendor a PRODUCT_PACKAGES :

PRODUCT_PACKAGES += libexample.vendor