Um objeto VINTF agrega dados do manifesto do dispositivo e arquivos de manifesto da estrutura (XML). Ambos os manifestos compartilham um formato, embora nem todos os elementos se apliquem a ambos (para obter detalhes sobre o esquema, consulte Esquema do arquivo de manifesto ).
Manifesto do dispositivo
O manifesto do dispositivo (fornecido pelo dispositivo) consiste no manifesto do fornecedor e no manifesto ODM.
- O manifesto do fornecedor especifica HALs, versões de política SELinux, etc. comuns a um SoC. Recomenda-se a ser colocado na árvore fonte do Android em
device/ VENDOR / DEVICE /manifest.xml
, mas vários arquivos de fragmento pode ser usado. Para obter detalhes, consulte fragmentos de manifesto e Gerar DM a partir de fragmentos . - O manifesto ODM lista HALs específicos para o produto na partição ODM . O objeto VINTF carrega o manifesto ODM nesta ordem:
- Se
SKU
for definido (em queSKU
é o valor da propriedadero.boot.product.hardware.sku
),/odm/etc/vintf/manifest_ SKU .xml
-
/odm/etc/vintf/manifest.xml
- Se
SKU
for definido,/odm/etc/manifest_ SKU .xml
-
/odm/etc/manifest.xml
- Se
- O manifesto do fornecedor lista HALs específicos para o produto na partição do fornecedor. O objeto VINTF carrega o manifesto do fornecedor nesta ordem:
- Se
SKU
for definido (em queSKU
é o valor da propriedadero.boot.product.vendor.sku
),/vendor/etc/vintf/manifest_ SKU .xml
-
/vendor/etc/vintf/manifest.xml
- Se
- O objeto VINTF carrega o manifesto do dispositivo nesta ordem:
- Se o manifesto do fornecedor existir, combine o seguinte:
- O manifesto do fornecedor
- Fragmentos opcionais de manifesto do fornecedor
- Manifesto ODM opcional
- Fragmentos de manifesto ODM opcionais
- Caso contrário, se o manifesto ODM existir, combine o manifesto ODM com os fragmentos opcionais do manifesto ODM.
-
/vendor/manifest.xml
(legado, sem fragmentos)
Observe que:
- Em dispositivos legados, o manifesto do fornecedor legado e o manifesto ODM são usados. O manifesto ODM pode substituir completamente o manifesto do fornecedor legado.
- Em dispositivos iniciados com o Android 9, o manifesto ODM é combinado com o manifesto do fornecedor.
- Ao combinar uma lista de manifestos, os manifestos que aparecem posteriormente na lista podem substituir as tags nos manifestos que aparecem anteriormente na lista, desde que as tags no manifesto posterior tenham o atributo
override="true"
. Por exemplo, o manifesto ODM pode substituir algumas marcas<hal>
do manifesto do fornecedor. Consulte a documentação paraoverride
atributos abaixo.
- Se o manifesto do fornecedor existir, combine o seguinte:
Essa configuração permite que vários produtos com a mesma placa compartilhem a mesma imagem do fornecedor (que fornece HALs comuns), embora tenham imagens ODM diferentes (que especificam HALs específicos do produto).
Aqui está um exemplo de manifesto do fornecedor.
<?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>
Aqui está um exemplo de manifesto 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>
Aqui está um exemplo de manifesto de dispositivo em um pacote 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 obter mais detalhes, consulte Device Manifest Development .
Manifesto da estrutura
O arquivo de manifesto da estrutura consiste no manifesto do sistema, no manifesto do produto e no manifesto system_ext.
- O manifesto do sistema (fornecido pelo Google) é gerado manualmente e reside na árvore de origem do Android em
/system/libhidl/manifest.xml
. - O manifesto do produto (fornecido pelo dispositivo) lista HALs atendidos por módulos instalados na partição do produto.
- O manifesto system_ext (fornecido pelo dispositivo) lista o seguinte:
- HALs atendidos por módulos instalados na partição system_ext;
- Versões VNDK;
- Versão do SDK do sistema.
Semelhante ao manifesto do dispositivo, vários arquivos de fragmento podem ser usados. Para obter detalhes, consulte Fragmentos de manifesto .
Aqui está um exemplo de manifesto do 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> <vendor-ndk> <version>27</version> </vendor-ndk> <system-sdk> <version>27</version> </system-sdk> </manifest>
Fragmentos de manifesto
No Android 10 e superior, você pode associar uma entrada de manifesto a um módulo HAL no sistema de compilação. Isso torna mais fácil incluir condicionalmente o módulo HAL no sistema de compilação.
Exemplo
Em sua Android.bp
ou Android.mk
arquivo, adicione vintf_fragments
a qualquer módulo. Por exemplo, você pode modificar o módulo com a implementação de seu HAL ( my.package.foo@1.0-service-bar
).
... { ... vintf_fragments: ["manifest_foo.xml"], ... }
LOCAL_MODULE := ... LOCAL_VINTF_FRAGMENTS := manifest_foo.xml
Em um arquivo chamado manifest_foo.xml
, crie o manifesto para este módulo. No momento da construção, este manifesto é adicionado ao dispositivo. Adicionar uma entrada aqui é o mesmo que adicionar uma entrada no manifesto principal do dispositivo. Isso permite que os clientes usem a interface e permite que o VTS identifique quais implementações HAL estão no dispositivo. Tudo o que um manifesto regular faz, este manifesto também faz.
O exemplo abaixo implementa android.hardware.foo@1.0::IFoo/default
, que é instalado no vendor
ou partição odm
. Se estiver instalado no system
, product
ou partição system_ext
, use o tipo de framework
vez do tipo de 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 arquivo de manifesto
Esta seção descreve o significado dessas tags XML. Algumas tags "obrigatórias" podem estar faltando no arquivo de origem na árvore de origem do Android e escritas por assemble_vintf
no momento da construção. As tags necessárias devem estar presentes nos arquivos correspondentes no dispositivo.
-
?xml
- Opcional. Fornece apenas informações para o analisador XML.
-
manifest.version
- Requeridos. Meta-versão deste manifesto. Descreve os elementos esperados no manifesto. Não relacionado à versão XML.
-
manifest.type
- Requeridos. Tipo deste manifesto. Ele tem o valor
device
para o arquivo de manifesto do dispositivo e aframework
para o arquivo de manifesto da estrutura. -
manifest.target-level
- Obrigatório para o manifesto do dispositivo. Especifica a versão da matriz de compatibilidade da estrutura (FCM) com a qual este manifesto do dispositivo se destina a ser compatível. Isso também é chamado de versão FCM de envio do dispositivo.
-
manifest.hal
- Opcional, pode repetir. Um único HAL (HIDL ou nativo, como GL), dependendo do atributo de
format
. -
manifest.hal.format
- Opcional. O valor pode ser um dos seguintes:
-
hidl
: HIDL HALs. Este é o padrão. -
aidl
: AIDL HALs . Válido apenas na meta-versão 2.0 e superior do manifesto. -
native
: HALs nativos.
-
-
manifest.hal.override
- Opcional. O valor pode ser um dos seguintes:
-
true
: substitui outros elementos<hal>
pelo mesmo<name>
e versão principal. Se nenhum<version>
ou<fqname>
estiver neste elemento<hal>
, o elemento<hal>
declara que este HAL está desativado. -
false
: Não sobrescreve outros elementos<hal>
com o mesmo<name>
e versão principal.
-
-
manifest.hal.name
- Requeridos. Nome do pacote totalmente qualificado do HAL. Várias entradas HAL podem usar o mesmo nome. Exemplos:
-
android.hardware.camera
(HIDL ou AIDL HAL) -
GLES
(HAL nativo, requer apenas nome)
-
-
manifest.hal.transport
- Obrigatório quando
manifest.hal.format == "hidl"
. NÃO deve estar presente de outra forma. Indica qual transporte é usado quando uma interface deste pacote é consultada no gerenciador de serviço. O valor pode ser um dos seguintes:-
hwbinder
: modo Binderized -
passthrough
: modo Passthrough
-
-
manifest.hal.transport.arch
- Obrigatório para
passthrough
e não deve estar presente parahwbinder
. Descreve a quantidade de bits do serviço de passagem que está sendo fornecido. O valor pode ser um dos seguintes:- Modo
32
: 32 bits -
64
: modo de 64 bits -
32+64
: ambos
- Modo
-
manifest.hal.version
- Opcional, pode repetir. Uma versão para as tags
hal
em um manifesto.
Para HIDL e HALs nativos, o formato éMAJOR . MINOR
. Para obter exemplos, consultehardware/interfaces
,vendor/${VENDOR}/interfaces
,framework/hardware/interfaces
ousystem/hardware/interfaces
.
HIDL e HALs nativos podem usar vários campos de versão, desde que representem versões principais distintas , com apenas uma versão secundária por versão principal fornecida. Por exemplo, 3.1 e 3.2 não podem coexistir, mas 1.0 e 3.4 podem. Isso se aplica a todos os elementoshal
com o mesmo nome, a menos queoverride="true"
. Os valores de<version>
não estão associados a<fqname>
porque um<fqname>
carrega uma versão.
Para AIDL HALs,<version>
não deve estar presente em dispositivos que executam o Android 11 e inferior.<version>
deve ser um único número inteiro em dispositivos que executam Android S (AOSP experimental) e superior. Deve haver no máximo uma<version>
para cada tupla(package, interface, instance)
. Se não estiver presente, o padrão é1
. O valor de<version>
está associado a todos os<fqname>
no mesmo<hal>
porque um<fqname>
não carrega uma versão. -
manifest.hal.interface
- Obrigatório, pode repetir sem duplicatas. Indique uma interface no pacote que tenha um nome de instância. Pode haver vários elementos
<interface>
em um<hal>
; os nomes devem ser distintos. -
manifest.hal.interface.name
- Requeridos. Nome da interface.
-
manifest.hal.interface.instance
- Obrigatório, pode repetir. Nome da instância da interface. Pode ter várias instâncias para uma interface, mas nenhum elemento
<instance>
duplicado. -
manifest.hal.fqname
- Opcional, pode repetir. Uma maneira alternativa de especificar uma instância para o HAL com o nome
manifest.hal.name
.- Para HIDL HALs, o formato é
@ MAJOR . MINOR :: INTERFACE / INSTANCE
. - Para AIDL HALs, o formato é
INTERFACE / INSTANCE
.
- Para HIDL HALs, o formato é
-
manifest.sepolicy
- Requeridos. Contém todas as entradas relacionadas à sepolicy.
-
manifest.sepolicy.version
- Obrigatório para o manifesto do dispositivo. Declara a versão SELinux. Possui o formato
SDK_INT . PLAT_INT
. -
manifest.vendor-ndk
- Obrigatório, pode repetir; necessário para o manifesto da estrutura. Não deve estar presente no manifesto do dispositivo. Várias entradas de
<vendor-ndk>
devem ter<version>
s diferentes. Descreve um conjunto de instantâneos VNDK fornecidos pela estrutura. -
manifest.vendor-ndk.version
- Requeridos. Este é um número inteiro positivo que representa a versão do instantâneo VNDK.
-
manifest.vendor-ndk.library
- Opcional, pode repetir, sem duplicatas. Descreve um conjunto de bibliotecas VNDK fornecidas pela estrutura para este instantâneo do fornecedor VNDK. O valor é o nome do arquivo de uma biblioteca, por exemplo,
libjpeg.so
, incluindo o prefixolib
e o sufixo.so
. Nenhum componente de caminho é permitido. -
manifest.system-sdk.version
- Opcional, pode repetir, sem duplicatas; usado apenas pelo manifesto do framework. Descreve um conjunto de versões do SDK do sistema fornecidas pela estrutura para aplicativos de fornecedores.
-
manifest.kernel
- Opcional. Descreve informações estáticas sobre o kernel.
-
manifest.kernel.target-level
- Opcional. Descreve o branch do kernel. O valor padrão é
manifest.target-level
se não estiver presente. Deve ser maior ou igual amanifest.target-level
. Consulte as regras de correspondência do kernel para obter detalhes.