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.

Regras de correspondência

Os dois pares de manifestos e matrizes de compatibilidade devem ser reconciliado para verificar se e a implementação do fornecedor podem funcionar em conjunto. Essa verificação for bem-sucedido quando houver uma correspondência entre a matriz de compatibilidade do framework e o manifesto do dispositivo e entre o manifesto do framework e o dispositivo matriz de compatibilidade.

Essa verificação é feita durante o build, na atualização OTA tempo de geração de pacotes, no momento da inicialização e em testes de compatibilidade do VTS.

As seções a seguir detalham as regras de correspondência usadas pelos vários componentes.

Correspondências da versão da matriz de compatibilidade do framework

Para corresponder um manifesto de dispositivo a uma matriz de compatibilidade de framework, a versão de envio do FCM especificada por manifest.target-level precisa ser exatamente igual à versão do FCM especificada pelo compatibility-matrix.level. Caso contrário, não há correspondência.

Quando a matriz de compatibilidade do framework é solicitada com libvintf, essa correspondência é sempre bem-sucedido porque libvintf abre o manifesto do dispositivo, recupera o objeto Shipping Versão do FCM, e retorna a matriz de compatibilidade do framework nessa versão de envio do FCM (mais alguns HALs opcionais de matrizes de compatibilidade em versões mais recentes do FCM).

Correspondências de HAL

A regra de correspondência de HAL identifica as versões dos elementos hal em um arquivo de manifesto que tem suporte do proprietário do arquivo matriz de compatibilidade.

HIDL e HALs nativas

Veja a seguir as regras de correspondência para HIDL e HALs nativas.

Vários elementos <hal> são avaliados com um único AND. relação.
Os elementos <hal> podem ter <hal optional="true"> para marcá-los como não é obrigatório.
Vários elementos <version> no mesmo <hal> têm o relação OR. Se dois ou mais forem especificados, apenas uma das versões precisa ser implementada. Consulte o exemplo de DRM abaixo.
Vários <instance> e elementos <regex-instance> no mesmo <hal> são avaliadas com uma única relação E quando os O campo <hal> é obrigatório. Veja o <ahref="#drm">exemplo de DRM abaixo.</ahref="#drm">

Exemplo: correspondência de HAL bem-sucedida para um módulo

Para uma HAL na versão 2.5, a regra de correspondência é a seguinte:

Matriz Manifesto correspondente

2.5 2,5-2.✕. Na matriz de compatibilidade, 2.5 é a abreviação de 2.5-5.

Matriz	Manifesto correspondente
`2.5`	2,5-2.✕. Na matriz de compatibilidade, `2.5` é a abreviação de `2.5-5`.
`2.5-7`	2,5-2. inclusive. Indica o seguinte: A versão 2.5 é a mínima necessária, ou seja, um manifesto que fornece a HAL. 2.0-2.4 não é compatível. A versão 2.7 é a máxima que poderia ser solicitada, ou seja, o proprietário do a matriz de compatibilidade (framework ou dispositivo) não solicitará versões além de 2,7. O proprietário do manifesto correspondente ainda pode veicular a versão 2.10 (por exemplo) quando 2.7 é solicitado. O proprietário da matriz de compatibilidade sabe somente se o serviço solicitado é compatível com a versão 2.7 da API. O número -7 é apenas informativo e não afeta o processo de atualização OTA. . Assim, um dispositivo com uma HAL na versão 2.10 no arquivo de manifesto permanece compatível com um framework que declara `2.5-7` na matriz de compatibilidade.

2.5-7

2,5-2. inclusive. Indica o seguinte:

A versão 2.5 é a mínima necessária, ou seja, um manifesto que fornece a HAL. 2.0-2.4 não é compatível.
A versão 2.7 é a máxima que poderia ser solicitada, ou seja, o proprietário do a matriz de compatibilidade (framework ou dispositivo) não solicitará versões além de 2,7. O proprietário do manifesto correspondente ainda pode veicular a versão 2.10 (por exemplo) quando 2.7 é solicitado. O proprietário da matriz de compatibilidade sabe somente se o serviço solicitado é compatível com a versão 2.7 da API.
O número -7 é apenas informativo e não afeta o processo de atualização OTA.

