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

Se usó la API de Cloud Translation para traducir esta página.

Manifiestos

Un objeto VINTF agrega datos del manifiesto del dispositivo y archivos de manifiesto del marco (XML). Ambos manifiestos comparten un formato, aunque no todos los elementos se aplican a ambos (para obtener detalles sobre el esquema, consulte Esquema del archivo de manifiesto ).

Manifiesto del dispositivo

El manifiesto del dispositivo (proporcionado por el dispositivo) consta del manifiesto del proveedor y el manifiesto del ODM.

El manifiesto del proveedor especifica HAL, versiones de políticas de SELinux, etc. comunes a un SoC. Se recomienda colocarlo en el árbol de fuentes de Android en device/ VENDOR / DEVICE /manifest.xml , pero se pueden usar varios archivos de fragmentos. Para obtener más información, consulte Fragmentos de manifiesto y Generar DM a partir de fragmentos .
El manifiesto de ODM enumera las HAL específicas del producto en la partición de ODM . El objeto VINTF carga el manifiesto ODM en este orden:
1. Si se define SKU (donde SKU es el valor de la propiedad ro.boot.product.hardware.sku ), /odm/etc/vintf/manifest_ SKU .xml
2. /odm/etc/vintf/manifest.xml
3. Si se define SKU , /odm/etc/manifest_ SKU .xml
4. /odm/etc/manifest.xml
El manifiesto del proveedor enumera las HAL específicas del producto en la partición del proveedor. El objeto VINTF carga el manifiesto del proveedor en este orden:
1. Si se define SKU (donde SKU es el valor de la propiedad ro.boot.product.vendor.sku ), /vendor/etc/vintf/manifest_ SKU .xml
2. /vendor/etc/vintf/manifest.xml
El objeto VINTF carga el manifiesto del dispositivo en este orden:
1. Si existe el manifiesto del proveedor, combine lo siguiente:
  1. El manifiesto del proveedor
  2. Fragmentos de manifiesto de proveedor opcionales
  3. Manifiesto ODM opcional
  4. Fragmentos de manifiesto ODM opcionales
2. De lo contrario, si existe el manifiesto ODM, combine el manifiesto ODM con los fragmentos opcionales del manifiesto ODM.
3. /vendor/manifest.xml (heredado, sin fragmentos)
Tenga en cuenta que:
- En los dispositivos heredados, se utilizan el manifiesto del proveedor heredado y el manifiesto ODM. El manifiesto ODM puede anular por completo el manifiesto del proveedor heredado.
- En los dispositivos lanzados con Android 9, el manifiesto de ODM se combina con el manifiesto del proveedor.
- Al combinar una lista de manifiestos, los manifiestos que aparecen más adelante en la lista pueden anular las etiquetas en los manifiestos que aparecen antes en la lista, siempre que las etiquetas en el último manifiesto tengan el atributo override="true" . Por ejemplo, el manifiesto ODM puede anular algunas etiquetas <hal> del manifiesto del proveedor. Consulte la documentación para la override de atributos a continuación.

Esta configuración permite que varios productos con la misma placa compartan la misma imagen de proveedor (que proporciona HAL comunes) pero que tengan diferentes imágenes ODM (que especifican HAL específicas del producto).

Este es un manifiesto de proveedor de ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="2.0" type="device" target-level="1">
    <hal>
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.4</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
            <instance>proprietary/0</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <version>2.0</version>
        <interface>
            <name>INfc</name>
            <instance>nfc_nci</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <fqname>@2.0::INfc/default</fqname>
    </hal>
    <hal>
        <name>android.hardware.drm</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ICryptoFactory</name>
            <instance>default</instance>
        </interface>
        <interface>
            <name>IDrmFactory</name>
            <instance>default</instance>
        </interface>
        <fqname>@1.1::ICryptoFactory/clearkey</fqname>
        <fqname>@1.1::IDrmFactory/clearkey</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.light</name>
        <version>1</version>
        <fqname>ILights/default</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.power</name>
        <version>2</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal format="native">
        <name>EGL</name>
        <version>1.1</version>
    </hal>
    <hal format="native">
        <name>GLES</name>
        <version>1.1</version>
        <version>2.0</version>
        <version>3.0</version>
    </hal>
    <sepolicy>
        <version>25.0</version>
    </sepolicy>
</manifest>

Aquí hay un manifiesto ODM de ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device">
    <!-- camera 3.4 in vendor manifest is ignored -->
    <hal override="true">
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.5</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
        </interface>
    </hal>
    <!-- NFC is declared to be disabled -->
    <hal override="true">
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
    </hal>
    <hal>
        <name>android.hardware.power</name>
        <transport>hwbinder</transport>
        <version>1.1</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
</manifest>

Aquí hay un manifiesto de dispositivo de ejemplo en un paquete OTA.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device" target-level="1">
    <!-- hals ommited -->
    <kernel version="4.4.176">
        <config>
            <key>CONFIG_ANDROID</key>
            <value>y</value>
        </config>
        <config>
            <key>CONFIG_ARM64</key>
            <value>y</value>
        </config>
    <!-- other configs ommited -->
    </kernel>
