Règles de correspondance

Les deux paires de matrices et de fichiers manifestes de compatibilité doivent être réconciliées pour vérifier que le framework et l'implémentation du fournisseur peuvent fonctionner ensemble. Cette vérification réussit une correspondance entre la matrice de compatibilité du framework et le fichier manifeste de l'appareil, ainsi qu'entre le fichier manifeste du framework et la matrice de compatibilité des appareils.

Cette vérification est effectuée au moment de la compilation, au moment de la génération du package de mise à jour OTA, au démarrage et lors des tests de compatibilité VTS.

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

Correspondance des versions de la matrice de compatibilité du framework

Pour faire correspondre un fichier manifeste d'appareil à une matrice de compatibilité de framework, la version FCM de distribution 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 est toujours réussie, car libvintf ouvre le fichier manifeste de l'appareil, récupère la version de FCM de distribution et renvoie la matrice de compatibilité du framework à cette version de FCM de distribution (plus certains HAL facultatifs à partir de matrices de compatibilité à des versions FCM supérieures).

Correspondances HAL

La règle HAL-match identifie les versions des éléments hal dans un fichier manifeste qui sont considérées comme compatibles par le propriétaire de la matrice de compatibilité correspondante.

HAL HIDL et natives

Les règles de correspondance pour HIDL et les HAL natives sont les suivantes.

  • Plusieurs éléments <hal> sont évalués avec une seule relation ET.
  • Les éléments <hal> peuvent comporter <hal optional="true"> pour les marquer comme non obligatoires.
  • Plusieurs éléments <version> du même <hal> ont une relation OU. Si vous en spécifiez deux ou plus, seule l'une des versions doit être implémentée. (Voir l'exemple de DRM ci-dessous.)
  • Plusieurs éléments <instance> et <regex-instance> au sein d'un même <hal> sont évalués avec une seule relation ET lorsque l'<hal> est obligatoire. (Voir l'<ahref="#drm">exemple de DRM ci-dessous.)</ahref="#drm">

Exemple: Correspondance HAL réussie pour un module

Pour une version 2.5 du HAL, la règle de correspondance est la suivante:

Grille Fichier manifeste correspondant
2.5 2.5-2.∞. Dans la matrice de compatibilité, 2.5 est l'abréviation de 2.5-5.
2.5-7 2,5-2,∞. Indique ce qui suit :
  • La version 2.5 est la version minimale requise, ce qui signifie qu'un fichier manifeste fournissant HAL 2.0 à 2.4 n'est pas compatible.
  • 2.7 est la version maximale pouvant être demandée, ce qui signifie que le propriétaire de la matrice de compatibilité (framework ou appareil) ne demandera pas de versions ultérieures à 2.7. Le propriétaire du fichier manifeste correspondant peut toujours diffuser la version 2.10 (par exemple) lorsque la version 2.7 est demandée. Le propriétaire de la matrice de compatibilité ne sait que le service demandé est compatible avec la version 2.7 de l'API.
  • -7 est à titre informatif uniquement et n'a aucune incidence sur le processus de mise à jour OTA.
Ainsi, un appareil dont le fichier manifeste contient une HAL version 2.10 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 le HAL 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>

Un fournisseur doit implémenter l'une des instances suivantes :

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

HAL AIDL

Toutes les versions d'Android postérieures à Android 11 (à l'exception d'Android 11) sont compatibles avec les versions des HAL AIDL dans VINTF. Les règles de correspondance pour les HAL AIDL sont similaires à celles des HAL HIDL et natives, à l'exception qu'il n'y a pas de versions majeures et qu'il n'y a qu'une seule 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 comporter <hal optional="true"> pour les marquer comme non obligatoires.
  • Plusieurs éléments <instance> et <regex-instance> au sein d'un même <hal> sont évalués avec une seule relation AND lorsque l'élément <hal> est requis. (Voir l'<ahref="#vibrator">exemple de vibreur ci-dessous.)</ahref="#vibrator">

Exemple: Correspondance HAL réussie pour un module

Pour une version 5 du HAL, la règle de correspondance est la suivante:

Grille Fichier manifeste correspondant
5 5-∞. Dans la matrice de compatibilité, 5 est l'abréviation de 5-5.
5-7 5-∞ : indique ce qui suit :
  • 5 est la version minimale requise, ce qui signifie qu'un fichier manifeste fournissant une version 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 appareil) ne demandera pas les versions supérieures à 7. Le propriétaire du fichier manifeste correspondant peut toujours diffuser la version 10 (par exemple) lorsque la version 7 est demandée. Le propriétaire de la matrice de compatibilité sait uniquement que le service demandé est compatible avec la version 7 de l'API.
  • -7 est à titre informatif uniquement et n'a aucune incidence sur le processus de mise à jour OTA.
Ainsi, un appareil avec un HAL de 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 du vibreur et de la 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 de noyau

La section <kernel> de la matrice de compatibilité du framework décrit les exigences du framework concernant le noyau Linux sur l'appareil. Ces informations doivent être mises en correspondance avec les informations sur le noyau transmises par l'objet VINTF de l'appareil.

Faire correspondre les branches du noyau

Chaque suffixe de branche de kernel (par exemple, 5.4-r) est mappé sur une version FCM de kernel unique (par exemple, 5). Le mappage est le même que celui entre les lettres de publication (par exemple, R) et les versions FCM (par exemple, 5).

Les tests VTS exigent que l'appareil spécifie explicitement la version FCM du noyau dans le fichier manifeste de l'appareil, /vendor/etc/vintf/manifest.xml, si l'une des conditions suivantes est remplie:

  • La version FCM du kernel est différente de la version FCM cible. Par exemple, l'appareil mentionné ci-dessus 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 la branche du noyau r).

Les tests VTS exigent que, si la version FCM du noyau est spécifiée, celle-ci est supérieure ou égale à la version FCM cible indiquée dans le fichier 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 qu'il exécute le noyau à partir de la branche 4.19-r, le fichier 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 de noyau 4.19-r, spécifiée dans la version 5 de FCM. Ces exigences sont créées à partir de kernel/configs/r/android-4.19 dans l'arborescence source Android.

Exemple: Déterminer la branche du kernel pour GKI

Si l'appareil utilise l'image de noyau générique (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 kernel et l'utilise pour déterminer la version FCM du kernel. Dans cet exemple, android12 signifie la version 6 du kernel FCM (publiée dans Android 12).

Pour en savoir plus sur l'analyse de la chaîne de version du kernel, consultez la section Gestion des versions de GKI.

Correspondre aux versions du noyau

Une matrice peut inclure plusieurs sections <kernel>, chacune avec un attribut version différent, au format suivant:

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

L'objet VINTF ne prend en compte que la section <kernel> de FCM avec la version de FCM correspondante avec les mêmes ${ver} et ${major_rev} que le noyau de l'appareil (par exemple, 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 n'y a pas de correspondance.

Exemple: Sélectionner les conditions requises pour la mise en 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 kernel et la version du kernel sélectionnent ensemble les exigences du kernel à partir des FCM:

Version cible de FCMVersion du kernel FCMVersion de noyauCorrespondre à
3 (P)non spécifié4.4.106 Aucune correspondance (non-concordance des versions mineures)
3 (P)non spécifié4.4.107 4.4-p
3 (P)non spécifié4.19.42 4.19-q (voir la remarque ci-dessous)
3 (P)non spécifié5.4.41 5.4-r (voir la remarque ci-dessous)
3 (P)3 (P) 4.4.107 4.4-p
3 (P)3 (P) 4.19.42 Aucune correspondance (aucune 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 (aucune branche du kernel 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 la remarque ci-dessous)
4 (Q)4 (Q) 4.9.165 4.9-q
4 (Q)4 (Q) 5.4.41 Aucune correspondance (aucune branche du kernel 5.4-q)
4 (Q)5 (R) 4.14.1054.14-r
4 (Q)5 (R) 5.4.41 5.4-r
5 (R)non spécifiétout Échec de VTS (vous devez spécifier la version FCM du noyau pour la version FCM cible 5)
5 (R)4 (Q) tout Échec de VTS (version FCM du noyau < version FCM cible)
5 (R)5 (R) 4.14.1804.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 à /proc/config.gz. Pour chaque élément de configuration de 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é de la section <kernel> correspondante, il doit être absent de /proc/config.gz. Enfin, un élément de configuration qui ne figure pas dans la matrice de compatibilité peut être présent ou non dans /proc/config.gz.

Exemple: faire correspondre les configurations de 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, 0x1000 ou 0X1000.
  • <value type="int">0x1000</value> correspond à 4096, 0x1000 ou 0X1000.
  • <value type="int">0X1000</value> correspond à 4096, 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 à l'équivalent hexadécimal.

Exemple: Correspondance du kernel réussie

Une matrice de compatibilité du framework avec la version 1 de FCM 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 fichier manifeste de l'appareil sous manifest.kernel.target-level. La valeur par défaut est manifest.level si l'ancienne branche n'est pas spécifiée. Si la branche du kernel dans le fichier manifeste de l'appareil:

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

La version du kernel est ensuite mise en correspondance. Si un appareil dans uname() signale:

  • 4.9.84 (aucune correspondance avec la matrice, sauf s'il existe une section de kernel distincte avec <kernel version="4.9.x">, où x <= 84)
  • 4.14.41 (aucune correspondance avec la matrice, inférieure à version)
  • 4.14.42 (correspondance à la matrice)
  • 4.14.43 (correspondance à la matrice)
  • 4.1.22 (aucune correspondance avec la matrice, sauf s'il existe une section de kernel distincte avec <kernel version="4.1.x"> au lieu de x <= 22)

Une fois la section <kernel> appropriée sélectionnée, pour chaque élément <config> dont la valeur est différente de n, l'entrée correspondante devrait être présente dans /proc/config.gz. Pour chaque élément <config> ayant la valeur n, l'entrée correspondante ne devrait pas être présente dans /proc/config.gz. Le contenu de <value> devrait correspondre exactement au texte situé après le signe égal (y compris les guillemets), jusqu'au caractère de retour à la ligne ou #, les espaces de début et de fin étant tronqués.

La configuration du kernel 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 du kernel 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 avec les règles du SE

La règle du SE nécessite 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 se trouver dans l'une de ces plages pour être compatible avec le framework. Les règles de correspondance sont semblables aux versions HAL. Il s'agit d'une correspondance si la version sepolicy est supérieure ou égale à la version minimale de la plage. La version maximale est purement informative.
  • <kernel-sepolicy-version> (version policydb, par exemple). Doit être inférieur à l'security_policyvers() indiqué par l'appareil.

Exemple: Correspondance réussie de la stratégie SE

La matrice de compatibilité du framework indique les informations sepolicy 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, il ne s'agit pas d'une correspondance. Exemple :
    • Si un appareil renvoie 29, il ne correspond pas.
    • Si un appareil renvoie 31, il s'agit d'une correspondance.
  • La version de la stratégie SE doit être 25.0-∞ ou 26.0-∞. Sinon, il n'y a pas de correspondance. (Le "-3" après "26.0" est purement informatif.)

Correspondances de versions AVB

La version AVB contient une version majeure et une version mineure, au format MAJOR.MINOR (par exemple, 1.0, 2.1). Pour en savoir plus, consultez la section Gestion des versions et compatibilité. La version AVB possède les propriétés système suivantes:

  • ro.boot.vbmeta.avb_version correspond à la version libavb dans le bootloader.
  • ro.boot.avb_version est la version de libavb dans l'OS Android (init/fs_mgr).

La propriété système n'apparaît que lorsque le libavb correspondant a été utilisé pour vérifier les métadonnées AVB (et renvoie "OK"). Il est absent si une erreur de validation s'est produite (ou si aucune validation 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 bootloader ou l'OS Android peut contenir deux copies des bibliothèques libavb, chacune avec une version MAJOR différente pour les appareils de mise à niveau et les appareils 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 des avb.vbmeta-version différents):

Figure 1 : La version AVB correspond (/system est P, toutes les autres partitions sont O).



Figure 2. La version AVB correspond (toutes les partitions sont de type P).

Exemple: correspondance de la 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 

Correspondre à la version AVB lors de l'OTA

Pour les appareils lancés avec Android 9 ou version antérieure, lors de la mise à jour vers Android 10, les exigences concernant la version AVB dans la matrice de compatibilité du framework sont comparées à la version AVB actuelle de l'appareil. Si la version AVB est mise à niveau lors d'une mise à jour OTA (par exemple, de 0,0 à 1,0), la vérification de la compatibilité dans OTA par VINTF ne reflète pas la compatibilité après la mise à jour 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. Pour ce faire :

  1. Choisissez les CL suivantes à ajouter à l'arborescence source d'Android 9 :
  2. Définissez BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE pour l'appareil. Sa valeur doit être égale à la version AVB avant la mise à jour OTA, c'est-à-dire la version AVB de l'appareil au moment de son lancement.
  3. Recompilez 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 (non utilisé sous Android 9) sur l'appareil
  • system_matrix.xml dans compatibility.zip dans le package OTA

Ces modifications n'ont aucune incidence sur les autres matrices de compatibilité du framework, y compris /system/etc/vintf/compatibility_matrix.xml. Après la mise à jour OTA, la nouvelle valeur de /system/etc/vintf/compatibility_matrix.xml est utilisée pour les vérifications de compatibilité.

Correspondance de la version du VNDK

La matrice de compatibilité des appareils déclare la version VNDK requise dans compatibility-matrix.vendor-ndk.version. Si la matrice de compatibilité de l'appareil ne comporte pas de balise <vendor-ndk>, aucune exigence n'est imposée et il est donc toujours considéré 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 des instantanés de fournisseurs VNDK fourni par le framework dans le fichier manifeste du framework. Si une telle entrée n'existe pas, aucune correspondance n'est établie.

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ées dans le fichier 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é de l'appareil, 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 pour le VNDK: 

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

Dans le fichier manifeste du framework, seule l'entrée de 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 fichier 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 du VNDK se trouve dans le fichier manifeste du framework, libjpeg.so n'est pas compatible avec le framework dans cet instantané. La version 26 du VNDK est ignorée.

La version du SDK système correspond

La matrice de compatibilité des appareils déclare un ensemble de versions de SDK système requises dans compatibility-matrix.system-sdk.version. Il n'y a correspondance que si l'ensemble est un sous-ensemble des versions de SDK système fournies, comme déclaré dans manifest.system-sdk.version dans le fichier manifeste du framework.

  • Si aucune version du SDK système n'est énumérée dans la matrice de compatibilité des appareils, elle est toujours considérée comme une correspondance, car l'ensemble vide est un sous-ensemble d'un ensemble.

Exemple: correspondance de la version du SDK système réussie

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>

Le framework doit ensuite fournir les versions 26 et 27 du SDK système pour qu'elles correspondent.

<!-- 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 à cette définition.

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