Les deux paires de matrices de compatibilité et de manifestes sont destinées à être réconciliées pour vérifier que l'implémentation du framework et du fournisseur peut fonctionner ensemble. Cette vérification réussit en cas de correspondance entre la matrice de compatibilité du framework et le manifeste de l'appareil, ainsi qu'entre le manifeste du framework et la matrice de compatibilité de l'appareil.
Cette vérification est effectuée au moment de la construction, au moment de la génération du package de mise à jour OTA , au démarrage et dans les tests de compatibilité VTS.
Les sections suivantes détaillent les règles de correspondance utilisées par divers composants.
La version de la matrice de compatibilité du framework correspond
Pour faire correspondre un manifeste d'appareil avec une matrice de compatibilité de framework, la version Shipping FCM spécifiée par manifest.target-level doit être exactement égale à la version FCM spécifiée par compatibility-matrix.level . Sinon, il n'y a pas de correspondance.
Lorsque la matrice de compatibilité du framework est demandée avec libvintf , cette correspondance réussit toujours car libvintf ouvre le manifeste de l'appareil, récupère la version FCM d'expédition et renvoie la matrice de compatibilité du framework à cette version FCM d'expédition (plus quelques HAL facultatives des matrices de compatibilité à FCM supérieur versions).
Matchs HAL
La règle de correspondance HAL identifie les versions des éléments hal dans un fichier manifeste qui sont considérées comme prises en charge par le propriétaire de la matrice de compatibilité correspondante.
HIDL et HAL natifs
Les règles de correspondance pour HIDL et les HAL natifs sont les suivantes.
- Plusieurs éléments
<hal>sont évalués avec une seule relation ET . - Les éléments
<hal>peuvent avoir<hal optional="true">pour les marquer comme non requis. - Plusieurs éléments
<version>dans le même<hal>ont la relation OR . Si deux ou plusieurs sont spécifiés, une seule des versions doit être implémentée. (Voir l' exemple DRM ci-dessous.) - Plusieurs éléments
<instance>et<regex-instance>dans le même<hal>sont évalués avec une seule relation AND lorsque<hal>est requis. (Voir le
Exemple : correspondance HAL réussie pour un module
Pour une HAL en version 2.5, la règle de correspondance est la suivante :
| Matrice | Manifeste correspondant |
|---|---|
2.5 | 2.5-2.∞. Dans la matrice de compatibilité, 2.5 est le raccourci de 2.5-5 . |
2.5-7 | 2.5-2.∞. Indique ce qui suit :
2.5-7 dans sa matrice de compatibilité. |
Exemple : correspondance HAL réussie pour le module DRM
La matrice de compatibilité du framework indique les informations de version suivantes pour 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>
Un fournisseur doit implémenter UNE des instances suivantes ; Soit
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
ET doit également implémenter toutes ces instances :
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 HAL
Toutes les versions d'Android ultérieures à Android 11 (à l'exception d'Android 11) prennent en charge les versions pour AIDL HAL dans VINTF. Les règles de correspondance pour les HAL AIDL sont similaires à celles des HAL HIDL et natifs, sauf qu'il n'y a pas de versions majeures et qu'il existe exactement une version par instance HAL ( 1 si la version n'est pas spécifiée).
- Plusieurs éléments
<hal>sont évalués avec une seule relation ET . - Les éléments
<hal>peuvent avoir<hal optional="true">pour les marquer comme non requis. - Plusieurs éléments
<instance>et<regex-instance>dans le même<hal>sont évalués avec une seule relation AND lorsque<hal>est requis. (Voir le
Exemple : correspondance HAL réussie pour un module
Pour une HAL en version 5, la règle de correspondance est la suivante :
| Matrice | Manifeste correspondant |
|---|---|
5 | 5-∞. Dans la matrice de compatibilité, 5 est le raccourci pour 5-5 . |
5-7 | 5-∞. Indique ce qui suit :
5-7 dans sa matrice de compatibilité. |
Exemple : correspondance HAL réussie pour plusieurs modules
La matrice de compatibilité du framework indique les informations de version suivantes pour les HAL de vibreur et de caméra :
<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>
Un fournisseur doit implémenter toutes ces instances :
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
Correspondances du noyau
La section <kernel> de la matrice de compatibilité du framework décrit les exigences du framework du noyau Linux sur le périphérique. Ces informations sont destinées à être comparées aux informations sur le noyau qui sont signalées par l'objet VINTF du périphérique.
Faire correspondre les branches du noyau
Chaque suffixe de branche du noyau (par exemple, 5.4- r ) est mappé à une version FCM du noyau unique (par exemple, 5). Le mappage est le même que le mappage entre les lettres de version (par exemple, R) et les versions FCM (par exemple, 5).
Les tests VTS imposent que l'appareil spécifie explicitement la version FCM du noyau dans le manifeste de l'appareil, /vendor/etc/vintf/manifest.xml , si l'une des conditions suivantes est vraie :
- La version FCM du noyau est différente de la version FCM cible. Par exemple, le périphérique susmentionné a une version FCM cible 4 et sa version FCM du noyau est 5 (suffixe de branche du noyau
r). - La version FCM du noyau est supérieure ou égale à 5 (suffixe de branche du noyau
r).
Les tests VTS imposent que, si la version FCM du noyau est spécifiée, la version FCM du noyau est supérieure ou égale à la version FCM cible dans le manifeste de l'appareil.
Exemple : déterminer la branche du noyau
Si l'appareil dispose de la version 4 de FCM cible (publiée dans Android 10), mais exécute le noyau à partir de la branche 4.19-r , le manifeste de l'appareil doit spécifier les éléments suivants :
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
L'objet VINTF vérifie la compatibilité du noyau par rapport aux exigences sur la branche du noyau 4.19-r , qui est spécifiée dans la version 5 de FCM. Ces exigences sont construites à partir de kernel/configs/r/android-4.19 dans l'arborescence source Android.
Exemple : déterminer la branche du noyau pour GKI
Si le périphérique utilise l'image générique du noyau (GKI) et que la chaîne de version du noyau de /proc/version est la suivante :
5.4.42-android12-0-00544-ged21d463f856
Ensuite, l'objet VINTF obtient la version Android à partir de la version du noyau et l'utilise pour déterminer la version FCM du noyau. Dans cet exemple, android12 signifie kernel FCM version 6 (publié dans Android 12).
Pour plus de détails sur la façon dont la chaîne de version du noyau est analysée, consultez Gestion des versions GKI .
Faire correspondre les versions du noyau
Une matrice peut inclure plusieurs sections <kernel> , chacune avec un attribut de version différent utilisant le format :
${ver}.${major_rev}.${kernel_minor_rev} L'objet VINTF considère uniquement la section <kernel> du FCM avec la version FCM correspondante avec les mêmes ${ver} et ${major_rev} que le noyau de l'appareil (c'est-à-dire version="${ver}.${major_rev}.${matrix_minor_rev}") ; les autres sections sont ignorées. De plus, la révision mineure du noyau doit être une valeur de la matrice de compatibilité ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Si aucune section <kernel> ne répond à ces exigences, il s'agit d'une non-correspondance.
Exemple : sélectionner les exigences de correspondance
Considérez le cas hypothétique suivant où les FCM dans /system/etc/vintf déclarent les exigences suivantes (les balises d'en-tête et de pied de page sont omises) :
<!-- 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 -->
La version FCM cible, la version FCM du noyau et la version du noyau sélectionnent ensemble les exigences du noyau à partir des FCM :
| Version FCM cible | Version FCM du noyau | Version du noyau | Correspond avec |
|---|---|---|---|
| 3 (P) | non spécifié | 4.4.106 | Aucune correspondance (incompatibilité de version mineure) |
| 3 (P) | non spécifié | 4.4.107 | 4.4-p |
| 3 (P) | non spécifié | 4.19.42 | 4.19-q (voir note ci-dessous) |
| 3 (P) | non spécifié | 5.4.41 | 5.4-r (voir note ci-dessous) |
| 3 (P) | 3 (P) | 4.4.107 | 4.4-p |
| 3 (P) | 3 (P) | 4.19.42 | Aucune correspondance (pas de branche de noyau 4.19-p ) |
| 3 (P) | 4 (Q) | 4.19.42 | 4.19-q |
| 4 (Q) | non spécifié | 4.4.107 | Aucune correspondance (pas de branche de noyau 4.4-q ) |
| 4 (Q) | non spécifié | 4.9.165 | 4.9-q |
| 4 (Q) | non spécifié | 5.4.41 | 5.4-r (voir note ci-dessous) |
| 4 (Q) | 4 (Q) | 4.9.165 | 4.9-q |
| 4 (Q) | 4 (Q) | 5.4.41 | Aucune correspondance (pas de branche de noyau 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) | non spécifié | n'importe quel | VTS échoue (doit spécifier la version FCM du noyau pour la cible FCM version 5) |
| 5 (R) | 4 (Q) | n'importe quel | VTS échoue (version FCM du noyau < version FCM cible) |
| 5 (R) | 5 (R) | 4.14.180 | 4.14-r |
Faire correspondre les configurations du noyau
Si la section <kernel> correspond, le processus continue en essayant de faire correspondre les éléments de config avec /proc/config.gz . Pour chaque élément de configuration dans la matrice de compatibilité, il recherche /proc/config.gz pour voir si la configuration est présente. Lorsqu'un élément de configuration est défini sur n dans la matrice de compatibilité pour la section <kernel> correspondante, il doit être absent de /proc/config.gz . Enfin, un élément de configuration ne figurant pas dans la matrice de compatibilité peut ou non être présent dans /proc/config.gz .
Exemple : faire correspondre les configurations du noyau
-
<value type="string">bar</value>correspond à"bar". Les guillemets sont omis dans la matrice de compatibilité mais présents dans/proc/config.gz. -
<value type="int">4096</value>correspond à4096ou0x1000ou0X1000. -
<value type="int">0x1000</value>correspond à4096ou0x1000ou0X1000. -
<value type="int">0X1000</value>correspond à4096ou0x1000ou0X1000. -
<value type="tristate">y</value>correspond ày. -
<value type="tristate">m</value>correspond àm. -
<value type="tristate">n</value>signifie que l'élément de configuration ne doit PAS exister dans/proc/config.gz. -
<value type="range">1-0x3</value>correspond à1,2ou3, ou équivalent hexadécimal.
Exemple : correspondance de noyau réussie
Une matrice de compatibilité de framework avec FCM version 1 contient les informations suivantes sur le noyau :
<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>
La branche du noyau est mise en correspondance en premier. La branche du noyau est spécifiée dans le manifeste de l'appareil dans manifest.kernel.target-level , qui par défaut est manifest.level si le premier n'est pas spécifié. Si la branche du noyau dans le manifeste de l'appareil :
- est 1, passe à l'étape suivante et vérifie la version du noyau.
- est 2, pas de correspondance avec la matrice. Les objets VINTF lisent les exigences du noyau à partir de la matrice à la version 2 de FCM à la place.
Ensuite, la version du noyau est mise en correspondance. Si un périphérique dans uname() signale :
- 4.9.84 (aucune correspondance avec la matrice à moins qu'il n'y ait une section distincte du noyau avec
<kernel version="4.9.x">, oùx <= 84) - 4.14.41 (pas de correspondance avec la matrice, plus petite que la
version) - 4.14.42 (correspondance à la matrice)
- 4.14.43 (correspondance à la matrice)
- 4.1.22 (aucune correspondance avec la matrice à moins qu'il n'y ait une section distincte du noyau avec
<kernel version="4.1.x">oùx <= 22)
Une fois la section <kernel> appropriée sélectionnée, pour chaque élément <config> avec une valeur autre que n , nous nous attendons à ce que l'entrée correspondante soit présente dans /proc/config.gz ; pour chaque élément <config> avec la valeur n , nous nous attendons à ce que l'entrée correspondante ne soit pas présente dans /proc/config.gz . Nous nous attendons à ce que le contenu de <value> corresponde exactement au texte après le signe égal (y compris les guillemets), jusqu'au caractère de nouvelle ligne ou # , avec des espaces blancs de début et de fin tronqués.
La configuration de noyau suivante est un exemple de correspondance réussie :
# 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"
La configuration de noyau suivante est un exemple de correspondance infructueuse :
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
Correspondances de la politique SE
La stratégie SE requiert les correspondances suivantes :
-
<sepolicy-version>définit une plage fermée de versions mineures pour chaque version majeure. La version de sepolicy signalée par l'appareil doit être comprise dans l'une de ces plages pour être compatible avec le framework. Les règles de correspondance sont similaires aux versions HAL ; il s'agit d'une correspondance si la version de sepolicy est supérieure ou égale à la version minimale de la plage. La version maximale est purement informative. -
<kernel-sepolicy-version>c'est-à-dire la version de policydb. Doit être inférieur ausecurity_policyvers()signalé par l'appareil.
Exemple : Correspondance de stratégie SE réussie
La matrice de compatibilité du framework indique les informations de stratégie suivantes :
<sepolicy>
<kernel-sepolicy-version>30</kernel-sepolicy-version>
<sepolicy-version>25.0</sepolicy-version>
<sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>
Sur l'appareil :
- La valeur renvoyée par
security_policyvers()doit être supérieure ou égale à 30. Sinon, ce n'est pas une correspondance. Par exemple:- Si un appareil renvoie 29, ce n'est pas une correspondance.
- Si un appareil renvoie 31, il s'agit d'une correspondance.
- La version de la politique SE doit être l'une des 25.0-∞ ou 26.0-∞. Sinon ce n'est pas un match. (Le "
-3" après "26.0" est purement informatif.)
La version AVB correspond
La version AVB contient une version MAJEURE et une version MINEUR, avec le format MAJEUR.MINEUR (par exemple, 1.0, 2.1). Pour plus de détails, reportez-vous à Gestion des versions et compatibilité . La version AVB a les propriétés système suivantes :
-
ro.boot.vbmeta.avb_versionest la version delibavbdans le bootloader -
ro.boot.avb_versionest la version delibavbdans le système d'exploitation Android (init/fs_mgr)
La propriété système apparaît uniquement lorsque la libavb correspondante a été utilisée pour vérifier les métadonnées AVB (et renvoie OK). Il est absent si un échec de vérification s'est produit (ou si aucune vérification ne s'est produite).
Une correspondance de compatibilité compare les éléments suivants :
- sysprop
ro.boot.vbmeta.avb_versionavecavb.vbmeta-versionde la matrice de compatibilité du 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_versionavecavb.vbmeta-versionde la matrice de compatibilité du framework.-
ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR -
ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR
-
Le chargeur de démarrage ou le système d'exploitation Android peut contenir deux copies des bibliothèques libavb , chacune avec une version MAJEURE différente pour les périphériques de mise à niveau et les périphériques de lancement. Dans ce cas, la même image système non signée peut être partagée mais les images système signées finales sont différentes (avec différents avb.vbmeta-version ):
/system est P, toutes les autres partitions sont O).
Exemple : correspondance de version AVB réussie
La matrice de compatibilité du framework indique les informations AVB suivantes :
<avb>
<vbmeta-version>2.1</vbmeta-version>
</avb>
Sur l'appareil :
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
Version AVB correspondante pendant l'OTA
Pour les appareils lancés avec Android 9 ou une version antérieure, lors de la mise à jour vers Android 10, les exigences de version AVB dans la matrice de compatibilité du cadre sont comparées à la version AVB actuelle sur l'appareil. Si la version AVB a une mise à jour de version majeure lors d'un OTA (par exemple, de 0.0 à 1.0), la vérification de compatibilité VINTF dans OTA ne reflète pas la compatibilité après l'OTA.
Pour atténuer le problème, un OEM peut placer une fausse version AVB dans le package OTA ( compatibility.zip ) pour réussir la vérification. Faire cela:
- Sélectionnez les CL suivants dans l'arborescence source d'Android 9 :
- Définissez
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDEpour l'appareil. Sa valeur doit être égale à la version AVB avant l'OTA, c'est-à-dire la version AVB de l'appareil lors de son lancement. - Reconstruisez le package OTA.
Ces modifications placent automatiquement BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE en tant que compatibility-matrix.avb.vbmeta-version dans les fichiers suivants :
-
/system/compatibility_matrix.xml(qui n'est pas utilisé dans Android 9) sur l'appareil -
system_matrix.xmldanscompatibility.zipdans le package OTA
Ces modifications n'affectent pas les autres matrices de compatibilité du framework, y compris /system/etc/vintf/compatibility_matrix.xml . Après l'OTA, la nouvelle valeur dans /system/etc/vintf/compatibility_matrix.xml est utilisée pour les vérifications de compatibilité à la place.
La version VNDK correspond
La matrice de compatibilité des appareils déclare la version VNDK requise dans compatibility-matrix.vendor-ndk.version . Si la matrice de compatibilité des appareils n'a pas de <vendor-ndk> , aucune exigence n'est imposée et, par conséquent, elle est toujours considérée comme une correspondance.
Si la matrice de compatibilité des appareils comporte une <vendor-ndk> , une entrée <vendor-ndk> avec une <version> correspondante est recherchée dans l'ensemble d'instantanés de fournisseur VNDK fourni par le framework dans le manifeste du framework. Si une telle entrée n'existe pas, il n'y a pas de correspondance.
Si une telle entrée existe, l'ensemble des bibliothèques énumérées dans la matrice de compatibilité des périphériques doit être un sous-ensemble de l'ensemble des bibliothèques indiqué dans le manifeste du framework ; sinon, l'entrée n'est pas considérée comme une correspondance.
- Dans un cas particulier, si aucune bibliothèque n'est énumérée dans la matrice de compatibilité des périphériques, l'entrée est toujours considérée comme une correspondance, car l'ensemble vide est un sous-ensemble de n'importe quel ensemble.
Exemple : correspondance de version VNDK réussie
Si la matrice de compatibilité des appareils indique l'exigence suivante sur VNDK :
<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
<version>27</version>
<library>libjpeg.so</library>
<library>libbase.so</library>
</vendor-ndk>
Dans le manifeste du framework, seule l'entrée avec la version 27 est prise en compte.
<!-- Framework Manifest Example A -->
<vendor-ndk>
<version>27</version>
<library>libjpeg.so</library>
<library>libbase.so</library>
<library>libfoo.so</library>
</vendor-ndk>
L'exemple A est une correspondance, car VNDK version 27 est dans le manifeste du framework, et {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>
L'exemple B ne correspond pas. Même si VNDK version 27 se trouve dans le manifeste du framework, libjpeg.so n'est pas pris en charge par le framework dans cet instantané. VNDK version 26 est ignoré.
La version du SDK système correspond
La matrice de compatibilité des appareils déclare un ensemble de versions requises du SDK système dans compatibility-matrix.system-sdk.version . Il n'y a de correspondance que si l'ensemble est un sous-ensemble de versions du SDK système fournies, comme déclaré dans manifest.system-sdk.version dans le manifeste du framework.
- Dans un cas particulier, si aucune version du SDK système n'est énumérée dans la matrice de compatibilité des appareils, cela est toujours considéré comme une correspondance, car un ensemble vide est un sous-ensemble de n'importe quel ensemble.
Exemple : Correspondance réussie de la version du SDK système
Si la matrice de compatibilité des appareils indique l'exigence suivante sur le SDK système :
<!-- Example Device Compatibility Matrix -->
<system-sdk>
<version>26</version>
<version>27</version>
</system-sdk>
Ensuite, le framework doit fournir les versions 26 et 27 du SDK système pour correspondre.
<!-- Framework Manifest Example A -->
<system-sdk>
<version>26</version>
<version>27</version>
</system-sdk>
L'exemple A est une correspondance.
<!-- Framework Manifest Example B -->
<system-sdk>
<version>26</version>
<version>27</version>
<version>28</version>
</system-sdk>
L'exemple B correspond.
<!-- Framework Manifest Example C -->
<system-sdk>
<version>26</version>
</system-sdk>
L'exemple C ne correspond pas, car la version 27 du SDK système n'est pas fournie.