. Assim, um dispositivo com uma HAL na versão 2.10 no arquivo de manifesto permanece compatível com um framework que declara 2.5-7 na matriz de compatibilidade.

Exemplo: correspondência de HAL bem-sucedida para o módulo DRM

A matriz de compatibilidade do framework apresenta as seguintes informações de versão para HAL de DRM:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Um fornecedor precisa implementar UMA das seguintes instâncias: de cada

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0

android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

E também precisa implementar todas estas instâncias:

android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

HALs da AIDL

Todas as versões do Android anteriores ao 11 (exceto Android) 11) oferece suporte a versões de HALs da AIDL no VINTF. As regras de correspondência para HALs AIDL são semelhantes às de HIDL e HALs nativas, exceto que não há versões principais e há exatamente uma versão por instância de HAL (1 se versão não especificada).

Vários elementos <hal> são avaliados com um único AND. relação.
Os elementos <hal> podem ter <hal optional="true"> para marcá-los como não é obrigatório.
Vários <instance> e elementos <regex-instance> no mesmo <hal> são avaliadas com uma única relação E quando os O campo <hal> é obrigatório. Veja o <ahref="#vibrator">exemplo de vibração abaixo.</ahref="#vibrator">

Exemplo: correspondência de HAL bem-sucedida para um módulo

Para uma HAL na versão 5, a regra de correspondência é a seguinte:

Matriz Manifesto correspondente

5 5-Máximo. Na matriz de compatibilidade, 5 é a abreviação de 5-5.

Matriz	Manifesto correspondente
`5`	5-Máximo. Na matriz de compatibilidade, `5` é a abreviação de `5-5`.
`5-7`	5-Máximo. Indica o seguinte: 5 é a versão mínima necessária, ou seja, um manifesto que fornece a HAL 1 a 4 não é compatível. 7 é a versão máxima que pode ser solicitada, ou seja, o proprietário do a matriz de compatibilidade (framework ou dispositivo) não solicitará versões além de 7. O proprietário do manifesto correspondente ainda pode veicular a versão 10 (por exemplo) quando 7 é solicitado. O proprietário da matriz de compatibilidade sabe somente se o serviço solicitado é compatível com a versão 7 da API. O número -7 é apenas informativo e não afeta o processo de atualização OTA. . Assim, um dispositivo com uma HAL na versão 10 no arquivo de manifesto permanece compatível com um framework que declara `5-7` na matriz de compatibilidade.

5-7

5-Máximo. Indica o seguinte:

5 é a versão mínima necessária, ou seja, um manifesto que fornece a HAL 1 a 4 não é compatível.
7 é a versão máxima que pode ser solicitada, ou seja, o proprietário do a matriz de compatibilidade (framework ou dispositivo) não solicitará versões além de 7. O proprietário do manifesto correspondente ainda pode veicular a versão 10 (por exemplo) quando 7 é solicitado. O proprietário da matriz de compatibilidade sabe somente se o serviço solicitado é compatível com a versão 7 da API.
O número -7 é apenas informativo e não afeta o processo de atualização OTA.

. Assim, um dispositivo com uma HAL na versão 10 no arquivo de manifesto permanece compatível com um framework que declara 5-7 na matriz de compatibilidade.

Exemplo: correspondência de HAL bem-sucedida para vários módulos

A matriz de compatibilidade do framework apresenta as seguintes informações de versão para HALs de vibração e câmera:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Um fornecedor precisa implementar todas estas instâncias:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

Correspondências do kernel

A seção <kernel> da matriz de compatibilidade do framework descreve os requisitos do framework para o kernel do Linux no dispositivo. Isso as informações devem corresponder às informações sobre o kernel informado pelo objeto VINTF do dispositivo.

Corresponder ramificações do kernel

