Regras de correspondência

Os dois pares de matrizes de compatibilidade e manifestos devem ser reconciliados para verificar se a estrutura e a implementação do fornecedor podem funcionar entre si. Esta verificação é bem-sucedida após uma correspondência entre a matriz de compatibilidade da estrutura e o manifesto do dispositivo, bem como entre o manifesto da estrutura e a matriz de compatibilidade do dispositivo.

Essa verificação é feita no momento da construção, no momento da geração do pacote de atualização OTA , no momento da inicialização e nos testes de compatibilidade do VTS.

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

A versão da matriz de compatibilidade da estrutura corresponde

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

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

HAL corresponde

A regra de correspondência HAL identifica as versões dos elementos hal em um arquivo de manifesto que são consideradas suportadas pelo proprietário da matriz de compatibilidade correspondente.

HIDL e HALs nativos

As regras de correspondência para HIDL e HALs nativos são as seguintes.

  • Vários elementos <hal> são avaliados com um único relacionamento AND .
  • Os elementos <hal> podem ter <hal optional="true"> para marcá-los como não obrigatórios.
  • Vários elementos <version> dentro do mesmo <hal> possuem o relacionamento OR . Se duas ou mais forem especificadas, apenas uma das versões precisará ser implementada. (Veja o exemplo de DRM abaixo.)
  • Vários elementos <instance> e <regex-instance> dentro do mesmo <hal> são avaliados com um único relacionamento AND quando o <hal> é necessário. (Veja o Exemplo de DRM abaixo.)

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

Para um 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 .
2.5-7 2,5-2.∞. Indica o seguinte:
  • 2.5 é a versão mínima exigida, o que significa que um manifesto fornecendo HAL 2.0-2.4 não é compatível.
  • 2.7 é a versão máxima que pode ser solicitada, ou seja, o proprietário da matriz de compatibilidade (framework ou dispositivo) não solicitará versões além de 2.7. O proprietário do manifesto correspondente ainda pode servir a versão 2.10 (como exemplo) quando a 2.7 for solicitada. O proprietário da matriz de compatibilidade sabe apenas que o serviço solicitado é compatível com a versão 2.7 da API.
  • -7 é apenas informativo e não afeta o processo de atualização OTA.
Assim, um dispositivo com HAL na versão 2.10 em seu arquivo de manifesto permanece compatível com uma estrutura que indica 2.5-7 em sua matriz de compatibilidade.

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

A matriz de compatibilidade da estrutura indica as seguintes informações de versão para DRM HAL:

<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 deve implementar UMA das seguintes instâncias; qualquer

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

E também deve 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 AIDL

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

  • Vários elementos <hal> são avaliados com um único relacionamento AND .
  • Os elementos <hal> podem ter <hal optional="true"> para marcá-los como não obrigatórios.
  • Vários elementos <instance> e <regex-instance> dentro do mesmo <hal> são avaliados com um único relacionamento AND quando o <hal> é necessário. (Veja o exemplo de vibrador abaixo.)

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

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

Matriz Manifesto Correspondente
5 5-∞. Na matriz de compatibilidade, 5 é a abreviação de 5-5 .
5-7 5-∞. Indica o seguinte:
  • 5 é a versão mínima exigida, o que significa que um manifesto fornecendo HAL 1-4 não é compatível.
  • 7 é a versão máxima que pode ser solicitada, o que significa que o proprietário da matriz de compatibilidade (estrutura ou dispositivo) não solicitará versões além de 7. O proprietário do manifesto correspondente ainda pode servir a versão 10 (como exemplo) quando 7 for solicitado . O proprietário da matriz de compatibilidade sabe apenas que o serviço solicitado é compatível com a versão 7 da API.
  • -7 é apenas informativo e não afeta o processo de atualização OTA.
Assim, um dispositivo com HAL na versão 10 em seu arquivo de manifesto permanece compatível com uma estrutura que indica 5-7 em sua matriz de compatibilidade.

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

A matriz de compatibilidade da estrutura indica as seguintes informações de versão para HALs de vibradores e câmeras:

<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 deve 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 de kernel

A seção <kernel> da matriz de compatibilidade da estrutura descreve os requisitos da estrutura do kernel Linux no dispositivo. Essas informações devem ser comparadas com as informações sobre o kernel que são relatadas pelo objeto VINTF do dispositivo.

Corresponder ramificações do kernel

Cada sufixo de ramificação do kernel (por exemplo, 5.4- r ) é mapeado para uma versão exclusiva do FCM do kernel (por exemplo, 5). O mapeamento é igual ao mapeamento entre cartas de lançamento (por exemplo, R) e versões do FCM (por exemplo, 5).

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

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

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

