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äte-Manifest 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 einiger optionaler 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 Abgleichsregeln für HIDL- und native HALs sind wie folgt:
- Mehrere
<hal>
-Elemente werden mit einer einzelnen UND-Beziehung ausgewertet. <hal>
-Elemente können<hal optional="true">
enthalten, um sie als nicht erforderlich zu markieren.- Mehrere
<version>
-Elemente innerhalb desselben<hal>
-Elements haben eine ODER-Beziehung. Wenn zwei oder mehr angegeben sind, muss nur eine der Versionen implementiert werden. Weitere Informationen finden Sie unter 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.∞. Gibt Folgendes an:
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 muss 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
ODER:
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1 android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
UND muss alle diese Instanzen implementieren:
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">
enthalten, 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 einen HAL in Version 5 lautet die Abgleichsregel so:
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 muss alle diese 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 das Gerät die Kernel-FCM-Version explizit im Gerätemanifest /vendor/etc/vintf/manifest.xml
angibt, wenn eine der folgenden Bedingungen zutrifft:
-
Die Kernel-FCM-Version unterscheidet sich von der Ziel-FCM-Version. Das oben erwähnte Gerät hat beispielsweise die Ziel-FCM-Version 4 und die Kernel-FCM-Version 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 für 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 die Android-Version aus der Kernel-Version ab und verwendet sie, 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 (die Kernel-FCM-Version muss für die Ziel-FCM-Version 5 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 der Prozess fortgesetzt, indem versucht wird, 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.gz
vorhanden.<value type="int">4096</value>
entspricht4096
,0x1000
oder0X1000
.<value type="int">0x1000</value>
entspricht4096
,0x1000
oder0X1000
.<value type="int">0X1000</value>
entspricht4096
,0x1000
oder0X1000
.<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.gz
vorhanden sein darf.<value type="range">1-0x3</value>
entspricht1
,2
oder3
oder 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äte-Manifest 1 ist, wird mit dem nächsten Schritt fortgefahren und die Kernel-Version wird geprüft.
- Wenn der Kernel-Branch im Gerätemanifest 2 ist, gibt es keine Übereinstimmung mit der Matrix. VINTF-Objekte lesen die Kernelanforderungen stattdessen aus der Matrix in FCM-Version 2.
Anschließend wird die Kernelversion abgeglichen. Wenn ein Gerät in uname()
Folgendes meldet:
- 4.9.84 (keine Übereinstimmung mit der Matrix, sofern es keinen separaten Kernel-Abschnitt mit
<kernel version="4.9.x">
gibt, 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 (einschließlich Anführungszeichen) bis zum Zeilenumbruchzeichen oder #
übereinstimmen. 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 Match.
- Die SEPolicy-Version muss 25.0–∞ oder 26.0–∞ sein. Andernfalls liegt keine Übereinstimmung vor. Die
-3
nach26.0
dient nur zur Information.
AVB-Versionsübereinstimmungen
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_version
ist dielibavb
-Version im Bootloader.ro.boot.avb_version
ist dielibavb
-Version im Android-Betriebssystem (init/fs_mgr
).
Die Systemeigenschaft wird nur angezeigt, wenn die entsprechende libavb
zur Überprüfung von AVB-Metadaten verwendet wurde (und OK zurückgibt). 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_version
mitavb.vbmeta-version
aus der Framework-Kompatibilitätsmatrix: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
mitavb.vbmeta-version
aus der Framework-Kompatibilitätsmatrix:ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR
Der Bootloader oder das Android-Betriebssystem kann zwei Kopien von libavb
-Bibliotheken enthalten, jeweils mit einer anderen MAJOR-Version für Upgrade- und Launch-Geräte. In diesem Fall kann dasselbe nicht signierte System-Image freigegeben werden, die endgültigen signierten System-Images sind jedoch 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
In der Framework-Kompatibilitätsmatrix sind die folgenden AVB-Informationen angegeben:
<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 der Kompatibilität im OTA nicht die Kompatibilität nach dem OTA 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_OVERRIDE
für das Gerät. Der Wert sollte 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.xml
incompatibility.zip
im OTA-Paket
Diese Änderungen haben keine Auswirkungen auf andere Framework-Kompatibilitätsmatrizen, 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 dies immer als Übereinstimmung 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.