Cada sufixo de ramificação do kernel (por exemplo, 5.4-r) é mapeado para um único versão do FCM do kernel (por exemplo, 5). O mapeamento é o mesmo que o mapeamento entre as letras de lançamento (por exemplo, R) e versões do FCM (por exemplo, 5).

Os testes VTS exigem que o dispositivo especifique explicitamente a versão do FCM do kernel na manifesto do dispositivo, /vendor/etc/vintf/manifest.xml, se uma das seguintes condições for verdadeira:

A versão do FCM do kernel é diferente da versão de destino do FCM. Por exemplo, o o dispositivo mencionado acima tem uma versão 4 do FCM de destino e a versão do FCM do kernel é a 5 (kernel) sufixo de ramificação r).
A versão do FCM do kernel é maior ou igual a 5 (sufixo de ramificação do kernel r).

Observação: Se a versão do FCM do kernel for igual à versão de destino do FCM e elas forem maiores ou iguais a 5, o arquivo de origem do manifesto do dispositivo especificado por DEVICE_MANIFEST_FILE não tiver para especificar a versão do FCM do kernel. assemble_vintf infere automaticamente o versão do FCM do kernel a partir da versão de destino do FCM, caso essa versão seja maior ou igual a 5)

Os testes VTS impõem que, se a versão do FCM do kernel for especificada, a versão do FCM do kernel será maior ou igual à versão de destino do FCM no manifesto do dispositivo.

Exemplo: determinar a ramificação do kernel

Se o dispositivo tiver como destino a versão 4 do FCM (lançada no Android 10), mas executa o kernel da ramificação 4.19-r, o manifesto do dispositivo precisa especificar o seguinte:

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

O objeto VINTF verifica a compatibilidade do kernel em relação aos requisitos no kernel 4.19-r. especificada na versão 5 do FCM. Esses requisitos são criados kernel/configs/r/android-4.19 na árvore de origem do Android.

Exemplo: determinar a ramificação do kernel para GKI

Se o dispositivo usar a imagem genérica do kernel (GKI, na sigla em inglês) e a string de liberação do kernel do /proc/version é o seguinte:

5.4.42-android12-0-00544-ged21d463f856

Em seguida, o objeto VINTF obtém a versão do Android a partir da versão do kernel e a usa para determinar a versão do FCM do kernel. Neste exemplo, android12 significa a versão 6 do FCM do kernel (lançado no Android 12).

Para mais detalhes sobre como a string de versão do kernel é analisada, consulte Controle de versões de GKI.

Corresponder às versões do kernel

Uma matriz pode incluir várias seções <kernel>, cada uma com um atributo version diferente usando o formato:

${ver}.${major_rev}.${kernel_minor_rev}

O objeto VINTF considera apenas a seção <kernel> da FCM com versão correspondente do FCM com a mesma ${ver} e ${major_rev} como o kernel do dispositivo (ou seja, version="${ver}.${major_rev}.${matrix_minor_rev}") outras seções são ignorados. Além disso, a revisão secundária do kernel deve ser um valor da matriz de compatibilidade (${kernel_minor_rev} >= ${matrix_minor_rev};). Se nenhuma seção sobre <kernel> atender esses requisitos, é uma não correspondência.

Exemplo: selecionar requisitos de correspondência

Considere o seguinte caso hipotético em que os FCMs em /system/etc/vintf declaram a requisitos a seguir (as tags de cabeçalho e rodapé são omitidas):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

A versão de destino do FCM, a versão do FCM do kernel e a versão do kernel juntas selecionam o kernel requisitos dos FCMs:

