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">
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 >= 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 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">
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 cible | Version du noyau FCM | Version de noyau | Correspondance 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.105 | 4.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.180 | 4.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>
correspondances4096
,0x1000
ou0X1000
.<value type="int">0x1000</value>
correspondances4096
,0x1000
ou0X1000
.<value type="int">0X1000</value>
correspondances4096
,0x1000
ou0X1000
.<value type="tristate">y</value>
correspondancesy
<value type="tristate">m</value>
correspondancesm
<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>
correspondances1
,2
ou3
, 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 valeursecurity_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 versionlibavb
. dans le bootloaderro.boot.avb_version
est la version delibavb
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
avecavb.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
avecavb.vbmeta-version
de la matrice de compatibilité des frameworksro.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
):
![](https://source.android.com/docs/core/architecture/images/treble_vintf_avb_o_p.png?authuser=1&hl=fr)
Figure 1 : La version AVB correspond (/system est P, toutes les autres partitions sont O).
![](https://source.android.com/docs/core/architecture/images/treble_vintf_avb_p.png?authuser=1&hl=fr)
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 :
- Sélectionnez les CL suivants dans l'arborescence source d'Android 9: <ph type="x-smartling-placeholder">
- 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é. - 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
danscompatibility.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.