Règles de correspondance

Les deux paires de matrices de compatibilité et de fichiers manifestes sont destinées à être rapprochées pour vérifier le framework et la mise en œuvre du fournisseur peuvent fonctionner ensemble. Cette validation est une réussite si la matrice de compatibilité du framework le fichier manifeste de l'appareil, ainsi qu'entre le fichier manifeste du framework et celui la matrice de compatibilité.

Cette validation est effectuée au moment de la compilation, lors de la mise à jour OTA. au moment de la génération du package, au 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 des versions de la matrice de compatibilité du framework

Pour faire correspondre un fichier manifeste d'appareil à une matrice de compatibilité avec le framework, la version FCM pour la livraison spécifiée par manifest.target-level doit être exactement identique à la version de 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 l'opération aboutit toujours, car libvintf ouvre le fichier manifeste de l'appareil et récupère la livraison Version FCM, puis renvoie la matrice de compatibilité du framework associée à cette version (plus certaines HAL facultatives provenant des matrices de compatibilité des versions FCM ultérieures).

Correspondances HAL

La règle de correspondance HAL identifie les versions des éléments hal dans un fichiers manifestes considérés comme acceptés par le propriétaire la matrice de compatibilité.

HIDL et HAL natifs

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

  • Plusieurs éléments <hal> sont évalués avec un seul élément AND relation.
  • Les éléments <hal> peuvent comporter des <hal optional="true"> pour les marquer comme n'est pas obligatoire.
  • Plusieurs éléments <version> au sein d'un même <hal> ont les OR. Si deux ou plus sont spécifiés, seuls l'une des versions doit être implémentée. Reportez-vous à l'exemple DRM ci-dessous.)
  • Plusieurs <instance> et éléments <regex-instance> au sein du même Les <hal> sont évaluées avec une seule relation AND lorsque les Veuillez renseigner le champ <hal>. (Voir l'<ahref="#drm">exemple de DRM ci-dessous.)</ahref="#drm">

Exemple: correspondance HAL réussie pour un module

Pour une version HAL 2.5, 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 le raccourci pour 2.5-5
2.5-7 2,5-2,∞. Indique les éléments suivants:
<ph type="x-smartling-placeholder">
    </ph>
  • 2.5 est la version minimale requise, c'est-à-dire un fichier manifeste fournissant une HAL Les versions 2.0 à 2.4 ne sont pas compatibles.
  • 2.7 est la version maximale pouvant être demandée. Autrement dit, le propriétaire la matrice de compatibilité (framework ou appareil) ne demande pas de versions au-delà de 2,7. Le propriétaire du fichier manifeste correspondant peut toujours diffuser la version 2.10 (à titre d'exemple) lorsque la version 2.7 est demandée. Le propriétaire de la matrice de compatibilité sait que le service demandé est compatible avec la version 2.7 de l'API.
  • -7 est fourni à titre indicatif uniquement et n'a aucune incidence sur le processus de mise à jour OTA.
Ainsi, un appareil dont le fichier manifeste contient un HAL version 2.10 compatibles avec un cadre qui stipule 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 : l'un ou l'autre

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 les instances suivantes:

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 ultérieures à Android 11 (à l'exception d'Android) 11) est compatible avec les versions des HAL AIDL dans VINTF. Les règles de correspondance des HAL AIDL sont semblables à celles des HAL natives (HIDL), à la différence près que il n'y a pas de version majeure et il n'existe 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 un seul élément AND relation.
  • Les éléments <hal> peuvent comporter des <hal optional="true"> pour les marquer comme n'est pas obligatoire.
  • Plusieurs <instance> et éléments <regex-instance> au sein du même Les <hal> sont évaluées avec une seule relation AND lorsque les Veuillez renseigner le champ <hal>. (Voir l'<ahref="#vibrator">exemple de vibreur ci-dessous.)</ahref="#vibrator">

Exemple: correspondance HAL réussie pour un module

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

Grille Fichier manifeste correspondant
5 5-∞. Dans la matrice de compatibilité, 5 est le raccourci pour 5-5
5-7 5-∞. Indique les éléments suivants:
<ph type="x-smartling-placeholder">
    </ph>
  • 5 est la version minimale requise, c'est-à-dire un fichier manifeste fournissant une HAL. Les valeurs 1 à 4 ne sont pas compatibles.
  • 7 est la version maximale pouvant être demandée, ce qui signifie que le propriétaire la matrice de compatibilité (framework ou appareil) ne demande pas de versions au-delà de 7. Le propriétaire du fichier manifeste correspondant peut toujours diffuser la version 10 (à titre d'exemple) lorsque la valeur 7 est demandée. Le propriétaire de la matrice de compatibilité sait que le service demandé est compatible avec la version 7 de l'API.
  • -7 est fourni à titre indicatif uniquement et n'a aucune incidence sur le processus de mise à jour OTA.
Ainsi, un appareil doté d'un HAL version 10 dans son fichier manifeste reste compatibles avec un cadre qui stipule 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 mettre en œuvre tous les cas suivants:

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

Section <kernel> de la matrice de compatibilité du framework décrit les exigences du framework du noyau Linux sur l'appareil. Ce les informations doivent être comparées d'informations sur le noyau qui est signalé 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é sur une chaîne unique Version du noyau FCM (par exemple, 5). Le mappage est identique à celui entre les lettres d'autorisation (R, par exemple) et celles de FCM (5, par exemple).

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

  • La version FCM du noyau est différente de la version FCM cible. Par exemple, L'appareil mentionné ci-dessus cible la version 4 du FCM et la version 5 de son noyau FCM (noyau). suffixe de branche r).
  • La version FCM du noyau est supérieure ou égale à 5 (suffixe de la branche du noyau r).

Les tests VTS garantissent 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 indiquée dans le fichier manifeste de l'appareil.

Exemple: Déterminer la branche du noyau

Si l'appareil cible la version 4 de FCM (publiée sous Android 10), mais que exécute le noyau à partir de la branche 4.19-r, le fichier manifeste de l'appareil doit spécifier ce qui suit: 

<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 du noyau 4.19-r qui est spécifiée dans la version 5 de FCM. Ces exigences sont élaborées <ph type="x-smartling-placeholder"></ph> 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 du noyau générique (GKI) et la chaîne de version du noyau de /proc/version est le suivant:

5.4.42-android12-0-00544-ged21d463f856

Ensuite, l'objet VINTF obtient la version d'Android à partir de la version du noyau et l'utilise pour déterminer la version du noyau FCM. Dans cet exemple, android12 correspond à la version 6 du noyau FCM. (publié dans Android 12).

Pour plus de détails sur l'analyse de la chaîne de publication du noyau, consultez Gestion des versions GKI

Faire correspondre les versions de noyau

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

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

L'objet VINTF ne prend en compte que la section <kernel> du FCM avec la version FCM correspondante et la même ${ver} et ${major_rev} comme noyau de l'appareil (par exemple, version="${ver}.${major_rev}.${matrix_minor_rev}"); autres sections sont ignorés. De plus, la révision mineure du noyau doit être une valeur à partir de la matrice de compatibilité (${kernel_minor_rev} >= ${matrix_minor_rev};). Si aucune des sections <kernel> ne correspond ces exigences, il s'agit d'une non-correspondance.

Exemple: Sélectionner les conditions requises pour la mise en correspondance

Prenons le cas hypothétique suivant où les FCM de /system/etc/vintf déclarent le Conditions requises 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 le noyau. exigences de FCM:

Version FCM cibleVersion du noyau FCMVersion de noyauCorrespondance avec
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 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 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 de noyau 5.4-q)
4 (Q)5 (D) 4.14.1054.14-r
4 (Q)5 (D) 5.4.41 5.4-r
5 (D)non spécifiétout Échec du VTS (vous devez spécifier la version FCM du noyau pour la version 5 du FCM cible)
5 (D)4 (Q) tout Échecs VTS (version FCM du noyau < version FCM cible)
5 (D)5 (D) 4.14.1804.14-r

Faire correspondre les configurations du noyau

Si la section <kernel> correspond, le processus se poursuit. en tentant de faire correspondre les éléments config /proc/config.gz Pour chaque élément de configuration du composant "compatibilité", la matrice recherche /proc/config.gz pour voir si la configuration à l'heure actuelle. Lorsqu'un élément de configuration est défini sur n dans la compatibilité pour la section <kernel> correspondante, elle doit être absente de /proc/config.gz. Enfin, un élément de configuration qui n'est pas La matrice de compatibilité peut être présente ou non dans /proc/config.gz.

Exemple: faire correspondre les configurations de noyau

  • <value type="string">bar</value> correspondances "bar" Les guillemets sont omis dans la matrice de compatibilité, mais ils sont présents dans /proc/config.gz.
  • <value type="int">4096</value> correspondances 4096, 0x1000 ou 0X1000.
  • <value type="int">0x1000</value> correspondances 4096, 0x1000 ou 0X1000.
  • <value type="int">0X1000</value> correspondances 4096, 0x1000 ou 0X1000.
  • <value type="tristate">y</value> correspondances y
  • <value type="tristate">m</value> correspondances m
  • <value type="tristate">n</value> signifie que la configuration L'élément NE DOIT PAS exister dans le dossier /proc/config.gz.
  • <value type="range">1-0x3</value> correspondances 1, 2 ou 3, 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 fichier manifeste de l'appareil. dans manifest.kernel.target-level, définie par défaut sur manifest.level. si l'ancienne n'est pas spécifiée. Si la branche du noyau dans le fichier manifeste de l'appareil:

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

Ensuite, la version du noyau est mise en correspondance. Si un appareil se trouvant dans uname() rapports:

  • 4.9.84 (aucune correspondance avec la matrice, sauf s'il existe une section de noyau séparée 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 noyau distincte) avec <kernel version="4.1.x">, où x <= 22)

Une fois la section <kernel> appropriée sélectionnée, par exemple chaque élément <config> ayant une valeur autre que n, nous que l'entrée correspondante soit présente dans /proc/config.gz ; pour chaque élément <config> ayant la valeur n, nous estimons l'entrée correspondante ne doit pas être présente dans /proc/config.gz. Mer le contenu de <value> doit correspondre exactement au texte situé après le signe égal (y compris les guillemets), jusqu'au caractère de retour à la 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 ayant échoué:

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 composant sécurisé

La règle du SE nécessite les correspondances suivantes:

  • <sepolicy-version> définit une plage fermée de mineurs. pour chaque version majeure. Version de sepolicy signalée par l'appareil doivent se situer dans l'une de ces plages pour être compatibles avec le framework. Correspondance sont similaires aux versions HAL ; une correspondance est établie si la version de sepolicy est supérieure ou égale à la version minimale pour la plage. La version maximale est purement informatives.
  • <kernel-sepolicy-version> (version policydb, par exemple). Doit être inférieure à la valeur security_policyvers() indiquée par l'appareil.

Exemple: correspondance réussie avec la règle 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. Dans le cas contraire, il ne s'agit pas d'une correspondance. Par exemple: <ph type="x-smartling-placeholder">
      </ph>
    • 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 règle SE doit être 25.0-∞ ou 26.0-∞. Sinon, il ne s'agit pas correspond. (Le "-3" après "26.0" est purement à titre informatif.)

La version AVB correspond

La version AVB contient une version MAJEUR et une version MINEUR, au format MAJEURE.MINEURE (par exemple, 1,0 ou 2,1). Pour en savoir plus, consultez 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 OS Android (init/fs_mgr)

La propriété système ne s'affiche que lorsque le libavb correspondant a été utilisé. pour vérifier les métadonnées AVB (et renvoie OK). Il est absent en cas d'échec de la validation. (ou aucune vérification).

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

  • sysprop ro.boot.vbmeta.avb_version avec avb.vbmeta-version à partir de la matrice de compatibilité des frameworks <ph type="x-smartling-placeholder">
      </ph>
    • 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é des frameworks
    • 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 de libavb. de versions majeures différentes pour les appareils mis à niveau appareils. Dans ce cas, la même image système non signée peut être partagée, mais les images système finales signées sont différentes (avec des avb.vbmeta-version):

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

Faire correspondre la version AVB pendant la mise à jour OTA

Pour les appareils équipés d'Android 9 ou version antérieure, lors de la mise à jour vers Android 10, l'AVB les exigences de version dans la matrice de compatibilité du framework sont comparées à l'AVB actuel sur l'appareil. Si la version AVB comporte une mise à niveau majeure lors d'une mise à niveau OTA (par exemple, de 0.0 à 1.0), la vérification VINTF de compatibilité dans l'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 effectuer le contrôle. Pour ce faire :

  1. Sélectionnez les CL suivants dans l'arborescence source d'Android 9: <ph type="x-smartling-placeholder">
  2. Définissez BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE pour l'appareil. Sa valeur doit correspondre à la version AVB avant l'OTA, c'est-à-dire à la version AVB de l'appareil au moment lancé.
  3. Recréez le package OTA.

Ces changements 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é avec 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, y compris /system/etc/vintf/compatibility_matrix.xml Après l'OTA, la nouvelle valeur de /system/etc/vintf/compatibility_matrix.xml est utilisé à la place pour les vérifications de compatibilité.

La version du VNDK correspond

La matrice de compatibilité des appareils déclare la version de VNDK requise dans compatibility-matrix.vendor-ndk.version Si l'appareil la matrice de compatibilité ne comporte pas de tag <vendor-ndk>, pas de sont imposées, et sont donc toujours considérées comme une correspondance.

Si la matrice de compatibilité des appareils comporte un <vendor-ndk> une entrée <vendor-ndk> avec une expression <version> a été recherché dans l'ensemble des instantanés de fournisseur VNDK fournies par le framework dans son fichier manifeste. Si une telle entrée ne il n'y a pas de correspondance.

Si une telle entrée existe, l'ensemble des bibliothèques énumérées dans l'appareil la matrice de compatibilité doit être un sous-ensemble de l'ensemble de bibliothèques indiqué dans le le fichier manifeste du framework. sinon l'entrée n'est pas considérée comme une correspondance.

  • Si aucune bibliothèque n'est énumérée dans l'appareil, de compatibilité de la matrice, l'entrée est toujours considérée comme une correspondance, car est un sous-ensemble d'un ensemble.

Exemple: correspondance de la 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 de VNDK est dans le framework manifeste, libjpeg.so n'est pas compatible avec le framework un 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 SDK système requis dans compatibility-matrix.system-sdk.version. Il y a un correspondre uniquement si l'ensemble est un sous-ensemble de versions fournies du SDK système telles que déclarées dans manifest.system-sdk.version dans le fichier manifeste du framework.

  • Cas particulier, si aucune version du SDK système n'est énumérée dans l'appareil de compatibilité, elle est toujours considérée comme une correspondance, car les valeurs 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 pour les SDK: 

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Le framework doit ensuite fournir les versions 26 et 27 des SDK système correspondants.

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

L'exemple A correspond.

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