Exemplo: Determinar o branch do kernel

Se o dispositivo tiver como destino o FCM versão 4 (lançado no Android 10), mas executar o kernel da ramificação 4.19-r , o manifesto do dispositivo deverá 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 na ramificação do kernel 4.19-r , que é especificada na versão 5 do FCM. Esses requisitos são criados a partir de kernel/configs/r/android-4.19 na árvore de origem do Android.

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

Se o dispositivo usar a imagem genérica do kernel (GKI) e a sequência de lançamento do kernel de /proc/version for a 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 usa-a para determinar a versão do FCM do kernel. Neste exemplo, android12 significa kernel FCM versão 6 (lançado no Android 12).

Para obter detalhes sobre como a string de lançamento do kernel é analisada, consulte Controle de versão do GKI .

Corresponder versões do kernel

Uma matriz pode incluir múltiplas 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> do FCM com a versão correspondente do FCM com o mesmo ${ver} e ${major_rev} do kernel do dispositivo (ou seja, version="${ver}.${major_rev}.${matrix_minor_rev}") ; outras seções são ignoradas. 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 <kernel> atender a esses requisitos, não há correspondência.

Exemplo: Selecione requisitos para correspondência

Considere o seguinte caso hipotético em que FCMs em /system/etc/vintf declaram os seguintes requisitos (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 alvo do FCM, a versão do kernel FCM e a versão do kernel selecionam juntas os requisitos do kernel dos FCMs:

Versão alvo do FCM Versão do kernel FCM Versão do kernel Combina com
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 (ver nota abaixo)
3 (P) não especificado 5.4.41 5.4-r (ver nota abaixo)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Sem correspondência (nenhuma ramificação do kernel 4.19-p )
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) não especificado 4.4.107 Sem correspondência (nenhuma ramificação do kernel 4.4-q )
4 (Q) não especificado 4.9.165 4.9-q
4 (Q) não especificado 5.4.41 5.4-r (ver nota abaixo)
4 (Q) 4 (Q) 4.9.165 4.9-q
4 (Q) 4 (Q) 5.4.41 Sem correspondência (nenhuma ramificação do kernel 5.4-q )
4 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) não especificado qualquer VTS falha (deve especificar a versão do FCM do kernel para a versão 5 do FCM de destino)
5 (R) 4 (Q) qualquer VTS falha (versão FCM do kernel <versão FCM alvo)
5 (R) 5 (R) 4.14.180 4.14-r

Corresponder às configurações do kernel

Se a seção <kernel> corresponder, o processo continuará tentando combinar os elementos config com /proc/config.gz . Para cada elemento de configuração na matriz de compatibilidade, ele consulta /proc/config.gz para ver se a configuração está presente. Quando um item de configuração é definido como n na matriz de compatibilidade da seção <kernel> correspondente, ele deve estar ausente de /proc/config.gz . Finalmente, um item de configuração que não está na matriz de compatibilidade pode ou não estar presente em /proc/config.gz .

Exemplo: Corresponder às configurações do kernel

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

Exemplo: correspondência de kernel bem-sucedida

Uma matriz de compatibilidade da estrutura com o FCM versão 1 possui as seguintes informações do 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 ramificação do kernel é correspondida primeiro. A ramificação do kernel é especificada no manifesto do dispositivo em manifest.kernel.target-level , cujo 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.
  • é 2, nenhuma correspondência com a matriz. Os objetos VINTF leem os requisitos do kernel da matriz no FCM versão 2.

Então, a versão do kernel é correspondida. Se um dispositivo em uname() reportar:

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

Depois que a seção <kernel> apropriada for selecionada, para cada item <config> com valor diferente de n , esperamos que a entrada correspondente esteja presente em /proc/config.gz ; para cada item <config> com valor n , esperamos que a entrada correspondente não esteja presente em /proc/config.gz . Esperamos que o conteúdo de <value> corresponda exatamente ao texto após o sinal de igual (incluindo aspas), até o caractere de nova linha ou # , com os espaços em branco iniciais e finais truncados.

A seguinte configuração do 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 uma 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 de política SE

A política SE exige as seguintes correspondências:

  • <sepolicy-version> define um intervalo fechado de versões secundárias para cada versão principal. A versão da sepolicy informada pelo dispositivo deve estar dentro de uma dessas faixas para ser compatível com a estrutura. As regras de correspondência são semelhantes às versões HAL; é uma correspondência se a versão da sepolicy for superior ou igual à versão mínima do intervalo. A versão máxima é meramente informativa.
  • <kernel-sepolicy-version> ou seja, versão do policydb. Deve ser menor que security_policyvers() relatado pelo dispositivo.

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

