Manifiestos

Un objeto VINTF agrega datos desde device Archivos de manifiesto y manifiesto del framework (XML). Ambas opciones los manifiestos comparten un formato, aunque no todos los elementos se aplican a ambos (para obtener más información en el esquema, consulta Esquema del archivo de manifiesto).

Manifiesto del dispositivo

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

  • El manifiesto del proveedor especifica las HAL, las versiones de políticas de SELinux, etc. comunes a un SoC. Integra se recomienda colocarlo en el árbol de fuentes de Android en device/VENDOR/DEVICE/manifest.xml, pero varios fragmentos se pueden usar archivos adjuntos. Para obtener más información, consulta Fragmentos del manifiesto y Generar MD a partir de fragmentos
  • El manifiesto de ODM incluye HALs 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 HALs 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, combina lo siguiente:
      1. El manifiesto del proveedor
      2. Fragmentos opcionales del manifiesto del proveedor
      3. Manifiesto de ODM opcional
      4. Fragmentos opcionales del manifiesto de ODM
    2. De lo contrario, si el manifiesto de ODM existe, combinalo con el ODM opcional. fragmentos del manifiesto.
    3. /vendor/manifest.xml (heredado, sin fragmentos)
    4. Por último, combina los fragmentos del manifiesto de los APEX de cualquier proveedor.

    Ten en cuenta lo siguiente:

    • En los dispositivos heredados, se usan el manifiesto del proveedor heredado y el manifiesto del ODM. El El manifiesto del ODM puede anular por completo el manifiesto del proveedor heredado.
    • En los dispositivos que se lanzan con Android 9, el manifiesto ODM se combina con el manifiesto del proveedor.
    • Cuando se combina una lista de manifiestos, es posible que los que aparezcan más adelante en la lista anulen etiquetas en los manifiestos que aparecen antes en la lista, siempre que las etiquetas de la tienen el atributo override="true". Por ejemplo, el manifiesto ODM puede anular algunas etiquetas <hal> del manifiesto del proveedor Consulta la documentación para el atributo override a continuación.

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

Este es un ejemplo de manifiesto del proveedor.

<?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>

Este es un ejemplo de manifiesto de ODM.

<?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>

El siguiente es un ejemplo de manifiesto de dispositivo en un paquete inalámbrico.

<?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 información detallada, consulta el Manifiesto del dispositivo. Desarrollo.

Manifiesto del framework

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

  • El manifiesto del sistema (proporcionado por Google) se genera manualmente. se encuentran en el árbol de fuentes de Android /system/libhidl/manifest.xml
  • El manifiesto del producto (proporcionado por el dispositivo) enumera las HALs que entregan los módulos instalados en el en cada partición de producto.
  • El manifiesto system_ext (proporcionado por el dispositivo) enumera lo siguiente:
    • HALs atendidas por módulos instalados en la partición system_ext
    • Versiones de VNDK;
    • Versión del SDK del sistema.

De manera similar al manifiesto del dispositivo, se pueden usar varios archivos de fragmentos. Para obtener más información, consulta Fragmentos del manifiesto.

Este es un ejemplo de manifiesto de un framework.

<?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 del manifiesto

En Android 10 y versiones posteriores, puedes asociar un manifiesto HAL con un módulo de HAL en el sistema de compilación. Esto hace que sea más fácil incluir condicionalmente el módulo HAL en el sistema de compilación.

Ejemplo

En el archivo Android.bp o Android.mk, agrega vintf_fragments a cualquier módulo. Por ejemplo, puedes modificar el módulo con la implementación de tu 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, crea el manifiesto para más adelante en este módulo. Durante el tiempo de compilación, este manifiesto se agrega al dispositivo. Agregando aquí una entrada es lo mismo que agregar una entrada en el manifiesto principal del dispositivo. Esto permite que los clientes usen la interfaz y que el VTS identifique qué HAL implementaciones están en el dispositivo. Todo lo que un manifiesto normal hace, este manifiesto también hace.

