Manifestos

Um objeto VINTF agrega dados de manifesto de dispositivo e arquivos de manifesto de 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 do ODM.

  • O manifesto do fornecedor especifica HALs, versões de políticas SELinux, etc. comuns a um SoC. Recomenda-se que seja colocado na árvore de origem do Android em device/ VENDOR / DEVICE /manifest.xml , mas vários arquivos de fragmentos podem ser usados. Para obter detalhes, consulte Fragmentos de manifesto e Gerar DM a partir de fragmentos .
  • O manifesto do ODM lista HALs específicos do produto na partição ODM . O objeto VINTF carrega o manifesto ODM nesta ordem:
    1. Se SKU for definido (onde SKU é o valor 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 HALs específicos do produto na partição do fornecedor. O objeto VINTF carrega o manifesto do fornecedor nesta ordem:
    1. Se SKU estiver definido (onde SKU é o valor 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 opcionais de manifesto do fornecedor
      3. Manifesto ODM opcional
      4. Fragmentos de manifesto ODM opcionais
    2. Caso contrário, se o manifesto ODM existir, combine o manifesto ODM com os fragmentos opcionais do manifesto ODM.
    3. /vendor/manifest.xml (legado, sem fragmentos)

    Observe que:

    • Em dispositivos legados, são usados ​​o manifesto do fornecedor legado e o manifesto ODM. O manifesto do ODM pode substituir completamente o manifesto do fornecedor legado.
    • Em dispositivos lançados com Android 9, o manifesto do ODM é combinado com o manifesto do fornecedor.
    • Ao combinar uma lista de manifestos, os manifestos que aparecem posteriormente na lista podem substituir tags em 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 tags <hal> do manifesto do fornecedor. Consulte a documentação para override de atributos abaixo.

Essa configuração permite que vários produtos com a mesma placa compartilhem a mesma imagem de fornecedor (que fornece HALs comuns), mas 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 Desenvolvimento de manifesto de dispositivo .

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 fica 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 fragmentos podem ser usados. Para obter detalhes, consulte Fragmentos de manifesto .

Aqui está um exemplo de manifesto de estrutura.

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

No seu arquivo Android.bp ou Android.mk , adicione vintf_fragments a qualquer módulo. Por exemplo, você pode modificar o módulo com a implementação do 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 compilação, esse 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 na partição vendor ou odm . Se estiver instalado na partição system , product ou system_ext , use o tipo framework em vez do 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>

Se um módulo HAL for empacotado em um fornecedor APEX , empacote seus fragmentos VINTF associados dentro do mesmo APEX com `prebuilt_etc` conforme explicado em fragmentos VINTF .

Esquema do 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 compilação. As tags obrigatórias devem estar presentes nos arquivos correspondentes no dispositivo.

?xml
Opcional. Fornece informações apenas ao analisador XML.
manifest.version
Obrigatório. Meta-versão deste manifesto. Descreve os elementos esperados no manifesto. Não relacionado à versão XML.
manifest.type
Obrigatório. Tipo deste manifesto. Possui o valor device para o arquivo de manifesto do dispositivo e framework 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 de estrutura (FCM) com a qual este manifesto do dispositivo deve 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 format .
manifest.hal.format
Opcional. O valor pode ser um dos seguintes:
  • hidl : HALs HIDL. Este é o padrão.
  • aidl : HALs AIDL . Válido apenas na metaversão do manifesto 2.0 e superior.
  • native : HALs nativos.
manifest.hal.max-level
Opcional. Válido apenas em manifestos de estrutura. Se definido, os HALs com um nível máximo inferior à versão alvo do FCM no manifesto da estrutura serão desabilitados.
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> , então o elemento <hal> declara este HAL como desabilitado.
  • false : Não substitua outros elementos <hal> pelo mesmo <name> e versão principal.
manifest.hal.name
Obrigatório. Nome de 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ços. O valor pode ser um dos seguintes:
  • hwbinder : modo binderizado
  • passthrough : modo de passagem
Opcional quando manifest.hal.format == "aidl" . NÃO deve estar presente de outra forma. Indica qual transporte é usado quando uma interface é atendida remotamente. O valor deve ser:
  • inet : soquete Inet
O manifest.hal.transport.ip e manifest.hal.transport.port devem ser usados ​​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 o número de bits do serviço de passagem que está sendo fornecido. O valor pode ser um dos seguintes:
  • 32 : modo de 32 bits
  • 64 : modo de 64 bits
  • 32+64 : Ambos
manifest.hal.transport.ip
Obrigatório para inet e NÃO deve estar presente de outra forma. Descreve o endereço IP do qual a interface remota está sendo atendida.
manifest.hal.transport.port
Obrigatório para inet e NÃO deve estar presente de outra forma. Descreve a porta da qual a interface remota está sendo atendida.
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 . Por exemplo, consulte hardware/interfaces , vendor/${VENDOR}/interfaces , frameworks/hardware/interfaces ou system/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 elementos hal com o mesmo nome, a menos que override="true" . Os valores de <version> não estão associados a <fqname> porque um <fqname> carrega uma versão.

Para HALs AIDL, <version> não pode estar presente em dispositivos com Android 11 e versões anteriores. <version> deve ser um número inteiro único em dispositivos com Android 12 e versões posteriores. Deve haver no máximo um <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
Obrigatório. Nome da interface.
manifest.hal.interface.instance
Obrigatório, pode repetir. Nome da instância da interface. Pode ter múltiplas 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 HALs HIDL, o formato é @ MAJOR . MINOR :: INTERFACE / INSTANCE .
  • Para HALs AIDL, o formato é INTERFACE / INSTANCE .
manifest.sepolicy
Obrigatório. Contém todas as entradas relacionadas à sepolicy.
manifest.sepolicy.version
Obrigatório para o manifesto do dispositivo. Declara a versão do 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 <vendor-ndk> devem ter <version> s diferentes. Descreve um conjunto de snapshots do VNDK fornecidos pela estrutura.
manifest.vendor-ndk.version
Obrigatório. Este é um número inteiro positivo que representa a versão do snapshot do VNDK.
manifest.vendor-ndk.library
Opcional, pode repetir, sem duplicatas. Descreve um conjunto de bibliotecas VNDK fornecidas pela estrutura para este snapshot do fornecedor VNDK. O valor é o nome do arquivo de uma biblioteca, por exemplo, libjpeg.so , incluindo o prefixo lib e o sufixo .so . Nenhum componente de caminho é permitido.
manifest.system-sdk.version
Opcional, pode repetir, sem duplicatas; usado apenas pelo manifesto da estrutura. 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 a ramificação do kernel. Seu valor padrão é manifest.target-level se não estiver presente. Deve ser maior ou igual a manifest.target-level . Consulte as regras de correspondência do kernel para obter detalhes.