Un objeto VINTF agrega datos de archivos de manifiesto de dispositivo y de 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 del manifiesto 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 ODM enumera los HAL específicos del producto en la partición ODM . El objeto VINTF carga el manifiesto ODM en este orden:
- Si se define
SKU
(dondeSKU
es el valor de la propiedadro.boot.product.hardware.sku
),/odm/etc/vintf/manifest_ SKU .xml
-
/odm/etc/vintf/manifest.xml
- Si se define
SKU
,/odm/etc/manifest_ SKU .xml
-
/odm/etc/manifest.xml
- Si se define
- El manifiesto del proveedor enumera HAL específicos del producto en la partición del proveedor. El objeto VINTF carga el manifiesto del proveedor en este orden:
- Si se define
SKU
(dondeSKU
es el valor de la propiedadro.boot.product.vendor.sku
),/vendor/etc/vintf/manifest_ SKU .xml
-
/vendor/etc/vintf/manifest.xml
- Si se define
- El objeto VINTF carga el manifiesto del dispositivo en este orden:
- Si el manifiesto del proveedor existe, combine lo siguiente:
- El manifiesto del proveedor.
- Fragmentos de manifiesto de proveedor opcionales
- Manifiesto ODM opcional
- Fragmentos de manifiesto ODM opcionales
- De lo contrario, si el manifiesto ODM existe, combine el manifiesto ODM con los fragmentos del manifiesto ODM opcionales.
-
/vendor/manifest.xml
(heredado, sin fragmentos)
Tenga en cuenta que:
- En 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 dispositivos lanzados con Android 9, el manifiesto 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 de los manifiestos que aparecen antes en la lista, siempre que las etiquetas del manifiesto posterior tengan el atributo
override="true"
. Por ejemplo, el manifiesto ODM puede anular algunas etiquetas<hal>
del manifiesto del proveedor. Consulte la documentación paraoverride
de atributos a continuación.
- Si el manifiesto del proveedor existe, combine lo siguiente:
Esta configuración permite que varios productos con la misma placa compartan la misma imagen del proveedor (que proporciona HAL comunes) pero tengan diferentes imágenes ODM (que especifican HAL específicos del producto).
Aquí hay un ejemplo de manifiesto de 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>
A continuación se muestra un ejemplo de manifiesto 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>
A continuación se muestra un ejemplo de manifiesto de dispositivo 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 manifiesto de dispositivo .
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 código fuente de Android en
/system/libhidl/manifest.xml
. - El manifiesto del producto (proporcionado por el dispositivo) enumera los HAL atendidos 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 .
A continuación se muestra un manifiesto de marco 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, puedes 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 a los clientes utilizar la interfaz y permite que VTS identifique qué implementaciones HAL están en el dispositivo. Todo lo que hace un manifiesto normal, este manifiesto también lo hace.
El siguiente ejemplo implementa android.hardware.foo@1.0::IFoo/default
, que se instala en la partición vendor
o odm
. Si está instalado en la partición system
, product
o system_ext
, use el tipo framework
en lugar del tipo 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 HAL está empaquetado en un APEX de proveedor , empaquete sus fragmentos VINTF asociados dentro del mismo APEX con `prebuilt_etc` como se explica en Fragmentos VINTF .
Esquema de archivo de manifiesto
Esta sección describe el significado de estas etiquetas XML. Es posible que falten algunas etiquetas "requeridas" en el archivo fuente en el árbol de fuentes de Android y que se escriban mediante assemble_vintf
en el momento de la compilación. Las etiquetas requeridas deben estar presentes en los archivos correspondientes del dispositivo.
-
?xml
- Opcional. Sólo proporciona información al analizador XML.
-
manifest.version
- Requerido. Metaversió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 valor
device
para el archivo de manifiesto del dispositivo yframework
para el archivo de manifiesto del marco. -
manifest.target-level
- Requerido para el manifiesto del dispositivo. Especifica la versión de la matriz de compatibilidad del marco (FCM) con la que este manifiesto de dispositivo debe ser compatible. Esto también se denomina versión FCM de envío del dispositivo.
-
manifest.hal
- Opcional, se puede repetir. Un único HAL (HIDL o nativo, como GL), según el atributo
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 la metaversión 2.0 y superior del manifiesto. -
native
: HAL nativos.
-
-
manifest.hal.max-level
- Opcional. Solo es válido en manifiestos de marco. Si se establece, se deshabilitan los HAL con un nivel máximo inferior a la versión de destino de FCM 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 este HAL está deshabilitado. -
false
: no anule otros elementos<hal>
con el mismo<name>
y versión principal.
-
-
manifest.hal.name
- Requerido. Nombre de paquete completo de HAL. Varias entradas HAL pueden utilizar 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"
. De lo contrario NO debe estar presente. Indica qué transporte se utiliza cuando el administrador de servicios consulta una interfaz de este paquete. El valor puede ser uno de:-
hwbinder
: modo enlazado -
passthrough
: modo de paso a través
-
- Opcional cuando
manifest.hal.format == "aidl"
. De lo contrario NO debe estar presente. Indica qué transporte se utiliza cuando una interfaz se sirve de forma remota. El valor debe ser:-
inet
: toma Inet
manifest.hal.transport.ip
ymanifest.hal.transport.port
para especificar aún más la información de conexión Inet. -
-
manifest.hal.transport.arch
- Requerido para
passthrough
y no debe estar presente parahwbinder
. Describe el bitness 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 en otros casos. Describe la dirección IP desde la que se presta servicio a la interfaz remota. -
manifest.hal.transport.port
- Requerido para
inet
y NO debe estar presente en otros casos. Describe el puerto desde el que se presta servicio a la interfaz remota. -
manifest.hal.version
- Opcional, se puede repetir. Una versión para las etiquetas
hal
en un manifiesto.
Para HIDL y HAL nativo, el formato esMAJOR . MINOR
. Para ver ejemplos, consultehardware/interfaces
,vendor/${VENDOR}/interfaces
,frameworks/hardware/interfaces
osystem/hardware/interfaces
.
HIDL y HAL nativos pueden usar múltiples campos de versión siempre que representen versiones principales distintas , con solo una versión secundaria proporcionada por cada 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 elementoshal
con el mismo nombre, a menos queoverride="true"
. Los valores de<version>
no están asociados con<fqname>
porque un<fqname>
lleva una versión.
Para AIDL HAL,<version>
no debe estar presente en dispositivos con Android 11 y versiones anteriores.<version>
debe ser un número 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 es1
. El valor de<version>
está asociado con todos<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
- Requerido, 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 HIDL HAL, el formato es
@ MAJOR . MINOR :: INTERFACE / INSTANCE
. - Para AIDL HAL, el formato es
INTERFACE / INSTANCE
.
- Para HIDL HAL, el formato es
-
manifest.sepolicy
- Requerido. Contiene todas las entradas relacionadas con la política de seguridad.
-
manifest.sepolicy.version
- Requerido para el manifiesto del dispositivo. Declara la versión de SELinux. Tiene el formato
SDK_INT . PLAT_INT
. -
manifest.vendor-ndk
- Requerido, puede repetirse; requerido para el manifiesto del marco. No debe estar presente en el manifiesto del dispositivo. Varias entradas
<vendor-ndk>
deben tener diferentes<version>
. 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 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 prefijolib
y el sufijo.so
. No se permiten componentes de ruta. -
manifest.system-sdk.version
- Opcional, se puede repetir, sin duplicados; utilizado sólo por el manifiesto del marco. Describe un conjunto de versiones de SDK del sistema proporcionadas por el marco a las aplicaciones de proveedores.
-
manifest.kernel
- Opcional. Describe información estática sobre el kernel.
-
manifest.kernel.target-level
- Opcional. Describe la rama del kernel. Su valor predeterminado es
manifest.target-level
si no está presente. Debe ser mayor o igual quemanifest.target-level
. Consulte las reglas de coincidencia del kernel para obtener más detalles.