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:
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 >= 0OU
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-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 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 |
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ências4096
,0x1000
ou0X1000
.<value type="int">0x1000</value>
correspondências4096
,0x1000
ou0X1000
.<value type="int">0X1000</value>
correspondências4096
,0x1000
ou0X1000
.<value type="tristate">y</value>
correspondênciasy
.<value type="tristate">m</value>
correspondênciasm
.<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ências1
,2
ou3
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 quex <= 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 quex <= 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 asecurity_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ãolibavb
no carregador de inicializaçãoro.boot.avb_version
é a versãolibavb
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
comavb.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
comavb.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:
- 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 dispositivosystem_matrix.xml
emcompatibility.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.