Versão de destino do FCM	Versão do FCM do kernel	Versão do kernel	Corresponder a
3 (p)	não especificado	`4.4.106`	Sem correspondência (incompatibilidade de versão secundária)
3 (p)	não especificado	`4.4.107`	`4.4-p`
3 (p)	não especificado	`4.19.42`	`4.19-q` (veja a observação abaixo)
3 (p)	não especificado	`5.4.41`	`5.4-r` (veja a observação abaixo)
3 (p)	3 (p)	`4.4.107`	`4.4-p`
3 (p)	3 (p)	`4.19.42`	Sem correspondência (sem ramificação do kernel `4.19-p`)
3 (p)	4 (T)	`4.19.42`	`4.19-q`
4 (T)	não especificado	`4.4.107`	Sem correspondência (sem ramificação do kernel `4.4-q`)
4 (T)	não especificado	`4.9.165`	`4.9-q`
4 (T)	não especificado	`5.4.41`	`5.4-r` (veja a observação abaixo)
4 (T)	4 (T)	`4.9.165`	`4.9-q`
4 (T)	4 (T)	`5.4.41`	Sem correspondência (sem ramificação do kernel `5.4-q`)
4 (T)	5 (D)	`4.14.105`	`4.14-r`
4 (T)	5 (D)	`5.4.41`	`5.4-r`
5 (D)	não especificado	qualquer	A VTS falha. É necessário especificar a versão do kernel do FCM para a versão 5 de destino do FCM.
5 (D)	4 (T)	qualquer	A VTS falha (versão do FCM do kernel < target FCM version)
5 (D)	5 (D)	`4.14.180`	`4.14-r`

Observação: Para dispositivos com uma versão de destino do FCM anterior a 5 (R) e uma versão do FCM do kernel não especificada, o O objeto VINTF seleciona a ramificação do kernel com o menor sufixo maior que o FCM de destino com a versão do kernel correspondente. No exemplo acima, um dispositivo com uma versão de destino do FCM das 3 (P) usam a ramificação do kernel 4.19-q porque 4.19-q tem o menor sufixo entre todas as ramificações de kernel 4.19-*, [4.19-q, 4.19-r, 4.19-s]. Isso o comportamento de seleção de requisito não é permitido para dispositivos com a versão 5 (R) de destino do FCM ou porque a versão do FCM do kernel precisa ser especificado.

Corresponder às configurações do kernel

Se a seção <kernel> corresponder, o processo continuará ao tentar corresponder elementos config com /proc/config.gz Para cada elemento de configuração na compatibilidade matriz, ele pesquisa /proc/config.gz para ver se a configuração é presente. Quando um item de configuração é definido como n na compatibilidade matriz para a seção <kernel> correspondente, ela deve estar ausente de /proc/config.gz. Por fim, um item de configuração que não matriz de compatibilidade pode ou não estar presente em /proc/config.gz.

Exemplo: combinar configurações de kernel

<value type="string">bar</value> correspondências "bar". As aspas são omitidas na matriz de compatibilidade, mas estão presentes em /proc/config.gz.
<value type="int">4096</value> correspondências 4096, 0x1000 ou 0X1000.
<value type="int">0x1000</value> correspondências 4096, 0x1000 ou 0X1000.
<value type="int">0X1000</value> correspondências 4096, 0x1000 ou 0X1000.
<value type="tristate">y</value> correspondências y.
<value type="tristate">m</value> correspondências m.
<value type="tristate">n</value> significa que a configuração o item NÃO pode existir em /proc/config.gz.
<value type="range">1-0x3</value> correspondências 1, 2 ou 3 ou equivalente hexadecimal.

Exemplo: correspondência de kernel bem-sucedida

Uma matriz de compatibilidade de framework com o FCM versão 1 tem as seguintes informações de kernel:

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

A correspondência da ramificação do kernel é feita primeiro. A ramificação do kernel é especificada no manifesto do dispositivo em manifest.kernel.target-level, que tem como padrão manifest.level se o primeiro não for especificado. Se a ramificação do kernel no manifesto do dispositivo:

é 1, prossegue para a próxima etapa e verifica a versão do kernel.
for 2, não corresponde à matriz. Os objetos VINTF leem os requisitos do kernel da matriz em Versão 2 do FCM.

Depois, é feita a correspondência com a versão do kernel. Se um dispositivo em uname() relatórios:

