Règles de correspondance

Les deux paires de matrices de compatibilité et de manifestes sont destinées à être réconciliées pour vérifier que le framework et l'implémentation du fournisseur peuvent fonctionner l'un avec l'autre. Cette vérification réussit suite à une correspondance entre la matrice de compatibilité du framework et le manifeste du périphérique, ainsi qu'entre le manifeste du framework et la matrice de compatibilité du périphérique.

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 moment du démarrage et lors des tests de compatibilité VTS.

Les sections suivantes détaillent les règles de correspondance utilisées par divers composants.

Correspondances de version de la matrice de compatibilité du framework

Pour faire correspondre un manifeste de périphérique avec une matrice de compatibilité de structure, 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 du périphérique, 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 facultatifs des matrices de compatibilité à un FCM supérieur Versions).

Matchs HAL

La règle HAL-match 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 AND .
  • Les éléments <hal> peuvent avoir <hal optional="true"> pour les marquer comme non requis.
  • Plusieurs éléments <version> au sein du même <hal> ont la relation OR . Si deux versions ou plus sont spécifiées, une seule des versions doit être implémentée. (Voir l' exemple DRM ci-dessous.)
  • Plusieurs éléments <instance> et <regex-instance> au sein du même <hal> sont évalués avec une seule relation AND lorsque le <hal> est requis. (Voir le Exemple de DRM ci-dessous.)

Exemple : correspondance HAL réussie pour un module

Pour un 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 pour 2.5-5 .
2.5-7 2.5-2.∞. Indique ce qui suit :
  • 2.5 est la version minimale requise, ce qui signifie qu'un manifeste fournissant HAL 2.0-2.4 n'est pas compatible.
  • 2.7 est la version maximale qui peut être demandée, ce qui signifie que le propriétaire de la matrice de compatibilité (framework ou périphérique) ne demandera pas de versions au-delà de 2.7. Le propriétaire du manifeste correspondant peut toujours servir la version 2.10 (à titre d'exemple) lorsque la version 2.7 est demandée. Le propriétaire de la matrice de compatibilité sait uniquement que le service demandé est compatible avec l'API version 2.7.
  • -7 est uniquement informatif et n’affecte pas le processus de mise à jour OTA.
Ainsi, un appareil avec un HAL en version 2.10 dans son fichier manifeste reste compatible avec un framework qui indique 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 mettre en œuvre UNE des instances suivantes : soit

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

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 les HAL AIDL dans VINTF. Les règles de correspondance pour les HAL AIDL sont similaires à celles des HIDL et des HAL 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 AND .
  • Les éléments <hal> peuvent avoir <hal optional="true"> pour les marquer comme non requis.
  • Plusieurs éléments <instance> et <regex-instance> au sein du même <hal> sont évalués avec une seule relation AND lorsque le <hal> est requis. (Voir le exemple de vibrateur ci-dessous.)

Exemple : correspondance HAL réussie pour un module

Pour un 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 est la version minimale requise, ce qui signifie qu'un manifeste fournissant HAL 1-4 n'est pas compatible.
  • 7 est la version maximale qui peut être demandée, ce qui signifie que le propriétaire de la matrice de compatibilité (framework ou périphérique) ne demandera pas de versions au-delà de 7. Le propriétaire du manifeste correspondant peut toujours servir la version 10 (à titre d'exemple) lorsque 7 est demandé . Le propriétaire de la matrice de compatibilité sait uniquement que le service demandé est compatible avec l'API version 7.
  • -7 est uniquement informatif et n’affecte pas le processus de mise à jour OTA.
Ainsi, un appareil avec un HAL en version 10 dans son fichier manifeste reste compatible avec un framework qui indique 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 vibrateur 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 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 le périphérique spécifie explicitement la version FCM du noyau dans le manifeste du périphérique, /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 la version FCM de son 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 soit supérieure ou égale à la version FCM cible dans le manifeste du périphérique.

Exemple : Déterminer la branche du noyau

Si l'appareil dispose de la version cible FCM 4 (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 de la branche du noyau 4.19-r , spécifiée dans la version 5 de FCM. Ces exigences sont construites à partir de kernel/configs/r/android-4.19 dans l'arborescence des sources 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 la version 6 du noyau FCM (publiée 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 version différent en 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 du périphérique (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électionnez les exigences de correspondance

Considérons 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é mineure de version)
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 du 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 du 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 du 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 lequel VTS échoue (doit spécifier la version FCM du noyau pour la version 5 du FCM cible)
5 (R) 4 (Q) n'importe lequel Échec de VTS (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 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 être présent ou non 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 à 4096 ou 0x1000 ou 0X1000 .
  • <value type="int">0x1000</value> correspond à 4096 ou 0x1000 ou 0X1000 .
  • <value type="int">0X1000</value> correspond à 4096 ou 0x1000 ou 0X1000 .
  • <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 , 2 ou 3 , ou équivalent hexadécimal.

Exemple : correspondance de noyau réussie

Une matrice de compatibilité du framework avec FCM version 1 contient les informations de noyau suivantes :

<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 du périphérique dans manifest.kernel.target-level , qui est par défaut manifest.level si le premier n'est pas spécifié. Si la branche du noyau dans le manifeste du périphérique :

  • est 1, passe à l'étape suivante et vérifie la version du noyau.
  • est 2, aucune correspondance avec la matrice. Les objets VINTF lisent plutôt les exigences du noyau à partir de la matrice de la version 2 de FCM.

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 sauf s'il existe une section de noyau distincte avec <kernel version="4.9.x"> , où x <= 84 )
  • 4.14.41 (aucune correspondance avec la matrice, plus petite que version )
  • 4.14.42 (correspondance à la matrice)
  • 4.14.43 (correspondance à la matrice)
  • 4.1.22 (pas de correspondance avec la matrice sauf s'il existe une section de noyau distincte 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 les espaces 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 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 la stratégie de sécurité signalée par l'appareil doit se situer 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 la stratégie 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 la base de données de politique. Doit être inférieur à la valeur security_policyvers() signalée par l'appareil.

Exemple : correspondance de politique SE réussie

La matrice de compatibilité du framework indique les informations de politique de sécurité 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, c'est 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 MINEURE, au format MAJOR.MINOR (par exemple, 1.0, 2.1). Pour plus de détails, reportez-vous à Gestion des versions et compatibilité . La version AVB possède les propriétés système suivantes :

  • ro.boot.vbmeta.avb_version est la version libavb dans le chargeur de démarrage
  • ro.boot.avb_version est la version libavb dans le système d'exploitation Android ( init/fs_mgr )

La propriété système apparaît uniquement lorsque le libavb correspondant a été utilisé 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 n'a eu lieu).

Une correspondance de compatibilité compare les éléments suivants :

  • sysprop ro.boot.vbmeta.avb_version avec avb.vbmeta-version de 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_version avec avb.vbmeta-version de 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 appareils de mise à niveau et 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 avb.vbmeta-version ) différentes :

Figure 1. Correspondances de version AVB ( /system est P, toutes les autres partitions sont O).


Figure 2. Correspondances de version AVB (toutes les partitions sont P).

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 framework sont comparées à la version AVB actuelle sur l'appareil. Si la version AVB a une mise à niveau majeure lors d'une OTA (par exemple, de 0.0 à 1.0), la vérification VINTF de compatibilité 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:

  1. Sélectionnez les CL suivantes dans l'arborescence des sources d'Android 9 :
  2. Définissez BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE pour le périphérique. Sa valeur doit être égale à la version AVB avant l'OTA, c'est-à-dire la version AVB de l'appareil au moment de son lancement.
  3. 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.xml dans compatibility.zip dans le package OTA

Ces modifications n'affectent pas les autres matrices de compatibilité du framework, notamment /system/etc/vintf/compatibility_matrix.xml . Après l'OTA, la nouvelle valeur dans /system/etc/vintf/compatibility_matrix.xml est utilisée à la place pour les vérifications de compatibilité.

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 ne comporte pas de balise <vendor-ndk> , aucune exigence n'est imposée et est donc toujours considérée comme une correspondance.

Si la matrice de compatibilité des appareils comporte une balise <vendor-ndk> , une entrée <vendor-ndk> avec une <version> correspondante est recherchée dans l'ensemble d'instantanés du fournisseur VNDK fourni par l'infrastructure dans le manifeste de l'infrastructure. 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 appareils 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.

  • 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 un 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 correspond, car la version 27 du VNDK se trouve 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 la version 27 de VNDK figure dans le manifeste du framework, libjpeg.so n'est pas pris en charge par le framework dans cet instantané. La version 26 de VNDK est ignorée.

La version du SDK système correspond

La matrice de compatibilité des appareils déclare un ensemble de versions du SDK système requises dans compatibility-matrix.system-sdk.version . Il n'y a de correspondance que si l'ensemble est un sous-ensemble des 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 correspondant.

<!-- 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 est une correspondance.

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