</manifest>

Para obtener más detalles, consulte Desarrollo de manifiestos de dispositivos .

Manifiesto del marco

El archivo de manifiesto del marco consta del manifiesto del sistema, el manifiesto del producto y el manifiesto system_ext.

El manifiesto del sistema (proporcionado por Google) se genera manualmente y se encuentra en el árbol de fuentes de Android en /system/libhidl/manifest.xml .
El manifiesto del producto (proporcionado por el dispositivo) enumera las HAL atendidas por los módulos instalados en la partición del producto.
El manifiesto system_ext (proporcionado por el dispositivo) enumera lo siguiente:
- HAL atendidos por módulos instalados en la partición system_ext;
- versiones VNDK;
- Versión del SDK del sistema.

De forma similar al manifiesto del dispositivo, se pueden utilizar varios archivos de fragmentos. Para obtener más información, consulte Fragmentos de manifiesto .

Aquí hay un manifiesto de framework de ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="framework">
    <hal>
        <name>android.hidl.allocator</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IAllocator</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.memory</name>
        <transport arch="32+64">passthrough</transport>
        <version>1.0</version>
        <interface>
            <name>IMapper</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.manager</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IServiceManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal>
        <name>android.frameworks.sensorservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISensorManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal max-level="5">
        <name>android.frameworks.schedulerservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISchedulingPolicyService</name>
            <instance>default</instance>
        </interface>
    </hal>
    <vendor-ndk>
        <version>27</version>
    </vendor-ndk>
    <system-sdk>
        <version>27</version>
    </system-sdk>
</manifest>

Fragmentos manifiestos

En Android 10 y versiones posteriores, puede asociar una entrada de manifiesto con un módulo HAL en el sistema de compilación. Esto facilita la inclusión condicional del módulo HAL en el sistema de compilación.

Ejemplo

En su archivo Android.bp o Android.mk , agregue vintf_fragments a cualquier módulo. Por ejemplo, puede modificar el módulo con su implementación de su HAL ( my.package.foo@1.0-service-bar ).

... {
    ...
    vintf_fragments: ["manifest_foo.xml"],
    ...
}

LOCAL_MODULE := ...
LOCAL_VINTF_FRAGMENTS := manifest_foo.xml

En un archivo llamado manifest_foo.xml , cree el manifiesto para este módulo. En el momento de la compilación, este manifiesto se agrega al dispositivo. Agregar una entrada aquí es lo mismo que agregar una entrada en el manifiesto principal del dispositivo. Esto permite que los clientes usen la interfaz y permite que VTS identifique qué implementaciones de HAL están en el dispositivo. Todo lo que hace un manifiesto regular, este manifiesto también lo hace.

El siguiente ejemplo implementa android.hardware.foo@1.0::IFoo/default , que se instala en la partición del vendor o del odm . Si está instalado en la partición system , product o system_ext , use type framework en lugar de type device .

<manifest version="1.0" type="device">
    <hal format="hidl">
        <name>android.hardware.foo</name>
        <transport>hwbinder</transport>
        <fqname>@1.0::IFoo/default</fqname>
    </hal>
</manifest>

Esquema de archivo de manifiesto

Esta sección describe el significado de estas etiquetas XML. Algunas etiquetas "obligatorias" pueden faltar en el archivo de origen en el árbol de fuentes de Android y pueden estar escritas por assemble_vintf en el momento de la compilación. Las etiquetas requeridas deben estar presentes en los archivos correspondientes en el dispositivo.

?xml

Opcional. Solo proporciona información al analizador XML.

manifest.version

Requerido. Meta-versión de este manifiesto. Describe los elementos esperados en el manifiesto. No relacionado con la versión XML.

manifest.type

Requerido. Tipo de este manifiesto. Tiene el device de valor para el archivo de manifiesto del dispositivo y el framework para el archivo de manifiesto del marco.

manifest.target-level

Obligatorio para el manifiesto del dispositivo. Especifica la versión de la matriz de compatibilidad del marco (FCM) con la que este manifiesto de dispositivo está destinado a ser compatible. Esto también se llama la versión FCM de envío del dispositivo.

manifest.hal

Opcional, se puede repetir. Un solo HAL (HIDL o nativo, como GL), según el atributo de format .

manifest.hal.format

Opcional. El valor puede ser uno de:

hidl : HAL HIDL. Este es el valor predeterminado.
aidl : AIDL HAL . Solo es válido en el manifiesto meta-versión 2.0 y superior.
native : HAL nativos.

manifest.hal.max-level

Opcional. Solo es válido en los manifiestos del marco. Si se establece, se deshabilitan las HAL con un nivel máximo inferior a la versión de FCM de destino en el manifiesto del marco.

manifest.hal.override

Opcional. El valor puede ser uno de:

true : anula otros elementos <hal> con el mismo <name> y versión principal. Si no hay <version> o <fqname> en este elemento <hal> , entonces el elemento <hal> declara que esta HAL está deshabilitada.
false : no anule otros elementos <hal> con el mismo <name> y versión principal.

manifest.hal.name