4.9.84 (sem correspondência com a matriz, a menos que haja uma seção de kernel separada com <kernel version="4.9.x">, em que x <= 84)
4.14.41 (sem correspondência para a matriz, menor que version)
4.14.42 (corresponde à matriz)
4.14.43 (corresponde à matriz)
4.1.22 (sem correspondência com a matriz, a menos que haja uma seção de kernel separada com <kernel version="4.1.x"> em que x <= 22)

Depois de selecionar a seção <kernel> apropriada, para para cada item <config> com um valor diferente de n, nós espera que a entrada correspondente esteja presente em /proc/config.gz; para cada item <config> com valor n, esperamos a entrada correspondente não esteja presente em /proc/config.gz. Qa espera que o conteúdo de <value> corresponda exatamente ao texto depois sinal de igual (incluindo aspas), até o caractere de nova linha ou #, com espaço em branco no início e no fim truncado.

A seguinte configuração de kernel é um exemplo de uma correspondência bem-sucedida:

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

A seguinte configuração de kernel é um exemplo de correspondência malsucedida:

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

Correspondências da política de SE

A política de SE requer as seguintes correspondências:

<sepolicy-version> define um intervalo fechado de objetos menores. para cada versão principal. A versão do sepolicy informada pelo dispositivo precisam estar em um desses intervalos para serem compatíveis com a estrutura. Correspondência são semelhantes às versões da HAL. haverá uma correspondência se a versão sepolicy for maior ou igual à versão mínima do intervalo. A versão máxima é puramente informativa.
<kernel-sepolicy-version>, ou seja, a versão do policydb. Deve ser menor que a security_policyvers() informada pelo dispositivo.

Exemplo: correspondência da política de SE bem-sucedida

A matriz de compatibilidade do framework apresenta as seguintes informações sepolicy:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

No dispositivo:

O valor retornado por security_policyvers() precisa ser maior ou igual a 30. Caso contrário, não é uma correspondência. Por exemplo:
- Se o dispositivo retornar 29, não será uma correspondência.
- Se o dispositivo retornar 31, é uma correspondência.
A versão da política de SE deve ser 25.0-✕ ou 26.0- inclusive. Caso contrário, não é um são correspondentes. O "-3" depois de "26.0" é puramente informativa.)

Correspondências da versão do AVB

A versão AVB contém uma versão MAJOR e uma versão MENOR, com o formato como MAJOR.MINOR (por exemplo, 1.0, 2.1). Para mais detalhes, consulte Controle de versões e compatibilidade. A versão da AVB tem as seguintes propriedades de sistema:

ro.boot.vbmeta.avb_version é a versão libavb no carregador de inicialização
ro.boot.avb_version é a versão libavb em SO Android (init/fs_mgr)

A propriedade do sistema só aparece quando o libavb correspondente é usado. para verificar os metadados AVB (e retorna OK). Está ausente se uma falha na verificação ocorreu (ou nenhuma verificação ocorreu).

Uma correspondência de compatibilidade compara o seguinte:

sysprop ro.boot.vbmeta.avb_version com avb.vbmeta-version da matriz de compatibilidade do framework;
- ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
- ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
sysprop ro.boot.avb_version com avb.vbmeta-version da matriz de compatibilidade do framework.
- ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
- ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

O carregador de inicialização ou o SO Android pode conter duas cópias de libavb. bibliotecas, cada uma com uma versão MAJOR diferente para dispositivos de upgrade dispositivos. Nesse caso, a mesma imagem do sistema não assinada pode ser compartilhada, mas as imagens assinadas finais do sistema são diferentes (com diferentes avb.vbmeta-version):

Figura 1. A versão do AVB corresponde (/system é P, todas as outras partições são O).

Figura 2. A versão do AVB é correspondente (todas as partições são P).

Exemplo: correspondência da versão AVB concluída

A matriz de compatibilidade do framework apresenta as seguintes informações da AVB:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

No dispositivo:

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match

ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match

Corresponder a versão do AVB durante o OTA