A matriz de compatibilidade da estrutura indica as seguintes informações de política:

<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() deve ser maior ou igual a 30. Caso contrário, não será correspondente. Por exemplo:
    • Se um dispositivo retornar 29, não há correspondência.
    • Se um dispositivo retornar 31, é uma correspondência.
  • A versão da Política SE deve ser 25.0-∞ ou 26.0-∞. Caso contrário, não é uma correspondência. (O " -3 " depois de " 26.0 " é puramente informativo.)

A versão do AVB corresponde

A versão AVB contém uma versão MAJOR e uma versão MINOR, com o formato MAJOR.MINOR (por exemplo, 1.0, 2.1). Para obter detalhes, consulte Controle de versão e compatibilidade . A versão AVB possui as seguintes propriedades de sistema:

  • ro.boot.vbmeta.avb_version é a versão libavb no bootloader
  • ro.boot.avb_version é a versão libavb no sistema operacional Android ( init/fs_mgr )

A propriedade do sistema aparece apenas quando o libavb correspondente foi usado para verificar os metadados do AVB (e retorna OK). Está ausente se ocorreu uma falha de verificação (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 da estrutura;
    • 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 da estrutura.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

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

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


Figura 2. Correspondências de versão do AVB (todas as partições são P).

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

A matriz de compatibilidade da estrutura indica as seguintes informações do 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 
l10n-placeholder18
ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

Versão AVB correspondente durante OTA

Para dispositivos lançados com Android 9 ou inferior, ao atualizar para o Android 10, os requisitos de versão do AVB na matriz de compatibilidade da estrutura são comparados com a versão atual do AVB no dispositivo. Se a versão AVB tiver uma atualização de versão principal durante um OTA (por exemplo, de 0,0 para 1,0), a verificação VINTF de compatibilidade no OTA não refletirá a compatibilidade após o OTA.

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

  1. Escolha os seguintes CLs para a árvore de origem do Android 9:
  2. Defina BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE para o dispositivo. Seu valor deve ser igual à versão AVB antes do OTA, ou seja, a versão AVB do aparelho quando foi lançado.
  3. Reconstrua o pacote OTA.

Essas alterações 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 estrutura, incluindo /system/etc/vintf/compatibility_matrix.xml . Após o OTA, o novo valor em /system/etc/vintf/compatibility_matrix.xml é usado para verificações de compatibilidade.

A versão do VNDK corresponde

A matriz de compatibilidade de dispositivos declara a versão necessária do VNDK em compatibility-matrix.vendor-ndk.version . Se a matriz de compatibilidade de dispositivos não tiver uma tag <vendor-ndk> , nenhum requisito será imposto e, portanto, será sempre considerada uma correspondência.

Se a matriz de compatibilidade de dispositivos tiver uma tag <vendor-ndk> , uma entrada <vendor-ndk> com uma <version> correspondente será pesquisada no conjunto de snapshots do fornecedor VNDK fornecido pela estrutura no manifesto da estrutura. Se tal entrada não existir, não há correspondência.

Se tal entrada existir, o conjunto de bibliotecas enumeradas na matriz de compatibilidade de dispositivos deverá ser um subconjunto do conjunto de bibliotecas indicado no manifesto da estrutura; caso contrário, a entrada não será considerada correspondente.

  • Como um caso especial, se nenhuma biblioteca for enumerada na matriz de compatibilidade de dispositivos, a entrada será sempre considerada uma correspondência, porque o conjunto vazio é um subconjunto de qualquer conjunto.

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

Se a matriz de compatibilidade de dispositivos 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 da estrutura 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 corresponde. Embora a versão 27 do VNDK esteja no manifesto da estrutura, libjpeg.so não é compatível com a estrutura nesse instantâneo. A versão 26 do VNDK é ignorada.

A versão do SDK do sistema corresponde

A matriz de compatibilidade de dispositivos declara um conjunto de versões necessárias do SDK do sistema em compatibility-matrix.system-sdk.version . Haverá uma correspondência somente se o conjunto for um subconjunto de versões do SDK do sistema fornecidas, conforme declarado em manifest.system-sdk.version no manifesto da estrutura.

  • Como um caso especial, se nenhuma versão do System SDK for enumerada na matriz de compatibilidade de dispositivos, isso sempre será considerado uma correspondência, porque o conjunto vazio é um subconjunto de qualquer conjunto.

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

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

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

Em seguida, a estrutura deve fornecer as versões 26 e 27 do System SDK 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 corresponde porque o System SDK versão 27 não é fornecido.