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

Regras de correspondência

Os dois pares de matrizes e manifestos de compatibilidade devem ser reconciliados para verificar se a implementação da estrutura e do fornecedor pode funcionar uma com a outra. Essa verificação é bem-sucedida em 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.

Esta verificação é feita em tempo de compilação, a OTA tempo de geração pacote de atualização, no momento da inicialização, e em testes de compatibilidade 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 a um manifesto dispositivo com uma matriz de compatibilidade quadro, a versão envio FCM especificado pelo manifest.target-level deve ser exatamente igual à versão FCM especificado pela compatibility-matrix.level . Caso contrário, não há correspondência.

Quando a matriz de compatibilidade quadro é solicitado com libvintf , este jogo é sempre bem sucedido porque libvintf abre o manifesto dispositivo, recupera a FCM versão de envio, e retorna a matriz de compatibilidade quadro naquele envio FCM Version (além de alguns HALs opcionais de matrizes de compatibilidade com maior FCM Versões).

Partidas HAL

Os identifica regra HAL-match as versões de hal elementos em um arquivo de manifesto que são considerados a ser suportado 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 <hal> elementos são avaliados com um único e de relacionamento.
  • Vários <version> elementos dentro da mesma <hal> têm o ou relacionamento. Se dois ou mais forem especificados, apenas uma das versões precisa ser implementada. (Ver o exemplo DRM abaixo).
  • Multiple <instance> e <regex-instance> elementos dentro da mesma <hal> são avaliados com um único e de relacionamento. (Ver o exemplo DRM abaixo).

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

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

Matriz Manifesto de Correspondência
2.5 2,5-2.∞. Na matriz de compatibilidade, 2.5 é a abreviação para 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 que fornece HAL 2.0-2.4 não é compatível.
  • 2.7 é a versão máxima que pode ser solicitada, o que significa que 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 um exemplo) quando 2.7 é solicitado. O proprietário da matriz de compatibilidade sabe apenas que o serviço solicitado é compatível com a API versão 2.7.
  • -7 é apenas informativo e não afeta o processo de atualização OTA.
Assim, um dispositivo com um HAL na versão 2.10 em seu arquivo de manifesto permanece compatível com um quadro que os estados 2.5-7 em sua matriz de compatibilidade.

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

A matriz de compatibilidade da estrutura declara 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 essas 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

AIDL HALs

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

  • Vários <hal> elementos são avaliados com um único e de relacionamento.
  • Multiple <instance> e <regex-instance> elementos dentro da mesma <hal> são avaliados com um único e de relacionamento. (Ver o exemplo vibrador abaixo).

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

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

Matriz Manifesto de Correspondência
5 5-∞. Na matriz de compatibilidade, 5 é a abreviação para 5-5 .
5-7 5-∞. Indica o seguinte:
  • 5 é a versão mínima exigida, o que significa que um manifesto que fornece 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 um exemplo) quando 7 é solicitado . O proprietário da matriz de compatibilidade sabe apenas que o serviço solicitado é compatível com a API versão 7.
  • -7 é apenas informativo e não afeta o processo de atualização OTA.
Assim, um dispositivo com um HAL na versão 10 em seu arquivo de manifesto permanece compatível com um quadro que os estados 5-7 em sua matriz de compatibilidade.

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

A matriz de compatibilidade da estrutura declara as seguintes informações de versão para vibrador e câmera HALs:

<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 essas 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

Fósforos de kernel

O <kernel> seção da matriz de compatibilidade quadro descreve os requisitos da estrutura do kernel do Linux no dispositivo. Esta informação é para ser comparado com a informação sobre o kernel que é reportado pelo objeto VINTF do dispositivo.

Corresponder aos ramos do kernel

Cada sufixo ramo kernel (por exemplo, 5.4- r ) é mapeado para uma única versão do kernel FCM (por exemplo, 5). O mapeamento é o mesmo que o mapeamento entre cartas de liberação (por exemplo, R) e versões FCM (por exemplo, 5).

Testes VTS impor que o dispositivo especifica explicitamente a versão do kernel FCM no manifesto dispositivo, /vendor/etc/vintf/manifest.xml , se uma das seguintes opções é verdadeira:

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

Os testes VTS garantem 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: Determine o branch do kernel