En el siguiente ejemplo, se implementa android.hardware.foo@1.0::IFoo/default, que se instala en la partición vendor o odm. Si se instala en el Partición system, product o system_ext, usa el tipo framework en lugar de escribe 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>

Si un módulo de HAL se empaqueta en un APEX de proveedor, empaquetar sus fragmentos de VINTF asociados dentro del mismo APEX con prebuilt_etc como se explica en fragmentos de VINTF.

Esquema del archivo de manifiesto

En esta sección, se describe el significado de estas etiquetas XML. Algunos son “obligatorios” etiquetas pueden faltar del archivo fuente en el árbol de fuentes de Android y escribirse assemble_vintf al momento de la compilación. Las etiquetas obligatorias deben estar presentes en los archivos correspondientes del dispositivo.

?xml
Opcional. Solo proporciona información al analizador de XML.
manifest.version
Obligatorio. Metaversión de este manifiesto. Describe elementos esperados en el manifiesto. No está relacionado con la versión XML.
manifest.type
Obligatorio. Es el tipo de este manifiesto. Tiene el valor device para el archivo de manifiesto del dispositivo y framework para el manifiesto del framework .
manifest.target-level
Obligatorio para el manifiesto del dispositivo. Especifica la matriz de compatibilidad del framework Versión (FCM) de la que este dispositivo es compatible con el manifiesto tus amigos. Esto también se denomina versión de FCM de envío del dispositivo.
manifest.hal
Opcional; se puede repetir. Una sola HAL (HIDL o nativa, como GL) según el atributo format.
manifest.hal.format
Opcional. El valor puede ser uno de los siguientes:
  • hidl: HAL de HIDL Es el valor predeterminado.
  • aidl: HAL de AIDL. Solo es válido en la meta-versión 2.0 del manifiesto y versiones posteriores.
  • native: HAL nativas
manifest.hal.max-level
Opcional. Solo es válida en los manifiestos de framework. Si se establece, las HALs con un nivel máximo inferior que la versión de destino de FCM del manifiesto del framework están inhabilitadas.
manifest.hal.override
Opcional. El valor puede ser uno de los siguientes:
  • true: Anula otros elementos <hal> con la misma <name> y la misma versión principal. Si la respuesta es no <version> o <fqname> están en esta elemento <hal> y, luego, el elemento <hal> declara que esta HAL está inhabilitada.
  • false: No anula otros elementos <hal>. con el mismo <name> y la misma versión principal.
manifest.hal.name
Obligatorio. Es el nombre del paquete completamente calificado de la HAL. Varias entradas de HAL pueden usar con el mismo nombre. Ejemplos:
  • android.hardware.camera (HIDL o HAL del AIDL)
  • GLES (HAL nativa; solo requiere nombre)
manifest.hal.transport
Obligatorio cuando manifest.hal.format == "hidl". NO debe ser presente de otro modo. Indica qué transporte se utiliza cuando una interfaz desde este paquete se consulta desde el administrador de servicios. El valor puede ser uno de los siguientes:
  • hwbinder: Modo vinculado
  • passthrough: Modo de transferencia
Opcional cuando manifest.hal.format == "aidl". NO debe ser presente de otro modo. Indica qué transporte se usa cuando se entrega una interfaz. de forma remota. El valor debe ser el siguiente:
  • inet: Enchufe Inet
manifest.hal.transport.ip y manifest.hal.transport.port debe usarse para especificar con más detalle la información de conexión de Inet.
manifest.hal.transport.arch
Obligatorio para passthrough y no debe estar presente en hwbinder Describe la cantidad de bits del servicio de transferencia que se está utilizando. que se proporcionan. El valor puede ser uno de los siguientes:
  • 32: Modo de 32 bits
  • 64: Modo de 64 bits
  • 32+64: Ambas
