Die beiden Paare von Kompatibilitätsmatrizen und -manifesten sollen abgeglichen werden, um zu überprüfen, ob das Framework und die Anbieterimplementierung miteinander funktionieren können. Diese Überprüfung ist erfolgreich, wenn eine Übereinstimmung zwischen der Framework-Kompatibilitätsmatrix und dem Gerätemanifest sowie zwischen dem Framework-Manifest und der Gerätekompatibilitätsmatrix vorliegt.
Diese Überprüfung erfolgt zur Erstellungszeit, zur Generierungszeit des OTA- Updatepakets, zur Bootzeit und in VTS-Kompatibilitätstests.
In den folgenden Abschnitten werden die von verschiedenen Komponenten verwendeten Übereinstimmungsregeln detailliert beschrieben.
Die Version der Framework-Kompatibilitätsmatrix stimmt überein
Um ein Gerätemanifest mit einer Framework-Kompatibilitätsmatrix abzugleichen, muss die durch manifest.target-level
angegebene Versand-FCM-Version genau mit der durch compatibility-matrix.level
angegebenen FCM-Version übereinstimmen. Ansonsten 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 Versand-FCM-Version abruft und die Framework-Kompatibilitätsmatrix dieser Versand-FCM-Version zurückgibt (plus einige optionale HALs aus Kompatibilitätsmatrizen bei höheren FCM-Versionen). Versionen).
HAL-Matches
Die HAL-Match-Regel identifiziert die Versionen von hal
Elementen in einer Manifestdatei, die vom Besitzer der entsprechenden Kompatibilitätsmatrix als unterstützt gelten.
HIDL und native HALs
Die Übereinstimmungsregeln für HIDL und native HALs lauten wie folgt.
- Mehrere
<hal>
-Elemente werden mit einer einzigen UND- Beziehung ausgewertet. -
<hal>
-Elemente können<hal optional="true">
haben, um sie als nicht erforderlich zu markieren. - Mehrere
<version>
-Elemente innerhalb desselben<hal>
haben die ODER- Beziehung. Wenn zwei oder mehr angegeben sind, muss nur eine der Versionen implementiert werden. (Siehe das DRM-Beispiel unten.) - Mehrere
<instance>
- und<regex-instance>
-Elemente innerhalb desselben<hal>
werden mit einer einzigen UND- Beziehung ausgewertet, wenn<hal>
erforderlich ist. (Siehe dieDRM-Beispiel unten.)
Beispiel: Erfolgreicher HAL-Match für ein Modul
Für einen HAL in Version 2.5 lautet die Übereinstimmungsregel wie folgt:
Matrix | Passendes Manifest |
---|---|
2.5 | 2,5-2,∞. In der Kompatibilitätsmatrix ist 2.5 die Abkürzung für 2.5-5 . |
2.5-7 | 2,5-2,∞. Zeigt Folgendes an:
2.5-7 angibt. |
Beispiel: Erfolgreicher HAL-Abgleich für DRM-Modul
Die Framework-Kompatibilitätsmatrix gibt die folgenden Versionsinformationen für DRM HAL an:
<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; entweder
android.hardware.drm@1.x::IDrmFactory/default // where x >= 0 android.hardware.drm@1.x::IDrmFactory/specific // where x >= 0ODER
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1 android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
AND muss auch 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
Alle Android-Versionen nach Android 11 (außer Android 11) unterstützen Versionen für AIDL HALs in VINTF. Die Übereinstimmungsregeln für AIDL-HALs ähneln denen von HIDL und nativen HALs, außer dass es keine Hauptversionen und genau eine Version pro HAL-Instanz gibt ( 1
, wenn die Version nicht angegeben ist).
- Mehrere
<hal>
-Elemente werden mit einer einzigen UND- Beziehung ausgewertet. -
<hal>
-Elemente können<hal optional="true">
haben, um sie als nicht erforderlich zu markieren. - Mehrere
<instance>
- und<regex-instance>
-Elemente innerhalb desselben<hal>
werden mit einer einzigen UND- Beziehung ausgewertet, wenn<hal>
erforderlich ist. (Siehe dieBeispiel für einen Vibrator unten.)
Beispiel: Erfolgreicher HAL-Match für ein Modul
Für einen HAL in Version 5 lautet die Übereinstimmungsregel wie folgt:
Matrix | Passendes Manifest |
---|---|
5 | 5-∞. In der Kompatibilitätsmatrix ist 5 die Abkürzung für 5-5 . |
5-7 | 5-∞. Zeigt Folgendes an:
5-7 angibt. |
Beispiel: Erfolgreicher HAL-Abgleich für mehrere Module
Die Framework-Kompatibilitätsmatrix gibt die folgenden Versionsinformationen für Vibrator- und Kamera-HALs an:
<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
Der Abschnitt <kernel>
der Framework-Kompatibilitätsmatrix beschreibt die Anforderungen des Frameworks an den Linux-Kernel auf dem Gerät. Diese Informationen sollen mit den Informationen über den Kernel abgeglichen werden, die vom VINTF-Objekt des Geräts gemeldet werden.
Passen Sie Kernelzweige an
Jedes Kernel-Zweigsuffix (z. B. 5.4- r
) wird einer eindeutigen Kernel-FCM-Version (z. B. 5) zugeordnet. Die Zuordnung ist dieselbe wie die Zuordnung zwischen Freigabebriefen (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 genannte Gerät verfügt beispielsweise über eine Ziel-FCM-Version 4 und seine Kernel-FCM-Version ist 5 (Kernel-Zweigsuffix
r
). - Die Kernel-FCM-Version ist größer oder gleich 5 (Kernel-Zweigsuffix
r
).
VTS-Tests erzwingen, dass bei Angabe der Kernel-FCM-Version die Kernel-FCM-Version größer oder gleich der Ziel-FCM-Version im Gerätemanifest ist.
Beispiel: Bestimmen Sie den Kernelzweig
Wenn das Gerät über die Ziel-FCM-Version 4 (veröffentlicht in Android 10) verfügt, aber den Kernel aus dem 4.19-r
Zweig ausführt, sollte das Gerätemanifest Folgendes angeben:
<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 werden aus kernel/configs/r/android-4.19
im Android-Quellbaum erstellt.
Beispiel: Bestimmen Sie den Kernelzweig für GKI
Wenn das Gerät das Generic Kernel Image (GKI) verwendet und die Kernel-Release-Zeichenfolge von /proc/version
wie folgt lautet:
5.4.42-android12-0-00544-ged21d463f856
Anschließend ruft das VINTF-Objekt die Android-Version aus der Kernel-Version ab und ermittelt damit die Kernel-FCM-Version. In diesem Beispiel bedeutet android12
Kernel-FCM-Version 6 (veröffentlicht in Android 12).
Einzelheiten dazu, wie die Kernel-Release-Zeichenfolge analysiert wird, finden Sie unter GKI-Versionierung .
Passen Sie die Kernelversionen an
Eine Matrix kann mehrere <kernel>
-Abschnitte enthalten, jeder mit einem anderen version
im folgenden Format:
${ver}.${major_rev}.${kernel_minor_rev}
Das VINTF-Objekt berücksichtigt nur den Abschnitt <kernel>
aus dem FCM mit passender FCM-Version mit demselben ${ver}
und ${major_rev}
wie der Gerätekernel (d. h. version="${ver}.${major_rev}.${matrix_minor_rev}")
; andere Abschnitte werden ignoriert. Darüber hinaus muss die Nebenrevision vom Kernel ein Wert aus der Kompatibilitätsmatrix sein ( ${kernel_minor_rev} >= ${matrix_minor_rev}
;). Wenn kein <kernel>
-Abschnitt diese Anforderungen erfüllt, handelt es sich um eine Nichtübereinstimmung.
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 (Kopf- und Fußzeilen-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 wählen zusammen die Kernel-Anforderungen aus den FCMs aus:
Ziel-FCM-Version | Kernel-FCM-Version | Kernelversion | Passt zu |
---|---|---|---|
3 (P) | nicht spezifiziert | 4.4.106 | Keine Übereinstimmung (Nebenversionskonflikt) |
3 (P) | nicht spezifiziert | 4.4.107 | 4.4-p |
3 (P) | nicht spezifiziert | 4.19.42 | 4.19-q (siehe Hinweis unten) |
3 (P) | nicht spezifiziert | 5.4.41 | 5.4-r (siehe Hinweis unten) |
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) | nicht spezifiziert | 4.4.107 | Keine Übereinstimmung (kein 4.4-q Kernelzweig) |
4 (Q) | nicht spezifiziert | 4.9.165 | 4.9-q |
4 (Q) | nicht spezifiziert | 5.4.41 | 5.4-r (siehe Hinweis unten) |
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) | nicht spezifiziert | beliebig | VTS schlägt fehl (Muss die Kernel-FCM-Version für die Ziel-FCM-Version 5 angeben) |
5 (R) | 4 (Q) | beliebig | VTS schlägt fehl (Kernel-FCM-Version < Ziel-FCM-Version) |
5 (R) | 5 (R) | 4.14.180 | 4.14-r |
Passen Sie die Kernelkonfigurationen an
Wenn der Abschnitt <kernel>
übereinstimmt, wird der Prozess fortgesetzt, indem versucht wird, config
mit /proc/config.gz
abzugleichen. Für jedes Konfigurationselement in der Kompatibilitätsmatrix wird nach /proc/config.gz
gesucht, um festzustellen, ob die Konfiguration vorhanden ist. Wenn ein Konfigurationselement in der Kompatibilitätsmatrix für den passenden <kernel>
-Abschnitt auf n
gesetzt ist, darf es in /proc/config.gz
nicht vorhanden sein. Schließlich kann ein Konfigurationselement, das nicht in der Kompatibilitätsmatrix enthalten ist, in /proc/config.gz
vorhanden sein oder auch nicht.
Beispiel: Kernelkonfigurationen anpassen
-
<value type="string">bar</value>
entspricht"bar"
. Anführungszeichen werden in der Kompatibilitätsmatrix weggelassen, sind aber in/proc/config.gz
vorhanden. -
<value type="int">4096</value>
entspricht4096
oder0x1000
oder0X1000
. -
<value type="int">0x1000</value>
entspricht4096
oder0x1000
oder0X1000
. -
<value type="int">0X1000</value>
entspricht4096
oder0x1000
oder0X1000
. -
<value type="tristate">y</value>
stimmt mity
überein. -
<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 einem hexadezimalen Äquivalent.
Beispiel: Erfolgreicher Kernel-Match
Eine Framework-Kompatibilitätsmatrix mit FCM Version 1 enthält die folgenden Kernel-Informationen:
<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 Kernelzweig wird zuerst abgeglichen. Der Kernel-Zweig wird im Gerätemanifest in manifest.kernel.target-level
angegeben, das standardmäßig manifest.level
ist, wenn ersteres nicht angegeben ist. Wenn der Kernel-Zweig im Gerätemanifest:
- ist 1, fährt mit dem nächsten Schritt fort und prüft die Kernel-Version.
- ist 2, keine Übereinstimmung mit der Matrix. VINTF-Objekte lesen stattdessen die Kernel-Anforderungen aus der Matrix bei FCM Version 2.
Anschließend wird die Kernelversion abgeglichen. Wenn ein Gerät in uname()
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 der Matrix, kleiner als
version
) - 4.14.42 (Anpassung an Matrix)
- 4.14.43 (Anpassung an Matrix)
- 4.1.22 (keine Übereinstimmung mit der Matrix, es sei denn, es gibt einen separaten Kernel-Abschnitt mit
<kernel version="4.1.x">
, wobeix <= 22
)
Nachdem der entsprechende <kernel>
-Abschnitt ausgewählt wurde, erwarten wir für jedes <config>
-Element mit einem anderen Wert als n
, dass der entsprechende Eintrag in /proc/config.gz
vorhanden ist; Für jedes <config>
-Element mit dem Wert n
erwarten wir, dass der entsprechende Eintrag nicht in /proc/config.gz
vorhanden ist. Wir erwarten, dass der Inhalt von <value>
bis zum Zeilenumbruchzeichen oder #
genau mit dem Text nach dem Gleichheitszeichen (einschließlich Anführungszeichen) übereinstimmt, wobei führende und nachfolgende Leerzeichen abgeschnitten sind.
Die folgende Kernel-Konfiguration 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 Kernel-Konfiguration ist ein Beispiel für einen erfolglosen Abgleich:
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
SE-Richtlinienübereinstimmungen
Die SE-Richtlinie erfordert die folgenden Übereinstimmungen:
-
<sepolicy-version>
definiert einen geschlossenen Bereich von Nebenversionen für jede Hauptversion. Die vom Gerät gemeldete Sepolicy-Version muss in einem dieser Bereiche liegen, um mit dem Framework kompatibel zu sein. Die Match-Regeln ähneln den HAL-Versionen. Es handelt sich um eine Übereinstimmung, wenn die Sepolicy-Version höher oder gleich der Mindestversion für den Bereich ist. Die maximale Version dient rein informativen Zwecken. -
<kernel-sepolicy-version>
, also die Policydb-Version. Muss kleiner sein als die vom Gerät gemeldetesecurity_policyvers()
.
Beispiel: Erfolgreicher SE-Richtlinienabgleich
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 handelt es sich nicht um eine Übereinstimmung. Zum Beispiel:- Wenn ein Gerät 29 zurückgibt, handelt es sich nicht um eine Übereinstimmung.
- Wenn ein Gerät 31 zurückgibt, handelt es sich um eine Übereinstimmung.
- Die SE-Richtlinienversion muss 25.0-∞ oder 26.0-∞ sein. Sonst ist es keine Übereinstimmung. (Das „
-3
“ nach „26.0
“ dient lediglich der Information.)
AVB-Version stimmt überein
Die AVB-Version enthält eine MAJOR-Version und eine MINOR-Version mit dem Format MAJOR.MINOR (z. B. 1.0, 2.1). Weitere Informationen finden Sie unter Versionierung und Kompatibilität . Die AVB-Version verfügt über 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 der AVB-Metadaten verwendet wurde (und OK zurückgibt). Es fehlt, wenn ein Verifizierungsfehler aufgetreten ist (oder überhaupt keine Verifizierung stattgefunden hat).
Bei einem Kompatibilitätsabgleich wird Folgendes 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 enthält möglicherweise zwei Kopien der libavb
Bibliotheken mit jeweils einer anderen MAJOR-Version für Upgrade-Geräte und Startgeräte. In diesem Fall kann dasselbe unsignierte Systemabbild geteilt werden, aber die endgültigen signierten Systemabbilder sind unterschiedlich (mit unterschiedlicher avb.vbmeta-version
):
![](https://source.android.google.cn/docs/core/architecture/images/treble_vintf_avb_o_p.png?authuser=6&hl=de)
/system
ist P, alle anderen Partitionen sind O).![](https://source.android.google.cn/docs/core/architecture/images/treble_vintf_avb_p.png?authuser=6&hl=de)
Beispiel: Erfolgreicher AVB-Versionsabgleich
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
Passende AVB-Version während OTA
Bei Geräten, die mit Android 9 oder niedriger gestartet wurden, werden beim Update 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 größeres Versions-Upgrade erfährt (z. B. von 0.0 auf 1.0), spiegelt die VINTF-Kompatibilitätsprüfung im OTA nicht die Kompatibilität nach dem OTA wider.
Um das Problem zu entschärfen, kann ein OEM eine gefälschte AVB-Version in das OTA-Paket ( compatibility.zip
) einfügen, um die Prüfung zu bestehen. Gehen Sie dazu wie folgt 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. Sein Wert sollte der AVB-Version vor dem OTA entsprechen, also der AVB-Version des Geräts beim Start. - Erstellen Sie das OTA-Paket neu.
Diese Änderungen platzieren BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
automatisch als compatibility-matrix.avb.vbmeta-version
in den folgenden Dateien:
-
/system/compatibility_matrix.xml
(wird in Android 9 nicht verwendet) auf dem Gerät -
system_matrix.xml
incompatibility.zip
im 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
Die Gerätekompatibilitätsmatrix deklariert die erforderliche VNDK-Version in compatibility-matrix.vendor-ndk.version
. Wenn die Gerätekompatibilitätsmatrix kein <vendor-ndk>
-Tag hat, werden keine Anforderungen gestellt und es wird daher immer als Übereinstimmung betrachtet.
Wenn die Gerätekompatibilitätsmatrix über ein <vendor-ndk>
-Tag verfügt, wird ein <vendor-ndk>
-Eintrag mit einer passenden <version>
aus dem Satz von VNDK-Anbieter-Snapshots gesucht, der vom Framework im Framework-Manifest bereitgestellt wird. Wenn ein solcher Eintrag nicht vorhanden ist, gibt es keine Übereinstimmung.
Wenn ein solcher Eintrag vorhanden ist, muss der in der Gerätekompatibilitätsmatrix aufgeführte Satz von Bibliotheken eine Teilmenge des im Framework-Manifest angegebenen Satzes von Bibliotheken sein; Andernfalls gilt der Eintrag nicht als Übereinstimmung.
- Als Sonderfall gilt: Wenn in der Gerätekompatibilitätsmatrix keine Bibliotheken aufgeführt sind, wird der Eintrag immer als Übereinstimmung betrachtet, da eine leere Menge eine Teilmenge einer beliebigen Menge ist.
Beispiel: Erfolgreicher VNDK-Versionsabgleich
Wenn in der Gerätekompatibilitätsmatrix die folgende Anforderung an VNDK 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 VNDK Version 27 im Framework-Manifest enthalten ist und {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>
Beispiel B ist keine Übereinstimmung. Obwohl VNDK Version 27 im Framework-Manifest enthalten ist, wird libjpeg.so
in diesem Snapshot vom Framework nicht unterstützt. VNDK Version 26 wird ignoriert.
System-SDK-Version stimmt überein
Die Gerätekompatibilitätsmatrix deklariert einen Satz erforderlicher System-SDK-Versionen in compatibility-matrix.system-sdk.version
. Es gibt nur dann eine Übereinstimmung, wenn es sich bei der Menge um eine Teilmenge der bereitgestellten System SDK-Versionen handelt, wie in manifest.system-sdk.version
im Framework-Manifest deklariert.
- 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 einer beliebigen Menge ist.
Beispiel: Erfolgreicher System-SDK-Versionsabgleich
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>
Dann muss das Framework die passenden 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 stimmt nicht überein, da System SDK Version 27 nicht bereitgestellt wird.