Se o dispositivo tem alvo FCM versão 4 (lançado em Android 10), mas runs do kernel do 4.19-r ramo, o manifesto do dispositivo deve especificar o seguinte:

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

Os VINTF objeto kernel verifica a compatibilidade em relação aos requisitos de 4.19-r ramo kernel, que é especificado na FCM versão 5. Estes requisitos são construídos a partir de kernel/configs/r/android-4.19 na árvore fonte do Android.

Corresponder às versões do kernel

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

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

O objeto VINTF considera apenas o <kernel> seção do FCM com correspondência versão FCM com o mesmo ${ver} e ${major_rev} como o kernel do dispositivo (ou seja, version="${ver}.${major_rev}.${matrix_minor_rev}") ; outras seções são ignoradas. Além disso, a revisão menor do kernel deve ser um valor a partir da matriz de compatibilidade ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Se nenhuma <kernel> seção atende a esses requisitos, é um não-jogo.

Exemplo: Selecione os requisitos para correspondência

Considere o seguinte caso hipotético em que FCMs em /system/etc/vintf declarar os seguintes requisitos (tags de cabeçalho e rodapé são omitidos):

<!-- 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 kernel do FCM e a versão do kernel, juntas, selecionam os requisitos do kernel dos FCMs:

Versão de destino 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 Páreo (sem 4.19-p ramo kernel)
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) não especificado 4.4.107 Páreo (sem 4.4-q ramo kernel)
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 Páreo (sem 5.4-q ramo kernel)
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 algum Falha de VTS (é necessário especificar a versão do FCM do kernel para a versão 5 do FCM de destino)
5 (R) 4 (Q) algum Falha de VTS (versão do kernel do FCM <versão do FCM de destino)
5 (R) 5 (R) 4.14.180 4.14-r

Corresponder às configurações do kernel

Se o <kernel> seção faz jogo, o processo continua tentando corresponder config elementos contra /proc/config.gz . Para cada elemento de configuração na matriz de compatibilidade, ele olha para cima /proc/config.gz para ver se a configuração estiver presente. Quando um item de configuração está definido para n na matriz de compatibilidade para a correspondência <kernel> seção, ele deve estar ausente do /proc/config.gz . Por fim, um produto de configuração não na matriz de compatibilidade pode ou não estar presente na /proc/config.gz .

Exemplo: corresponder às configurações do kernel

  • <value type="string">bar</value> jogos "bar" . Citações são omitidos na matriz de compatibilidade mas presente em /proc/config.gz .
  • <value type="int">4096</value> corresponde 4096 ou 0x1000 ou 0X1000 .
  • <value type="int">0x1000</value> corresponde 4096 ou 0x1000 ou 0X1000 .
  • <value type="int">0X1000</value> corresponde 4096 ou 0x1000 ou 0X1000 .
  • <value type="tristate">y</value> corresponde y .
  • <value type="tristate">m</value> corresponde m .
  • <value type="tristate">n</value> significa que o item de configuração não deve existir no /proc/config.gz .
  • <value type="range">1-0x3</value> jogos 1 , 2 , ou 3 , ou equivalente hexadecimal.

Exemplo: correspondência de kernel bem-sucedida

Uma matriz de compatibilidade de estrutura com 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>

O branch do kernel é correspondido primeiro. O ramo kernel é especificado no manifesto dispositivo no manifest.kernel.target-level , cujo padrão é manifest.level se o primeiro não é especificado. Se o kernel ramificar no manifesto do dispositivo:

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

Então, a versão do kernel é combinada. Se um dispositivo em uname() relatórios:

  • 4.9.84 (páreo para matriz a menos que haja uma seção do kernel separado com <kernel version="4.9.x"> , onde x <= 84 )
  • 4.14.41 (páreo para matriz, menor do que version )
  • 4.14.42 (corresponder à matriz)
  • 4.14.43 (corresponder à matriz)
  • 4.1.22 (páreo para matriz a menos que haja uma seção do kernel separado com <kernel version="4.1.x"> onde x <= 22 )

