O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Manifestos

A VINTF objeto agrega dados de manifesto de dispositivo e manifestam-quadro arquivos (XML). Ambos os manifestos compartilhar um formato, embora nem todos os elementos se aplicam a ambos (para obter detalhes sobre o esquema, consulte esquema de 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 mais detalhes, consulte fragmentos de manifesto e Gerar DM a partir de fragmentos .
  • O manifesto lista ODM HAL específico para o produto na partição ODM . O objeto VINTF carrega o manifesto ODM nesta ordem:
    1. Se SKU é definida (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 é 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 é definida (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 vendedor
      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, não há 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 dos manifestos, manifestos que aparecem mais tarde na lista pode substituir tags no manifesta que aparecem no início da lista, desde que as marcas na tarde manifesto tem o atributo override="true" . Por exemplo, o manifesto ODM podem substituir algumas <hal> marcas do fornecedor manifesto. Consulte a documentação para o atributo override 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 mais detalhes, consulte Dispositivo Manifest Desenvolvimento .

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 e vive na árvore fonte do Android em manualmente /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 mais 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>
    <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 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 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 , criar 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 ao 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 a seguir implementa android.hardware.foo@1.0::IFoo/default , que é instalado com o vendor ou odm partição. Se ele está instalado no system , product ou system_ext partição, tipo de uso 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>

Esquema de arquivo de manifesto

Esta seção descreve o significado dessas tags XML. Alguns "necessária" tags podem estar faltando do arquivo de origem na árvore fonte do Android e escrito por assemble_vintf em tempo de compilaçã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
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. Tem o valor device para o arquivo de manifesto de dispositivo e framework para o arquivo de manifesto quadro.
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 nativa, tal como GL), dependendo do format atributo.
manifest.hal.format
Opcional. O valor pode ser um dos seguintes:
  • hidl : HAL HIDL. Este é o padrão.
  • aidl : HAL AIDL . Válido apenas na meta-versão 2.0 e superior do manifesto.
  • 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 desativados.
manifest.hal.override
Opcional. O valor pode ser um dos seguintes:
  • true : Substituir outros <hal> elementos com o mesmo <name> e versão principal. Se nenhuma <version> ou <fqname> estão nesta <hal> elemento, então o <hal> elemento declara este HAL para ser desativado.
  • false : Não substitua outros <hal> elementos com o mesmo <name> e versão principal.
manifest.hal.name
Obrigatório. 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 nativa, requer apenas o nome)
manifest.hal.transport
Necessário quando manifest.hal.format == "hidl" . NÃO deve estar presente de outra forma. Afirma qual transporte é usado quando uma interface deste pacote é consultada no gerenciador de serviço. O valor pode ser um dos seguintes:
  • hwbinder : Binderized modo
  • passthrough : Modo Passthrough
manifest.hal.transport.arch
Necessário para passthrough e não devem estar presentes para hwbinder . Descreve a quantidade de bits do serviço de passagem que está sendo fornecido. O valor pode ser um dos seguintes:
  • 32 Modo 32 bits:
  • 64 Modo 64 bits:
  • 32+64 : Ambos
manifest.hal.version
Opcional, pode repetir. Uma versão para os hal marcas em um manifesto.

Para HIDL e HALs nativas, o formato é MAJOR . MINOR . Para exemplos, referem-se a hardware/interfaces , vendor/${VENDOR}/interfaces , framework/hardware/interfaces , ou system/hardware/interfaces .

HIDL e HALs nativos podem usar vários campos versão, desde que eles representam versões principais distintas, com apenas uma versão menor per versão principal fornecido. Por exemplo, 3.1 e 3.2 não podem coexistir, mas 1.0 e 3.4 podem. Isso se aplica a todos os hal elementos 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 abaixo. <version> deve ser um único inteiro em dispositivos que executam o Android 12 e acima. Deve haver no máximo um <version> para cada (package, interface, instance) tupla. Se não estiver presente, o padrão para 1 . O valor de <version> está associado a todos <fqname> na mesma <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. Não pode haver múltiplos <interface> elementos 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 várias instâncias de uma interface, mas não duplicados <instance> elementos.
manifest.hal.fqname
Opcional, pode repetir. Uma maneira alternativa para 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 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. Multiple <vendor-ndk> entradas deve ter diferentes <version> s. Descreve um conjunto de instantâneos VNDK fornecidos pela estrutura.
manifest.vendor-ndk.version
Obrigatório. 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 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. Seus padrões de valor para manifest.target-level se não estiver presente. Deve ser maior ou igual a manifest.target-level . Veja regras de jogo do kernel para obter detalhes.