Manifestos

Um objeto VINTF agrega dados do device manifesto e manifesto de framework (XML). Ambos manifestos compartilham um formato, embora nem todos os elementos se apliquem a ambos (para obter detalhes no esquema, confira Esquema do arquivo de manifesto).

Manifesto do dispositivo

O manifesto do dispositivo (fornecido pelo dispositivo) consiste no manifesto do fornecedor e o manifesto do ODM.

• O manifesto do fornecedor especifica HALs, versões de políticas do SELinux e outros elementos comuns a um SoC. Ela é recomendado para ser colocado na árvore de origem do Android em device/VENDOR/DEVICE/manifest.xml, mas vários fragmentos podem ser usados. Para mais detalhes, consulte Fragmentos de manifesto e Gerar Mensagens diretas de fragmentos.
• O manifesto ODM lista as HALs específicas do produto na Partição do ODM. O objeto VINTF carrega o manifesto ODM nesta ordem:
  1. Se SKU estiver definido (em que SKU é o valor do da propriedade ro.boot.product.hardware.sku), /odm/etc/vintf/manifest_SKU.xml
  2. /odm/etc/vintf/manifest.xml
  3. Se SKU estiver definido, /odm/etc/manifest_SKU.xml
  4. /odm/etc/manifest.xml
• O manifesto do fornecedor lista as HALs específicas do produto na partição do fornecedor. O objeto VINTF carrega o manifesto do fornecedor nesta ordem:
  1. Se SKU estiver definido (em que SKU é o valor do da propriedade ro.boot.product.vendor.sku), /vendor/etc/vintf/manifest_SKU.xml
  2. /vendor/etc/vintf/manifest.xml
• O objeto VINTF carrega o manifesto do dispositivo nesta ordem:
  1. Se o manifesto do fornecedor existir, combine o seguinte:
     1. O manifesto do fornecedor
     2. Fragmentos de manifesto opcionais do fornecedor
     3. Manifesto do ODM opcional
     4. Fragmentos de manifesto do ODM opcionais
  2. Caso contrário, se houver um manifesto ODM, combine-o com o ODM opcional fragmentos de manifesto.
  3. /vendor/manifest.xml (legado, sem fragmentos)
  4. Por fim, combine fragmentos de manifesto de qualquer APEX do fornecedor.

  Algumas considerações:

  • Em dispositivos legados, o manifesto do fornecedor legado e o manifesto do ODM são usados. A O manifesto ODM pode substituir completamente o manifesto do fornecedor legado.
  • Em dispositivos lançados com o Android 9, o manifesto ODM é combinado com o manifesto do fornecedor.
  • Ao combinar uma lista de manifestos, aqueles que aparecerem mais tarde na lista podem substituir nos manifestos que aparecem mais cedo na lista, desde que as tags nas próximas manifesto têm o atributo override="true". Por exemplo, o manifesto do ODM pode substitua algumas tags <hal> do manifesto do fornecedor. Consulte a documentação atributo override abaixo.

Essa configuração permite que vários produtos com o mesmo board compartilhem os mesmos itens do fornecedor (que fornece HALs comuns), mas têm imagens ODM diferentes (que especificar HALs específicas do produto).

Veja um exemplo de manifesto de 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>

Veja 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 mais detalhes, consulte Manifesto do dispositivo Desenvolvimento.

Manifesto do framework

O arquivo de manifesto da estrutura consiste no manifesto do sistema, no manifesto do produto e no 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 as HALs atendidas pelos módulos instalados no partição do produto.
• O manifesto system_ext (fornecido pelo dispositivo) lista o seguinte:
  • HALs atendidas por módulos instalados na partição system_ext;
  • Versões do VNDK.
  • Versão do SDK do sistema.

De forma semelhante ao manifesto do dispositivo, é possível usar vários arquivos de fragmento. Para mais detalhes, consulte Fragmentos de manifesto.

Aqui está um exemplo de manifesto de 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 de manifesto