Após o apropriado <kernel> seção é selecionado, para cada <config> artigo com valor diferente de n , esperamos que a entrada correspondente a estar presente em /proc/config.gz ; para cada <config> artigo com o valor n , esperamos que a entrada correspondente a não estar presente em /proc/config.gz . Esperamos que o conteúdo de <value> para corresponder exatamente o texto após o sinal de igual (incluindo as aspas), até o caractere de nova linha ou # , com os principais e espaços truncada.

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

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

  • <sepolicy-version> define um conjunto fechado de versões menores para cada versão principal. A versão sepolicy relatada 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 sepolicy for superior ou igual à versão mínima para o intervalo. A versão máxima é puramente informativa.
  • <kernel-sepolicy-version> ie policydb versão. Deve ser menor do que os security_policyvers() relatados pelo dispositivo.

Exemplo: correspondência de política de SE com sucesso

A matriz de compatibilidade da estrutura declara 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 é um jogo. Por exemplo:
    • Se um dispositivo retornar 29, não é uma 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. (A " -3 " depois " 26.0 " é meramente informativo).

A versão 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 mais detalhes, consulte Versões e compatibilidade . A versão do AVB tem as seguintes propriedades do sistema:

  • ro.boot.vbmeta.avb_version é o libavb versão em bootloader
  • ro.boot.avb_version é o libavb versão 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 quadro;
    • 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 quadro.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

O bootloader ou OS Android pode conter duas cópias de libavb bibliotecas, cada um com uma versão diferente MAJOR para dispositivos de atualização e dispositivos de lançamento. Neste caso, a mesma imagem do sistema não assinado pode ser compartilhada, mas as imagens finais do sistema assinados são diferentes (com diferentes avb.vbmeta-version ):

Figura 1. partidas versão BAV ( /system é P, todas as outras divisórias estão ó).


Figura 2. partidas versão BAV (todas as partições são P).

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

A matriz de compatibilidade da estrutura declara as seguintes informações de 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 

Versão AVB correspondente durante OTA

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

Para atenuar o problema, um OEM pode colocar uma versão falsa AVB no pacote OTA ( compatibility.zip ) para passar o cheque. Para fazer isso:

  1. Escolha os seguintes CLs para a árvore de origem do Android 9:
  2. Definir BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE para o dispositivo. Seu valor deve ser igual à versão do AVB anterior ao OTA, ou seja, a versão do AVB do dispositivo quando foi iniciado.
  3. Reconstrua o pacote OTA.

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

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

Estas mudanças não afetam outras matrizes de compatibilidade quadro, incluindo /system/etc/vintf/compatibility_matrix.xml . Após a OTA, o novo valor no /system/etc/vintf/compatibility_matrix.xml é usado para verificações de compatibilidade vez.

A versão VNDK corresponde

A matriz de compatibilidade de dispositivos declara a versão VNDK necessária compatibility-matrix.vendor-ndk.version . Se a matriz de compatibilidade dispositivo não tiver um <vendor-ndk> tag, há exigências são impostas, e, portanto, é sempre considerada uma correspondência.

Se a matriz de compatibilidade do dispositivo faz um Tem <vendor-ndk> tag, um <vendor-ndk> entrada com um correspondente <version> é procurada a partir do conjunto de instantâneos fornecedores VNDK que é fornecido pelo quadro no manifesto quadro. 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 deve ser um subconjunto do conjunto de bibliotecas declaradas no manifesto da estrutura; caso contrário, a entrada não é considerada uma correspondência.

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

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

Se a matriz de compatibilidade do dispositivo declarar 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 da estrutura, 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>

Exemplo Um é um jogo, porque VNDK versão 27 é no manifesto quadro, 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 é compatível. Mesmo que VNDK versão 27 é no manifesto quadro, libjpeg.so não é suportado pela estrutura em que instantâneo. VNDK versão 26 é ignorado.

A versão do SDK do sistema corresponde

A matriz de compatibilidade de dispositivos declara um conjunto de exigido versão do sistema SDK em compatibility-matrix.system-sdk.version . Há uma correspondência apenas se o conjunto é um subconjunto do fornecidas versões Sistema SDK declaradas no manifest.system-sdk.version no manifesto quadro.

  • Como um caso especial, se nenhuma versão do SDK do sistema for enumerada na matriz de compatibilidade do dispositivo, ela sempre será considerada 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 declarar o seguinte requisito no SDK do sistema:

<!-- 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.