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.
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
OU
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.
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).
.

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 FCMVersão do FCM do kernelVersão do kernelCorresponder a
3 (p)não especificado4.4.106 Sem correspondência (incompatibilidade de versão secundária)
3 (p)não especificado4.4.107 4.4-p
3 (p)não especificado4.19.42 4.19-q (veja a observação abaixo)
3 (p)não especificado5.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 especificado4.4.107 Sem correspondência (sem ramificação do kernel 4.4-q)
4 (T)não especificado4.9.165 4.9-q
4 (T)não especificado5.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.1054.14-r
4 (T)5 (D) 5.4.41 5.4-r
5 (D)não especificadoqualquer 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.1804.14-r

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:

  1. Selecione os CLs abaixo para a árvore de origem do Android 9:
  2. 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.
  3. 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.