Requerido. Nombre de paquete completo de la HAL. Múltiples entradas HAL pueden usar el mismo nombre. Ejemplos:

android.hardware.camera (HIDL o AIDL HAL)
GLES (HAL nativo, solo requiere nombre)

manifest.hal.transport

Requerido cuando manifest.hal.format == "hidl" . NO debe estar presente de lo contrario. Indica qué transporte se usa cuando se consulta una interfaz de este paquete desde el administrador de servicios. El valor puede ser uno de:

hwbinder : modo encuadernado
passthrough : modo de paso

Opcional cuando manifest.hal.format == "aidl" . NO debe estar presente de lo contrario. Indica qué transporte se utiliza cuando una interfaz se sirve de forma remota. El valor debe ser:

inet : enchufe Inet

Se deben usar manifest.hal.transport.ip y manifest.hal.transport.port para especificar más la información de conexión Inet.

manifest.hal.transport.arch

Obligatorio para passthrough y no debe estar presente para hwbinder . Describe el valor de bits del servicio de transferencia que se proporciona. El valor puede ser uno de:

32 : modo de 32 bits
64 : modo de 64 bits
32+64 : Ambos

manifest.hal.transport.ip

Requerido para inet y NO debe estar presente de otra manera. Describe la dirección IP desde la que se sirve la interfaz remota.

manifest.hal.transport.port

Requerido para inet y NO debe estar presente de otra manera. Describe el puerto desde el que se sirve la interfaz remota.

manifest.hal.version

Opcional, se puede repetir. Una versión para las etiquetas hal en un manifiesto.

Para HIDL y HAL nativas, el formato es MAJOR . MINOR . Para ver ejemplos, consulte hardware/interfaces , vendor/${VENDOR}/interfaces , frameworks/hardware/interfaces o system/hardware/interfaces .

HIDL y las HAL nativas pueden usar varios campos de versión, siempre que representen distintas versiones principales , y solo se proporciona una versión secundaria por versión principal. Por ejemplo, 3.1 y 3.2 no pueden coexistir, pero 1.0 y 3.4 sí. Esto se aplica a todos los elementos hal con el mismo nombre, a menos que override="true" . Los valores de <version> no están asociados con <fqname> porque <fqname> lleva una versión.

Para las HAL de AIDL, la <version> no debe estar presente en los dispositivos que ejecutan Android 11 y versiones anteriores. <version> debe ser un entero único en dispositivos con Android 12 y superior. Debe haber como máximo una <version> para cada tupla (package, interface, instance) . Si no está presente, el valor predeterminado es 1 . El valor de <version> está asociado con todos los <fqname> en el mismo <hal> porque un <fqname> no lleva una versión.

manifest.hal.interface

Requerido, se puede repetir sin duplicados. Indique una interfaz en el paquete que tenga un nombre de instancia. Puede haber múltiples elementos <interface> en un <hal> ; los nombres deben ser distintos.

manifest.hal.interface.name

Requerido. Nombre de la interfaz.

manifest.hal.interface.instance

Se requiere, se puede repetir. Nombre de instancia de la interfaz. Puede tener varias instancias para una interfaz, pero no elementos <instance> duplicados.

manifest.hal.fqname

Opcional, se puede repetir. Una forma alternativa de especificar una instancia para HAL con el nombre manifest.hal.name .

Para HAL HIDL, el formato es @ MAJOR . MINOR :: INTERFACE / INSTANCE .
Para AIDL HALs, el formato es INTERFACE / INSTANCE .

manifest.sepolicy

Requerido. Contiene todas las entradas relacionadas con sepolicy.

manifest.sepolicy.version

Obligatorio para el manifiesto del dispositivo. Declara la versión de SELinux. Tiene el formato SDK_INT . PLAT_INT .

manifest.vendor-ndk

Requerido, puede repetir; necesario para el manifiesto del marco. No debe estar presente en el manifiesto del dispositivo. Varias entradas de <vendor-ndk> deben tener <version> diferentes. Describe un conjunto de instantáneas de VNDK proporcionadas por el marco.

manifest.vendor-ndk.version

Requerido. Este es un número entero positivo que representa la versión de la instantánea de VNDK.

manifest.vendor-ndk.library

Opcional, se puede repetir, sin duplicados. Describe un conjunto de bibliotecas de VNDK proporcionadas por el marco para esta instantánea del proveedor de VNDK. El valor es el nombre de archivo de una biblioteca, por ejemplo, libjpeg.so , incluido el prefijo lib y el sufijo .so . No se permiten componentes de ruta.

manifest.system-sdk.version

Opcional, se puede repetir, sin duplicados; utilizado solo por el manifiesto del marco. Describe un conjunto de versiones del SDK del sistema proporcionadas por el marco a las aplicaciones de los proveedores.

manifest.kernel

Opcional. Describe información estática sobre el kernel.

manifest.kernel.target-level

Opcional. Describe la rama del núcleo. Su valor predeterminado es manifest.target-level si no está presente. Debe ser mayor o igual que manifest.target-level . Consulte las reglas de coincidencia del núcleo para obtener más detalles.