O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Manifestos

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:
    1. Se SKU for definido (em que 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 for definido, /odm/etc/manifest_ SKU .xml
    4. /odm/etc/manifest.xml
  • 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:
    1. Se SKU for definido (em que 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, 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 para override atributos abaixo.

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 a 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 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 para hwbinder . 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
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, consulte hardware/interfaces , vendor/${VENDOR}/interfaces , framework/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 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 .
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 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 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 a manifest.target-level . Consulte as regras de correspondência do kernel para obter detalhes.