manifest.hal.transport.ip
Obligatorio para inet y NO debe estar presente de otra manera. Describe la dirección IP desde la cual se entrega la interfaz remota.
manifest.hal.transport.port
Obligatorio para inet y NO debe estar presente de otra manera. Describe el puerto de la que se entrega la interfaz remota.
manifest.hal.version
Opcional; se puede repetir. Una versión para las etiquetas hal en un .

Para HIDL y HALs nativas, el formato es el siguiente: MAJOR.MINOR Para ejemplos, consulta hardware/interfaces vendor/${VENDOR}/interfaces, frameworks/hardware/interfaces o system/hardware/interfaces

El HIDL y las HAL nativas pueden usar varios campos de versión siempre que representen versiones principales distintas, con solo una versión secundaria por principal versión proporcionada. 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 que tengan el mismo nombre, a menos que override="true" Los valores de <version> no son asociado con <fqname> porque un <fqname> que lleva una versión.

Para las HAL del AIDL, <version> no debe estar presente en los dispositivos que se ejecutan Android 11 o versiones anteriores <version> debe ser un número entero único en dispositivos que ejecutan Android 12 y versiones posteriores. Debe haber, como máximo, un <version> para cada Tupla (package, interface, instance). Si no está presente, se establece de forma predeterminada como 1 El valor de <version> se asocia con todos <fqname> en el mismo <hal> porque Un objeto <fqname> no tiene una versión.
manifest.hal.interface
Obligatorio, se puede repetir sin duplicados. Indica una interfaz en el que tiene un nombre de instancia. Puede haber varios elementos <interface> en una <hal>; nombres deben ser distintos.
manifest.hal.interface.name
Obligatorio. Nombre de la interfaz.
manifest.hal.interface.instance
Obligatorio; se puede repetir. Nombre de instancia de la interfaz. Puede tener varios para una interfaz, pero no hay <instance> duplicados elementos.
manifest.hal.fqname
Opcional; se puede repetir. Una forma alternativa de especificar una instancia para la HAL con el nombre manifest.hal.name.
  • Para las HAL de HIDL, el formato es el siguiente @MAJOR.MINOR::INTERFACE/INSTANCE
  • Para las HAL del AIDL, el formato es el siguiente INTERFACE/INSTANCE
manifest.sepolicy
Obligatorio. Contiene todas las entradas relacionadas con la política.
manifest.sepolicy.version
Obligatorio para el manifiesto del dispositivo. Declara la versión de SELinux. Cuenta con formato SDK_INT.PLAT_INT.
manifest.vendor-ndk
Obligatorio, se puede repetir. necesarios para el manifiesto del framework. No debe estar presente. en el manifiesto del dispositivo. Varias entradas <vendor-ndk> deben tener diferentes <version>. Describe un conjunto de instantáneas del VNDK que proporciona el framework.
manifest.vendor-ndk.version
Obligatorio. Es un número entero positivo que representa la versión de VNDK. instantánea.
manifest.vendor-ndk.library
Opcional, se puede repetir, sin duplicados. Describe un conjunto de bibliotecas de VNDK que proporciona el framework para esta instantánea del proveedor del VNDK. El valor es la nombre de archivo de una biblioteca, p.ej., libjpeg.so, incluido el prefijo lib y el sufijo .so No hay componentes de ruta de acceso permitido.
manifest.system-sdk.version
Opcional, se puede repetir, sin duplicados. que solo usa el framework . Describe un conjunto de versiones del SDK del sistema que proporciona el framework para aplicaciones de proveedores de servicios en la nube.
manifest.kernel
Opcional. Describe la información estática sobre el kernel.
manifest.kernel.target-level
Opcional. Describe la rama de kernel. Su valor predeterminado es Es manifest.target-level si no está presente. Debe ser superior a o igual a manifest.target-level. Consulta reglas de coincidencia del kernel para conocer los detalles.