Para dispositivos lançados com o Android 9 ou versões anteriores, ao atualizar para Android 10, o AVB os requisitos de versão na matriz de compatibilidade do framework são comparados com o AVB atual versão no dispositivo. Se a versão do AVB tiver um upgrade de versão principal durante um OTA (por exemplo, de 0,0 a 1,0), a verificação de compatibilidade do VINTF no OTA não refletirá a compatibilidade após pela agência de viagens on-line.

Para atenuar o problema, um OEM pode colocar uma versão AVB falsa no pacote OTA (compatibility.zip) para passar na verificação. Para fazer isso, siga estas etapas:

Selecione os CLs abaixo para a árvore de origem do Android 9:
- CL 732261 (link em inglês)
- CL 732262 (link em inglês)
Defina BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE para o dispositivo. O valor deveria ser igual à versão AVB antes da OTA, ou seja, a versão AVB do dispositivo quando foi lançado.
Recrie o pacote OTA.

Essas mudanças colocam automaticamente BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE como compatibility-matrix.avb.vbmeta-version nos seguintes arquivos:

/system/compatibility_matrix.xml (que não é usado no Android 9) no dispositivo
system_matrix.xml em compatibility.zip no pacote OTA

Essas alterações não afetam outras matrizes de compatibilidade de framework, incluindo /system/etc/vintf/compatibility_matrix.xml: Depois da OTA, o novo valor /system/etc/vintf/compatibility_matrix.xml é usado para verificações de compatibilidade.

Correspondências da versão do VNDK

A matriz de compatibilidade do dispositivo declara a versão necessária do VNDK em compatibility-matrix.vendor-ndk.version: Se o dispositivo matriz de compatibilidade não tem uma tag <vendor-ndk>, não requisitos são impostos e, por isso, é sempre considerado uma correspondência.

Se a matriz de compatibilidade do dispositivo tiver um <vendor-ndk> uma entrada <vendor-ndk> com uma <version> foi pesquisado no conjunto de snapshots do fornecedor de VNDK que é fornecido pelo framework no manifesto dele. Se essa entrada não não existe correspondências.

Se essa entrada existir, o conjunto de bibliotecas enumerado no dispositivo a matriz de compatibilidade precisa ser um subconjunto do conjunto de bibliotecas indicado no manifesto da estrutura; caso contrário, a entrada não é considerada uma correspondência.

Como um caso especial, se nenhuma biblioteca for enumerada no dispositivo matriz de compatibilidade, a entrada será sempre considerada uma correspondência, porque os dados vazios é um subconjunto de qualquer conjunto.

Exemplo: correspondência de versão do VNDK bem-sucedida

Se a matriz de compatibilidade do dispositivo indicar o seguinte requisito no VNDK:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

No manifesto do framework, apenas a entrada com a versão 27 é considerada.

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

O exemplo A é uma correspondência, porque a versão 27 do VNDK está no manifesto do framework, e {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}.

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

O exemplo B não é uma correspondência. Embora a versão 27 do VNDK esteja no framework manifesto, o libjpeg.so não tem suporte do framework nessa snapshot. A versão 26 do VNDK é ignorada.

Correspondências da versão do SDK do sistema

A matriz de compatibilidade do dispositivo declara um conjunto de SDKs do sistema necessários versão em compatibility-matrix.system-sdk.version. Há um corresponder apenas se o conjunto for um subconjunto das versões do SDK do sistema fornecidas, conforme declarado em manifest.system-sdk.version no manifesto do framework.

Como um caso especial, se nenhuma versão do SDK do sistema for enumerada no dispositivo matriz de compatibilidade, ela será sempre considerada uma correspondência, porque os dados é um subconjunto de qualquer conjunto.

Exemplo: correspondência de versão do SDK do sistema concluída

Se a matriz de compatibilidade do dispositivo indicar o seguinte requisito no sistema SDK:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Em seguida, o framework precisa fornecer as versões 26 e 27 do SDK do sistema para corresponder.

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

O exemplo A é uma correspondência.

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

O exemplo B é uma correspondência.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

O exemplo C não é uma correspondência porque a versão 27 do SDK do sistema não foi fornecida.