Die beiden Paare von Kompatibilitätsmatrizen und Manifesten sollen abgeglichen werden, um zu prüfen, ob das Framework und die Anbieterimplementierung miteinander funktionieren. Diese Überprüfung ist erfolgreich, wenn die Framework-Kompatibilitätsmatrix und das Gerätemanifest sowie das Framework-Manifest und die Gerätekompatibilitätsmatrix übereinstimmen.
Diese Überprüfung erfolgt zur Build-Zeit, bei der Generierung des OTA-Aktualisierungspakets, zur Boot-Zeit und in VTS-Kompatibilitätstests.
In den folgenden Abschnitten werden die von den verschiedenen Komponenten verwendeten Abgleichsregeln beschrieben.
Versionen der Framework-Kompatibilitätsmatrix stimmen überein
Damit ein Gerätemanifest mit einer Framework-Kompatibilitätsmatrix übereinstimmt, muss die von manifest.target-level angegebene FCM-Version genau der von compatibility-matrix.level angegebenen FCM-Version entsprechen. Andernfalls gibt es keine Übereinstimmung.
Wenn die Framework-Kompatibilitätsmatrix mit libvintf angefordert wird, ist dieser Abgleich immer erfolgreich, da libvintf das Gerätemanifest öffnet, die ausgelieferte FCM-Version abruft und die Framework-Kompatibilitätsmatrix in dieser ausgelieferten FCM-Version zurückgibt (plus einige optionale HALs aus Kompatibilitätsmatrizen in höheren FCM-Versionen).
HAL-Übereinstimmungen
Die HAL-Abgleichsregel gibt die Versionen von hal-Elementen in einer Manifestdatei an, die vom Inhaber der entsprechenden Kompatibilitätsmatrix als unterstützt gelten.
HIDL- und native HALs
Die Übereinstimmungsregeln für HIDL- und native HALs sind wie folgt:
- Mehrere
<hal>-Elemente werden mit einer einzelnen UND-Beziehung ausgewertet. <hal>-Elemente können das Attribut<hal optional="true">haben, um sie als nicht erforderlich zu markieren.- Mehrere
<version>-Elemente innerhalb desselben<hal>-Elements haben die ODER-Beziehung. Wenn zwei oder mehr angegeben sind, muss nur eine der Versionen implementiert werden. (Siehe Erfolgreicher HAL-Abgleich für DRM-Modul.) - Mehrere
<instance>- und<regex-instance>-Elemente innerhalb desselben<hal>-Elements werden mit einer einzelnen UND-Beziehung ausgewertet, wenn das<hal>-Element erforderlich ist. Weitere Informationen finden Sie unter Erfolgreicher HAL-Abgleich für DRM-Modul.
Beispiel: Erfolgreiche HAL-Übereinstimmung für ein Modul
Für einen HAL in Version 2.5 lautet die Abgleichsregel so:
| Matrix | Passendes Manifest |
|---|---|
2.5 |
2.5–2.∞. In der Kompatibilitätsmatrix ist 2.5 die Kurzform für 2.5-5. |
2.5-7 |
2.5–2.∞. Das bedeutet Folgendes:
2.5-7 angegeben ist. |
Beispiel: Erfolgreiche HAL-Übereinstimmung für DRM-Modul
In der Framework-Kompatibilitätsmatrix werden die folgenden Versionsinformationen für die DRM HAL angegeben:
<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>
Ein Anbieter kann eine der folgenden Instanzen implementieren:
android.hardware.drm@1.x::IDrmFactory/default // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific // where x >= 0
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
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-HALs
Android und höher unterstützt Versionen für AIDL-HALs in VINTF.
Die Übereinstimmungsregeln für AIDL-HALs ähneln denen von HIDL- und nativen HALs. Es gibt jedoch keine Hauptversionen und genau eine Version pro HAL-Instanz (1, wenn die Version nicht angegeben ist):
- Mehrere
<hal>-Elemente werden mit einer einzelnen UND-Beziehung ausgewertet. <hal>-Elemente können<hal optional="true">haben, um sie als nicht erforderlich zu kennzeichnen.- Mehrere
<instance>- und<regex-instance>-Elemente innerhalb desselben<hal>werden mit einer einzelnen UND-Beziehung ausgewertet, wenn das<hal>erforderlich ist. Weitere Informationen finden Sie unter Erfolgreicher HAL-Abgleich für mehrere Module.
Beispiel: Erfolgreiche HAL-Übereinstimmung für ein Modul
Für ein HAL in Version 5 gilt die folgende Abgleichsregel:
| Matrix | Passendes Manifest |
|---|---|
5 |
5–∞. In der Kompatibilitätsmatrix ist 5 die Kurzform für 5-5. |
5-7 |
5–∞: Gibt Folgendes an:
5-7 in seiner Kompatibilitätsmatrix angibt. |
Beispiel: Erfolgreicher HAL-Abgleich für mehrere Module
In der Framework-Kompatibilitätsmatrix werden die folgenden Versionsinformationen für Vibrator- und Kamera-HALs angegeben:
<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>
Ein Anbieter kann eine der folgenden Instanzen implementieren:
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
Kernel-Übereinstimmungen
Im Abschnitt <kernel> der Framework-Kompatibilitätsmatrix werden die Anforderungen des Frameworks an den Linux-Kernel auf dem Gerät beschrieben. Diese Informationen sollen mit den Informationen zum Kernel abgeglichen werden, die vom VINTF-Objekt des Geräts gemeldet werden.
Kernel-Branches abgleichen
Jedes Kernel-Branch-Suffix (z. B. 5.4-r) wird einer eindeutigen Kernel-FCM-Version (z. B. 5) zugeordnet. Die Zuordnung ist dieselbe wie die Zuordnung zwischen Release-Buchstaben (z. B. R) und FCM-Versionen (z. B. 5).
VTS-Tests erzwingen, dass im Gerätemanifest /vendor/etc/vintf/manifest.xml explizit die Kernel-FCM-Version angegeben wird, wenn eine der folgenden Bedingungen zutrifft:
-
Die Kernel-FCM-Version unterscheidet sich von der Ziel-FCM-Version. Das oben genannte Gerät hat beispielsweise die FCM-Zielversion 4 und die FCM-Kernelversion 5 (Kernel-Branch-Suffix
r). -
Die Kernel-FCM-Version ist mindestens 5 (Kernel-Branch-Suffix
r).
VTS-Tests erzwingen, dass die Kernel-FCM-Version, falls angegeben, größer oder gleich der Ziel-FCM-Version im Gerätemanifest ist.
Beispiel: Kernel-Branch ermitteln
Wenn auf dem Gerät die FCM-Zielversion 4 (veröffentlicht in Android 10) ausgeführt wird, aber der Kernel aus dem 4.19-r-Branch stammt, sollte im Gerätemanifest Folgendes angegeben werden:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
Das VINTF-Objekt prüft die Kernelkompatibilität anhand der Anforderungen an den 4.19-r-Kernelzweig, der in FCM-Version 5 angegeben ist. Diese Anforderungen basieren auf
kernel/configs/r/android-4.19 im Android-Quellbaum.
Beispiel: Kernel-Branch für GKI ermitteln
Wenn auf dem Gerät das Generic Kernel Image (GKI) verwendet wird und der Kernel-Release-String aus /proc/version so aussieht:
5.4.42-android12-0-00544-ged21d463f856
Das VINTF-Objekt ruft dann das Android-Release aus dem Kernel-Release ab und verwendet es, um die Kernel-FCM-Version zu bestimmen. In diesem Beispiel steht android12 für die Kernel-FCM-Version 6 (veröffentlicht in Android 12).
Weitere Informationen zum Parsen des Kernel-Release-Strings finden Sie unter GKI-Versionsverwaltung.
Kernel-Versionen abgleichen
Eine Matrix kann mehrere <kernel>-Abschnitte enthalten, die jeweils ein anderes version-Attribut im folgenden Format verwenden:
${ver}.${major_rev}.${kernel_minor_rev}
Das VINTF-Objekt berücksichtigt nur den <kernel>-Abschnitt des FCM mit passender FCM-Version mit derselben ${ver} und ${major_rev} wie der Geräte-Kernel (d. h. version="${ver}.${major_rev}.${matrix_minor_rev}")). Andere Abschnitte werden ignoriert. Außerdem muss die Nebenversionsnummer des Kernels ein Wert aus der Kompatibilitätsmatrix (${kernel_minor_rev} >=
${matrix_minor_rev}) sein. Wenn kein <kernel>-Abschnitt diese Anforderungen erfüllt, liegt keine Übereinstimmung vor.
Beispiel: Anforderungen für den Abgleich auswählen
Betrachten Sie den folgenden hypothetischen Fall, in dem FCMs in /system/etc/vintf die folgenden Anforderungen deklarieren (Header- und Footer-Tags werden weggelassen):
<!-- 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 -->
Die Ziel-FCM-Version, die Kernel-FCM-Version und die Kernel-Version legen gemeinsam die Kernelanforderungen der FCMs fest:
| FCM-Zielversion | Kernel-FCM-Version | Kernel-Version | Abgleichen mit |
|---|---|---|---|
| 3 (P) | Ohne Angabe | 4.4.106 | Keine Übereinstimmung (geringfügige Versionsabweichung) |
| 3 (P) | Ohne Angabe | 4.4.107 | 4.4-p |
| 3 (P) | Ohne Angabe | 4.19.42 | 4.19-q (siehe Hinweis nach der Tabelle) |
| 3 (P) | Ohne Angabe | 5.4.41 | 5.4-r (siehe Hinweis nach der Tabelle) |
| 3 (P) | 3 (P) | 4.4.107 | 4.4-p |
| 3 (P) | 3 (P) | 4.19.42 | Keine Übereinstimmung (kein 4.19-p-Kernelzweig) |
| 3 (P) | 4 (Q) | 4.19.42 | 4.19-q |
| 4 (Q) | Ohne Angabe | 4.4.107 | Keine Übereinstimmung (kein 4.4-q-Kernelzweig) |
| 4 (Q) | Ohne Angabe | 4.9.165 | 4.9-q |
| 4 (Q) | Ohne Angabe | 5.4.41 | 5.4-r (siehe Hinweis nach der Tabelle) |
| 4 (Q) | 4 (Q) | 4.9.165 | 4.9-q |
| 4 (Q) | 4 (Q) | 5.4.41 | Keine Übereinstimmung (kein 5.4-q-Kernelzweig) |
| 4 (Q) | 5 (R) | 4.14.105 | 4.14-r |
| 4 (Q) | 5 (R) | 5.4.41 | 5.4-r |
| 5 (R) | Ohne Angabe | beliebig | VTS-Fehler (für die Ziel-FCM-Version 5 muss die Kernel-FCM-Version angegeben werden) |
| 5 (R) | 4 (Q) | beliebig | VTS-Fehler (Kernel-FCM-Version < Ziel-FCM-Version) |
| 5 (R) | 5 (R) | 4.14.180 | 4.14-r |
Kernelkonfigurationen abgleichen
Wenn der Abschnitt <kernel> übereinstimmt, wird versucht, config-Elemente mit /proc/config.gz abzugleichen. Für jedes Konfigurationselement in der Kompatibilitätsmatrix wird in /proc/config.gz nachgesehen, ob die Konfiguration vorhanden ist. Wenn ein Konfigurationselement im entsprechenden <kernel>-Abschnitt der Kompatibilitätsmatrix auf n gesetzt ist, muss es in /proc/config.gz fehlen. Schließlich kann ein Konfigurationselement, das nicht in der Kompatibilitätsmatrix enthalten ist, in /proc/config.gz vorhanden sein oder nicht.
Beispiel: Kernelkonfigurationen abgleichen
<value type="string">bar</value>entspricht"bar". Anführungszeichen werden in der Kompatibilitätsmatrix ausgelassen, sind aber in/proc/config.gzvorhanden.<value type="int">4096</value>entspricht4096,0x1000oder0X1000.<value type="int">0x1000</value>entspricht4096,0x1000oder0X1000.<value type="int">0X1000</value>entspricht4096,0x1000oder0X1000.<value type="tristate">y</value>entsprichty.<value type="tristate">m</value>entsprichtm.<value type="tristate">n</value>bedeutet, dass das Konfigurationselement NICHT in/proc/config.gzvorhanden sein darf.<value type="range">1-0x3</value>entspricht1,2oder3oder dem hexadezimalen Äquivalent.
Beispiel: Erfolgreiche Kernel-Übereinstimmung
Eine Framework-Kompatibilitätsmatrix mit FCM-Version 1 enthält die folgenden Kernelinformationen:
<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>
Der Kernel-Branch wird zuerst abgeglichen. Der Kernel-Branch wird im Gerätemanifest in manifest.kernel.target-level angegeben. Wenn er nicht angegeben ist, wird standardmäßig manifest.level verwendet:
- Wenn der Kernel-Branch im Gerätemanifest 1 ist, wird mit dem nächsten Schritt fortgefahren und die Kernelversion wird geprüft.
- Wenn der Kernel-Branch im Gerätemanifest 2 ist, gibt es keine Übereinstimmung mit der Matrix. VINTF-Objekte: Die Kernelanforderungen werden stattdessen aus der Matrix in FCM-Version 2 gelesen.
Anschließend wird die Kernelversion abgeglichen. Wenn ein Gerät in uname() Folgendes meldet:
- 4.9.84 (keine Übereinstimmung mit der Matrix, es sei denn, es gibt einen separaten Kernel-Abschnitt mit
<kernel version="4.9.x">, wobeix <= 84) - 4.14.41 (keine Übereinstimmung mit Matrix, kleiner als
version) - 4.14.42 (entspricht der Matrix)
- 4.14.43 (mit Matrix abgleichen)
- 4.1.22 (keine Übereinstimmung mit der Matrix, sofern kein separater Kernelabschnitt mit
<kernel version="4.1.x">vorhanden ist, wobeix <= 22)
Nachdem der entsprechende <kernel>-Abschnitt ausgewählt wurde, sollte für jedes <config>-Element mit einem anderen Wert als n der entsprechende Eintrag in /proc/config.gz vorhanden sein. Für jedes <config>-Element mit dem Wert n sollte der entsprechende Eintrag nicht in /proc/config.gz vorhanden sein.
Der Inhalt von <value> muss genau mit dem Text nach dem Gleichheitszeichen übereinstimmen (einschließlich Anführungszeichen), bis zum Zeilenumbruchzeichen oder #. Führende und nachfolgende Leerzeichen werden abgeschnitten.
Die folgende Kernelkonfiguration ist ein Beispiel für eine erfolgreiche Übereinstimmung:
# 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"
Die folgende Kernelkonfiguration ist ein Beispiel für eine nicht erfolgreiche Übereinstimmung:
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
SEPolicy-Übereinstimmungen
Für SEPolicy sind die folgenden Übereinstimmungen erforderlich:
<sepolicy-version>definiert für jede Hauptversion einen geschlossenen Bereich von Nebenversionen. Die vom Gerät gemeldete SEPolicy-Version muss in einem dieser Bereiche liegen, damit sie mit dem Framework kompatibel ist. Abgleichsregeln ähneln HAL-Versionen. Es liegt ein Abgleich vor, wenn die SEPolicy-Version höher oder gleich der Mindestversion für den Bereich ist. Die maximale Version dient nur zu Informationszwecken.<kernel-sepolicy-version>, d. h. die Policy DB-Version, muss kleiner alssecurity_policyvers()sein, die vom Gerät gemeldet wird.
Beispiel: Erfolgreicher SEPolicy-Abgleich
Die Framework-Kompatibilitätsmatrix enthält die folgenden SEPolicy-Informationen:
<sepolicy>
<kernel-sepolicy-version>30</kernel-sepolicy-version>
<sepolicy-version>25.0</sepolicy-version>
<sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>Auf dem Gerät:
- Der von
security_policyvers()zurückgegebene Wert muss größer oder gleich 30 sein. Andernfalls liegt keine Übereinstimmung vor. Beispiel:- Wenn ein Gerät 29 zurückgibt, liegt keine Übereinstimmung vor.
- Wenn ein Gerät 31 zurückgibt, ist es ein Treffer.
- Die SEPolicy-Version muss 25.0–∞ oder 26.0–∞ sein. Andernfalls liegt keine Übereinstimmung vor. Die
-3nach26.0dient nur zur Information.
AVB-Version stimmt überein
Die AVB-Version enthält eine MAJOR-Version und eine MINOR-Version im Format MAJOR.MINOR (z. B. 1.0, 2.1). Weitere Informationen finden Sie unter Versionsverwaltung und Kompatibilität. Die AVB-Version hat die folgenden Systemeigenschaften:
ro.boot.vbmeta.avb_versionist dielibavb-Version im Bootloader.ro.boot.avb_versionist dielibavb-Version im Android-Betriebssystem (init/fs_mgr).
Die Systemeigenschaft wird nur angezeigt, wenn die entsprechende libavb zum Überprüfen von AVB-Metadaten verwendet wurde (und „OK“ zurückgegeben wird). Sie ist nicht vorhanden, wenn ein Bestätigungsfehler aufgetreten ist oder keine Bestätigung stattgefunden hat.
Bei einem Kompatibilitätsabgleich werden die folgenden Elemente verglichen:
- sysprop
ro.boot.vbmeta.avb_versionmitavb.vbmeta-versionaus der Framework-Kompatibilitätsmatrix:ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJORro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
- sysprop
ro.boot.avb_versionmitavb.vbmeta-versionaus der Framework-Kompatibilitätsmatrix:ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJORro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR
Der Bootloader oder das Android-Betriebssystem enthalten möglicherweise zwei Kopien von libavb-Bibliotheken, jeweils mit einer anderen MAJOR-Version für Upgrade- und Launch-Geräte. In diesem Fall kann dasselbe nicht signierte System-Image freigegeben werden, aber die endgültigen signierten System-Images sind unterschiedlich (mit unterschiedlichen avb.vbmeta-version):
Abbildung 1: Die AVB-Version stimmt überein („/system“ ist P, alle anderen Partitionen sind O).
Abbildung 2: AVB-Version stimmt überein (alle Partitionen sind „P“).
Beispiel: Erfolgreiche AVB-Versionsübereinstimmung
Die Framework-Kompatibilitätsmatrix enthält die folgenden AVB-Informationen:
<avb>
<vbmeta-version>2.1</vbmeta-version>
</avb>Auf dem Gerät:
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
AVB-Version während des OTA-Updates abgleichen
Bei Geräten, die mit Android 9 oder niedriger auf den Markt gekommen sind, werden beim Aktualisieren auf Android 10 die AVB-Versionsanforderungen in der Framework-Kompatibilitätsmatrix mit der aktuellen AVB-Version auf dem Gerät abgeglichen. Wenn die AVB-Version während eines OTA ein Hauptversions-Upgrade erhält (z. B. von 0.0 auf 1.0), spiegelt die VINTF-Prüfung auf Kompatibilität im OTA die Kompatibilität nach dem OTA nicht wider.
Um das Problem zu beheben, kann ein OEM eine gefälschte AVB-Version in das OTA-Paket (compatibility.zip) einfügen, damit die Prüfung bestanden wird. Gehen Sie dazu folgendermaßen vor:
- Wählen Sie die folgenden CLs für den Android 9-Quellbaum aus:
- Definieren Sie
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDEfür das Gerät. Der Wert muss der AVB-Version vor dem OTA entsprechen, d. h. der AVB-Version des Geräts bei der Markteinführung. - Erstelle das OTA-Paket neu.
Durch diese Änderungen wird BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE automatisch als compatibility-matrix.avb.vbmeta-version in den folgenden Dateien platziert:
/system/compatibility_matrix.xml(wird in Android 9 nicht verwendet) auf dem Gerätsystem_matrix.xmlincompatibility.zipim OTA-Paket
Diese Änderungen wirken sich nicht auf andere Framework-Kompatibilitätsmatrizen aus, einschließlich /system/etc/vintf/compatibility_matrix.xml. Nach dem OTA wird stattdessen der neue Wert in /system/etc/vintf/compatibility_matrix.xml für Kompatibilitätsprüfungen verwendet.
VNDK-Version stimmt überein
In der Gerätekompatibilitätsmatrix wird die erforderliche VNDK-Version in compatibility-matrix.vendor-ndk.version deklariert. Wenn die Gerätekompatibilitätsmatrix kein <vendor-ndk>-Tag enthält, werden keine Anforderungen gestellt und es wird immer als Übereinstimmung betrachtet.
Wenn die Gerätekompatibilitätsmatrix ein <vendor-ndk>-Tag enthält, wird aus der Menge der VNDK-Anbietersnapshots, die vom Framework im Framework-Manifest bereitgestellt werden, ein <vendor-ndk>-Eintrag mit einem passenden <version> gesucht. Wenn ein solcher Eintrag nicht vorhanden ist, gibt es keine Übereinstimmung.
Wenn ein solcher Eintrag vorhanden ist, muss die Menge der in der Gerätekompatibilitätsmatrix aufgeführten Bibliotheken eine Teilmenge der im Framework-Manifest angegebenen Bibliotheken sein. Andernfalls gilt der Eintrag nicht als Übereinstimmung.
- Als Sonderfall gilt ein Eintrag immer als Übereinstimmung, wenn in der Gerätekompatibilitätsmatrix keine Bibliotheken aufgeführt sind, da eine leere Menge eine Teilmenge jeder Menge ist.
Beispiel: Erfolgreiche VNDK-Versionsübereinstimmung
Wenn in der Gerätekompatibilitätsmatrix die folgende VNDK-Anforderung angegeben ist:
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
Im Framework-Manifest wird nur der Eintrag mit Version 27 berücksichtigt.
<!-- Framework Manifest Example A --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> <library>libfoo.so</library> </vendor-ndk>
Beispiel A ist eine Übereinstimmung, da die VNDK-Version 27 im Framework-Manifest und {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} enthalten ist.
<!-- 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>
Beispiel B ist keine Übereinstimmung. Obwohl VNDK-Version 27 im Framework-Manifest enthalten ist, wird libjpeg.so in diesem Snapshot nicht vom Framework unterstützt. VNDK-Version 26 wird ignoriert.
System‑SDK-Version stimmt überein
In der Gerätekompatibilitätsmatrix wird eine Reihe von erforderlichen System-SDK-Versionen in compatibility-matrix.system-sdk.version angegeben. Eine Übereinstimmung liegt nur vor, wenn die Menge eine Teilmenge der bereitgestellten System-SDK-Versionen ist, die im Framework-Manifest in manifest.system-sdk.version deklariert sind.
- Als Sonderfall gilt: Wenn in der Gerätekompatibilitätsmatrix keine System-SDK-Versionen aufgeführt sind, wird das Gerät immer als kompatibel betrachtet, da eine leere Menge eine Teilmenge jeder Menge ist.
Beispiel: Erfolgreicher Abgleich der System-SDK-Version
Wenn in der Gerätekompatibilitätsmatrix die folgende Anforderung für das System-SDK angegeben ist:
<!-- Example Device Compatibility Matrix -->
<system-sdk>
<version>26</version>
<version>27</version>
</system-sdk>Das Framework muss dann die System-SDK-Versionen 26 und 27 bereitstellen:
<!-- Framework Manifest Example A -->
<system-sdk>
<version>26</version>
<version>27</version>
</system-sdk>Beispiel A ist eine Übereinstimmung:
<!-- Framework Manifest Example B -->
<system-sdk>
<version>26</version>
<version>27</version>
<version>28</version>
</system-sdk>Beispiel B ist eine Übereinstimmung:
<!-- Framework Manifest Example C -->
<system-sdk>
<version>26</version>
</system-sdk>Beispiel C ist keine Übereinstimmung, da die System-SDK-Version 27 nicht angegeben ist.