Manifestos

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

  • O manifesto do fornecedor especifica HALs, versões de política 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 fragmento podem ser usados. Para obter detalhes, consulte Fragmentos de manifesto e Gerar DM de fragmentos .
  • O manifesto do ODM lista os HALs específicos do produto na partição do 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 as HALs específicas do produto na partição do fornecedor. O objeto VINTF carrega o manifesto do fornecedor nesta ordem:
    1. Se SKU for 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 de manifesto de fornecedor opcionais
      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 herdados, o manifesto do fornecedor herdado e o manifesto ODM são usados. O manifesto ODM pode substituir completamente o manifesto do fornecedor herdado.
    • Em dispositivos lançados 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 tags <hal> do manifesto do fornecedor. Consulte a documentação para override de atributo 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íficas do produto).

Aqui está 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>

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 os HALs atendidos pelos 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 manifesto de estrutura de exemplo.

<?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 superior, você pode associar uma entrada de manifesto a um módulo HAL no sistema de compilação. Isso facilita a inclusão condicional do módulo HAL no sistema de compilação.

Exemplo

Em 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 de HAL estão no dispositivo. Qualquer coisa que um manifesto regular faz, esse manifesto também faz.

O exemplo abaixo implementa android.hardware.foo@1.0::IFoo/default , que é instalado no vendor ou na partição odm . Se estiver instalado na partição system , product ou system_ext , use type framework em vez de type 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 ausentes do 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. Apenas fornece informações ao 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 framework para o arquivo de manifesto do framework.
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 de dispositivo destina-se 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 de:
  • hidl : HIDL HALs. Este é o padrão.
  • aidl : AIDL HALs . Válido apenas na meta-versão do manifesto 2.0 e superior.
  • native : HALs nativos.
manifest.hal.max-level
Opcional. Válido apenas em manifestos de framework. Se definido, os HALs com um nível máximo inferior à versão do FCM de destino no manifesto da estrutura são desabilitados.
manifest.hal.override
Opcional. O valor pode ser um de:
  • true : Substitui outros elementos <hal> com o mesmo <name> e versão principal. Se nenhum <version> ou <fqname> estiver neste elemento <hal> , então o elemento <hal> declara que este HAL está desabilitado.
  • false : Não substitua 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 o nome)
manifest.hal.transport
Necessá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 de:
  • hwbinder : modo Binderized
  • 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 ainda mais as informações de conexão Inet.
manifest.hal.transport.arch
Necessário para passthrough e não deve estar presente para hwbinder . Descreve a quantidade de bits do serviço de passagem que está sendo fornecido. O valor pode ser um de:
  • 32 : modo de 32 bits
  • 64 : modo de 64 bits
  • 32+64 : Ambos
manifest.hal.transport.ip
Necessá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
Necessá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 . Para exemplos, 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 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 o Android 12 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> ; 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 .
manifest.sepolicy
Requeridos. Contém todas as entradas relacionadas à sepolicy.
manifest.sepolicy.version
Obrigatório para o manifesto do dispositivo. Declara a versão do SELinux. Tem 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 s <version> diferentes. Descreve um conjunto de instantâneos do VNDK fornecidos pela estrutura.
manifest.vendor-ndk.version
Requeridos. Este é um número inteiro positivo que representa a versão do instantâneo do 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 prefixo lib 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 do fornecedor.
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.