No Android 10 e versões mais recentes, é possível associar um manifesto com um módulo HAL no sistema de build. Assim, fica mais fácil incluir condicionalmente o módulo HAL no sistema de compilação.

Exemplo

No seu arquivo Android.bp ou Android.mk, adicione vintf_fragments a qualquer módulo. Por exemplo, é possível modificar módulo com a implementação da 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 neste módulo. No tempo de build, esse manifesto é adicionado ao dispositivo. Adicionando uma entrada aqui é o mesmo que adicionar uma entrada no manifesto principal do dispositivo. Isso permite que os clientes usem a interface e que o VTS identifique qual HAL e implementações estão no dispositivo. Qualquer coisa que um manifesto normal faz, esse manifesto também faz.

O exemplo abaixo implementa android.hardware.foo@1.0::IFoo/default, que é instalado vendor ou odm. Se ele estiver instalado system, product ou system_ext, use o tipo framework em vez de digite 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>

Se um módulo HAL estiver em um APEX do fornecedor, empacotar seus fragmentos VINTF associados no mesmo APEX com prebuilt_etc como explicado em fragmentos VINTF.

Esquema do arquivo de manifesto

Esta seção descreve o significado dessas tags XML. Alguma informação "obrigatória" tags pode estar ausente no arquivo de origem na árvore de origem do Android e gravados por assemble_vintf no momento da criação. Tags obrigatórias devem estar presentes nos arquivos correspondentes na dispositivo.

?xml

Opcional. Fornece informações apenas para o analisador XML.

manifest.version

Obrigatório. Metaversão deste manifesto. Descreve elementos esperados no manifesto. Não tem relação com a versão do XML.

manifest.type

Obrigatório. Tipo deste manifesto. Tem o valor device para no arquivo de manifesto do dispositivo e framework para o manifesto do framework. .

manifest.target-level

Obrigatório para o manifesto do dispositivo. Especifica a matriz de compatibilidade do framework A versão do (FCM) a que o manifesto do dispositivo é segmentado para ser compatível com Ela também é chamada de versão de envio do FCM do dispositivo.

manifest.hal

Opcional, pode repetir. Uma única HAL (HIDL ou nativa, como GL) dependendo do atributo format.

manifest.hal.format

Opcional. O valor pode ser um dos seguintes:

• hidl: HALs HIDL. Esse é o padrão.
• aidl: HALs da AIDL. Válido somente no manifesto metaversão 2.0 e superior.
• native: HALs nativas.

manifest.hal.max-level

Opcional. Válido apenas em manifestos de framework. Se definida, as HALs com nível máximo menor que a versão de destino do FCM no manifesto do framework sejam desativadas.

manifest.hal.override

Opcional. O valor pode ser um dos seguintes:

• true: substitui outros elementos <hal> por o mesmo <name> e a versão principal. Em caso negativo <version> ou <fqname> estão nesta elemento <hal>, o elemento <hal> declara que essa HAL está desativada.
• false: não substitua outros elementos <hal>. com a mesma <name> e versão principal.

manifest.hal.name

Obrigatório. Nome do pacote totalmente qualificado da HAL. Várias entradas da HAL podem usar com o mesmo nome. Exemplos:

• android.hardware.camera (HAL de HIDL ou AIDL)
• GLES (HAL nativa, requer apenas o nome)

manifest.hal.transport

Obrigatório quando manifest.hal.format == "hidl". NÃO pode ser presentes de outra forma. Define qual transporte é usado quando uma interface de este pacote é consultado com o gerenciador de serviço. O valor pode ser um dos seguintes:

• hwbinder: modo Binderized
• passthrough: modo de passagem

.

Opcional quando manifest.hal.format == "aidl". NÃO pode ser presentes de outra forma. Informa qual transporte é usado quando uma interface é disponibilizada remotamente. O valor precisa ser:

• inet: soquete Inet

. O manifest.hal.transport.ip e o manifest.hal.transport.port deve ser usado para especificar melhor as informações de conexão Inet.

manifest.hal.transport.arch

Obrigatório para passthrough e não deve estar presente para hwbinder Descreve a quantidade de bits do serviço de passagem fornecidas. O valor pode ser um dos seguintes:

• 32: modo de 32 bits
• 64: modo de 64 bits
• 32+64: ambas

manifest.hal.transport.ip

Obrigatório para inet e NÃO poderá estar presente de outra forma. Descreve o endereço IP do qual a interface remota é exibida.

manifest.hal.transport.port

Obrigatório para inet e NÃO poderá estar presente de outra forma. Descreve a porta de qual a interface remota é exibida.

manifest.hal.version

Opcional, pode repetir. Uma versão para as tags hal em um manifesto do aplicativo.

Para HIDL e HALs nativas, o formato é MAJOR.MINOR. Para exemplos, consulte hardware/interfaces, vendor/${VENDOR}/interfaces, frameworks/hardware/interfaces ou system/hardware/interfaces.

O HIDL e as HALs nativas podem usar vários campos de versão, desde que representem versões principais distintas, com apenas uma versão secundária por maior versão 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 elementos hal com o mesmo nome, a menos que override="true". Os valores de <version> não são associado a <fqname> porque um <fqname> carrega uma versão.

Para HALs da AIDL, <version> não pode estar presente em dispositivos em execução Android 11 e versões anteriores <version> precisa ser um Número inteiro único em dispositivos com o Android 12 e versões mais recentes. É necessário que haja no máximo um <version> para cada Tupla (package, interface, instance). Se ausente, 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 ser repetido sem duplicatas. Indicar uma interface no que tem um nome de instância. Pode haver várias Elementos <interface> em uma <hal>. nomes precisam ser distintos.

manifest.hal.interface.name

Obrigatório. Nome da interface.

manifest.hal.interface.instance

Obrigatório, pode ser repetido. Nome da instância da interface. Pode ter vários instâncias para uma interface, mas nenhuma <instance> duplicada elementos.

manifest.hal.fqname

Opcional, pode repetir. Uma forma alternativa de especificar uma instância para a HAL com o nome manifest.hal.name.

• Para HALs HIDL, o formato é @MAJOR.MINOR::INTERFACE/INSTANCE:
• Para HALs da AIDL, o formato é INTERFACE/INSTANCE:

manifest.sepolicy

Obrigatório. Contém todas as entradas relacionadas a sepolicy.

manifest.sepolicy.version

Obrigatório para o manifesto do dispositivo. Declara a versão do SELinux. Ele tem o formato SDK_INT.PLAT_INT.

manifest.vendor-ndk

Obrigatório, pode ser repetido para o manifesto do framework. Não pode estar presente no manifesto do dispositivo. Várias entradas <vendor-ndk> precisam ter <version>s diferentes. Descreve um conjunto de snapshots do VNDK oferecidos pelo framework.

manifest.vendor-ndk.version

Obrigatório. É um número inteiro positivo que representa a versão do VNDK snapshot.

manifest.vendor-ndk.library

Opcional, pode repetir, sem duplicatas. Descreve um conjunto de bibliotecas VNDK fornecidos pelo framework para esse snapshot do fornecedor de VNDK. O valor é nome do arquivo de uma biblioteca, por exemplo, libjpeg.so, incluindo o prefixo lib e o sufixo .so. Nenhum componente de caminho está permitido.

manifest.system-sdk.version

Opcional, pode repetir, sem duplicatas; usadas apenas pelo framework manifesto do aplicativo. Descreve um conjunto de versões de SDK do sistema fornecidas pelo framework para apps de fornecedores.

manifest.kernel

Opcional. Descreve informações estáticas sobre o kernel.

manifest.kernel.target-level

Opcional. Descreve a ramificação do kernel. O valor padrão é manifest.target-level se ausente. Precisa ser maior que ou igual a manifest.target-level. Consulte Regras de correspondência do kernel para mais detalhes.