Die beiden Paare aus Kompatibilitätsmatrizen und Manifesten abgeglichen, um zu überprüfen, Framework und Anbieterimplementierung zusammenarbeiten können. Diese Bestätigung bei einer Übereinstimmung zwischen der Framework-Kompatibilitätsmatrix und der Geräte-Manifest sowie zwischen dem Framework-Manifest und dem Gerät Kompatibilitätsmatrix zu verstehen.
Diese Überprüfung erfolgt bei der Build-Erstellung beim OTA-Update. bei der Paketerstellung, beim Booten und bei VTS-Kompatibilitätstests.
In den folgenden Abschnitten werden die Regeln für den Abgleich beschrieben, die von verschiedenen Komponenten.
Version der Framework-Kompatibilitätsmatrix stimmt überein
Um ein Gerätemanifest einer Framework-Kompatibilitätsmatrix zuzuordnen,
die in manifest.target-level angegebene FCM-Version für den Versand
muss genau der FCM-Version entsprechen, die durch
compatibility-matrix.level. Andernfalls gibt es keine Übereinstimmung.
Wenn die Framework-Kompatibilitätsmatrix mit libvintf angefordert wird, ist diese Übereinstimmung:
immer erfolgreich, da libvintf das Gerätemanifest öffnet und die
FCM-Version und gibt die Framework-Kompatibilitätsmatrix für diese Versand-FCM-Version zurück (plus einige
optionale HALs aus Kompatibilitätsmatrizen bei höheren FCM-Versionen).
HAL-Übereinstimmungen
Die HAL-Übereinstimmungsregel gibt die Versionen von hal-Elementen in einem
Manifest-Datei, die vom Inhaber der entsprechenden
Kompatibilitätsmatrix zu verstehen.
HIDL und native HALs
Für HIDL und native HALs gelten die folgenden Übereinstimmungsregeln.
- Mehrere
<hal>-Elemente werden mit einem einzigen AND-Element ausgewertet Beziehung. <hal>-Elemente können<hal optional="true">haben, um sie zu markieren als nicht erforderlich.- Mehrere
<version>-Elemente innerhalb desselben<hal>haben die OR-Beziehung. Wenn zwei oder mehr angegeben sind, eine der Versionen implementiert werden muss. (siehe Beispiel für digitale Rechteverwaltung unten). - Mehrere
<instance>- und<regex-instance>-Elemente innerhalb derselben<hal>werden mit einer einzelnen AND-Beziehung ausgewertet, wenn die<hal>ist erforderlich. Weitere Informationen finden Sie im <ahref="#drm">DRM-Beispiel unten.</ahref="#drm">
Beispiel: Erfolgreicher HAL-Abgleich für ein Modul
Für einen HAL in Version 2.5 lautet die Übereinstimmungsregel:
| Matrix | Übereinstimmendes 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,∞. Gibt Folgendes an:
<ph type="x-smartling-placeholder">
2.5-7 in der Kompatibilitätsmatrix angegeben ist. |
Beispiel: Erfolgreicher HAL-Abgleich für DRM-Modul
Die Framework-Kompatibilitätsmatrix enthält die folgenden Versionsinformationen: für 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>
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 außerdem alle folgenden 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 (ausgenommen Android)
11) unterstützt Versionen für AIDL HALs in VINTF.
Die Übereinstimmungsregeln für AIDL HALs ähneln denen von HIDL und nativen HALs, außer dass
Es gibt keine Hauptversionen und es gibt genau eine Version pro HAL-Instanz (1, wenn
Version nicht angegeben ist).
- Mehrere
<hal>-Elemente werden mit einem einzigen AND-Element ausgewertet Beziehung. <hal>-Elemente können<hal optional="true">haben, um sie zu markieren als nicht erforderlich.- Mehrere
<instance>- und<regex-instance>-Elemente innerhalb derselben<hal>werden mit einer einzelnen AND-Beziehung ausgewertet, wenn die<hal>ist erforderlich. Siehe dazu das <ahref="#vibrator">Vibrator-Beispiel unten.</ahref="#vibrator">
Beispiel: Erfolgreicher HAL-Abgleich für ein Modul
Für einen HAL in Version 5 lautet die Übereinstimmungsregel:
| Matrix | Übereinstimmendes Manifest |
|---|---|
5 |
5-∞. In der Kompatibilitätsmatrix ist 5 die Abkürzung für
5-5. |
5-7 |
5-∞. Gibt Folgendes an:
<ph type="x-smartling-placeholder">
5-7 in der Kompatibilitätsmatrix angegeben ist. |
Beispiel: Erfolgreicher HAL-Abgleich für mehrere Module
Die Framework-Kompatibilitätsmatrix enthält die folgenden Versionsinformationen: für Vibrations- und Kamera-HALs:
<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 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
Der Abschnitt <kernel> der Framework-Kompatibilitätsmatrix
beschreibt die Framework-Anforderungen des Linux-Kernels auf dem Gerät. Dieses
dass Informationen mit den
Informationen
über den Kernel, der vom VINTF-Objekt
des Geräts gemeldet wird.
Übereinstimmung mit Kernel-Zweigen
Jedes Kernel-Zweig-Suffix (z. B. 5.4-r) ist einem eindeutigen
FCM-Kernel-Version (z. B. 5). Die Zuordnung entspricht der Zuordnung zwischen Release-Buchstaben.
(z. B. R) und FCM-Versionen (z. B. 5).
VTS-Tests erzwingen, dass das Gerät die FCM-Kernel-Version explizit im
Gerätemanifest /vendor/etc/vintf/manifest.xml, wenn eine der folgenden Bedingungen zutrifft:
-
Die FCM-Kernel-Version unterscheidet sich von der FCM-Zielversion. Beispiel: Der Parameter
auf dem zuvor erwähnten Gerät die FCM-Zielversion 4 und die FCM-Kernel-Version 5 (Kernel
Zweig-Suffix
r). -
Die FCM-Kernel-Version ist größer oder gleich 5 (Kernel-Zweig-Suffix
r).
VTS-Tests erzwingen, dass bei Angabe der FCM-Kernel-Version die FCM-Kernel-Version ist größer oder gleich der FCM-Zielversion im Gerätemanifest.
Beispiel: Kernel-Zweig ermitteln
Das Gerät hat die Ziel-FCM-Version 4 (veröffentlicht in Android 10), aber
führt Kernel aus dem 4.19-r-Branch aus, 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 Kernel-Kompatibilität anhand der Anforderungen für den 4.19-r-Kernel
der in FCM Version 5 angegeben ist. Diese Anforderungen basieren auf
<ph type="x-smartling-placeholder"></ph>
kernel/configs/r/android-4.19.
in der Android-Quellstruktur.
Beispiel: Kernel-Zweig für GKI bestimmen
Wenn das Gerät das generische Kernel-Image (Generic Kernel Image, GKI) verwendet und den Kernel-Release-String von
/proc/version ist Folgendes:
5.4.42-android12-0-00544-ged21d463f856
Das VINTF-Objekt ruft dann den Android-Release vom Kernel-Release ab und verwendet ihn, um zu bestimmen,
die FCM-Kernel-Version. In diesem Beispiel steht android12 für FCM-Kernel-Version 6
(veröffentlicht in Android 12).
Weitere Informationen dazu, wie der Kernel-Release-String geparst wird, finden Sie unter GKI-Versionsverwaltung
Kernel-Versionen abgleichen
Eine Matrix kann mehrere <kernel>-Abschnitte enthalten, jeweils mit
ein anderes version-Attribut mit folgendem Format:
${ver}.${major_rev}.${kernel_minor_rev}
Das VINTF-Objekt berücksichtigt nur den Abschnitt <kernel> aus der
FCM mit übereinstimmender FCM-Version mit derselben
${ver} und ${major_rev} als Gerätekernel (d.h.
version="${ver}.${major_rev}.${matrix_minor_rev}"); anderen Abschnitten
werden ignoriert. Darüber hinaus muss die Nebenversion aus dem Kernel ein Wert sein
aus der Kompatibilitätsmatrix (${kernel_minor_rev} >=
${matrix_minor_rev};). Wenn kein <kernel>-Abschnitt erfüllt ist
diese Anforderungen erfüllt, entspricht dies nicht.
Beispiel: Anforderungen für den Abgleich auswählen
Betrachten Sie den folgenden hypothetischen Fall, bei dem FCMs in /system/etc/vintf Folgendes deklarieren:
folgenden Anforderungen (Kopf- und Fußzeilen-Tags werden ausgelassen):
<!-- 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 FCM-Zielversion, die FCM-Kernel-Version und die Kernel-Version wählen zusammen den Kernel aus Anforderungen der FCMs:
| FCM-Zielversion | FCM-Kernel-Version | Kernel-Version | Abgleichen mit |
|---|---|---|---|
| 3 (P) | nicht angegeben | 4.4.106 | Keine Übereinstimmung (Nebenversion stimmt nicht überein) |
| 3 (P) | nicht angegeben | 4.4.107 | 4.4-p |
| 3 (P) | nicht angegeben | 4.19.42 | 4.19-q (siehe Hinweis unten) |
| 3 (P) | nicht angegeben | 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-Kernel-Branch) |
| 3 (P) | 4 (Q) | 4.19.42 | 4.19-q |
| 4 (Q) | nicht angegeben | 4.4.107 | Keine Übereinstimmung (kein 4.4-q-Kernel-Branch) |
| 4 (Q) | nicht angegeben | 4.9.165 | 4.9-q |
| 4 (Q) | nicht angegeben | 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-Kernel-Branch) |
| 4 (Q) | 5 (R) | 4.14.105 | 4.14-r |
| 4 (Q) | 5 (R) | 5.4.41 | 5.4-r |
| 5 (R) | nicht angegeben | beliebig | VTS schlägt fehl (muss die FCM-Kernel-Version für die FCM-Zielversion 5 angeben) |
| 5 (R) | 4 (Q) | beliebig | VTS schlägt fehl (Kernel-FCM-Version < FCM-Zielversion) |
| 5 (R) | 5 (R) | 4.14.180 | 4.14-r |
Kernel-Konfigurationen abgleichen
Wenn der Abschnitt <kernel> übereinstimmt, wird der Vorgang fortgesetzt.
indem versucht wird, config-Elemente
/proc/config.gz Für jedes Konfigurationselement in der Kompatibilitäts-
Matrix verwendet, wird nach /proc/config.gz gesucht, um zu sehen, ob die Konfiguration
vorhanden ist. Wenn ein Konfigurationselement in der Kompatibilitätseinstellung auf n festgelegt ist
Matrix für den übereinstimmenden <kernel>-Abschnitt ein, darf nicht vorhanden sein
von /proc/config.gz. Ein Konfigurationselement, das nicht im
Kompatibilitätsmatrix kann in /proc/config.gz vorhanden sein oder nicht.
Beispiel: Kernel-Konfigurationen abgleichen
<value type="string">bar</value>Übereinstimmungen"bar". Anführungszeichen werden in der Kompatibilitätsmatrix weggelassen, sind aber vorhanden in „/proc/config.gz“.<value type="int">4096</value>Übereinstimmungen4096,0x1000oder0X1000.<value type="int">0x1000</value>Übereinstimmungen4096,0x1000oder0X1000.<value type="int">0X1000</value>Übereinstimmungen4096,0x1000oder0X1000.<value type="tristate">y</value>Übereinstimmungeny.<value type="tristate">m</value>Übereinstimmungenm.<value type="tristate">n</value>steht für die Konfiguration. Element darf in/proc/config.gzNICHT vorhanden sein.<value type="range">1-0x3</value>Übereinstimmungen1,2oder3oder ein hexadezimales Äquivalent.
Beispiel: Erfolgreicher Kernel-Abgleich
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 Kernel-Zweig wird zuerst abgeglichen. Der Kernel-Zweig ist im Gerätemanifest angegeben
in manifest.kernel.target-level. Der Standardwert ist manifest.level.
wenn Ersterer nicht angegeben ist. Wenn der Kernel-Zweig im Gerätemanifest:
- 1 ist, fährt mit dem nächsten Schritt fort und prüft die Kernel-Version.
- ist 2, keine Übereinstimmung mit der Matrix. VINTF-Objekte lesen Kernelanforderungen aus der Matrix bei FCM Version 2.
Anschließend wird die Kernel-Version abgeglichen. Wenn ein Gerät in uname()
Berichte:
- 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 (Übereinstimmung mit Matrix)
- 4.14.43 (Übereinstimmung mit 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)
Nach Auswahl des entsprechenden <kernel>-Abschnitts
für jedes <config>-Element mit einem anderen Wert als n
erwarten, dass der entsprechende Eintrag in /proc/config.gz vorhanden ist.
Für jedes <config>-Element mit dem Wert n erwarten wir
Der entsprechende Eintrag darf in /proc/config.gz nicht vorhanden sein. Mi.
erwarten, dass der Inhalt von <value> genau mit dem Text nach
das Gleichheitszeichen (einschließlich Anführungszeichen), bis zum Zeilenumbruchzeichen oder
#, wobei voran- und nachgestellte Leerzeichen abgeschnitten sind.
Die folgende Kernel-Konfiguration ist ein Beispiel für einen erfolgreichen Abgleich:
# 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 eine fehlgeschlagene Ü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
SE-Richtlinienübereinstimmungen
Die SE-Richtlinie erfordert die folgenden Übereinstimmungen:
<sepolicy-version>definiert einen geschlossenen Bereich von Minderjährigen Versionen für jede Hauptversion. Die vom Gerät gemeldete sepolicy-Version muss in einen dieser Bereiche fallen, um mit dem Framework kompatibel zu sein. Übereinstimmung sind HAL-Versionen ähnlich. Übereinstimmung, wenn die sepolicy-Version mindestens der Mindestversion für den Bereich entspricht. Die maximale Version ist die rein informativ sind.<kernel-sepolicy-version>, d.h. die policydb-Version. Muss kleiner sein als diesecurity_policyvers(), die vom Gerät gemeldet wurden.
Beispiel: Erfolgreicher SE-Richtlinienabgleich
Die Framework-Kompatibilitätsmatrix enthält die folgenden 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 sein als oder gleich 30 ist. Andernfalls gibt es keine Übereinstimmung. Hier einige Beispiele: <ph type="x-smartling-placeholder">- </ph>
- Wenn ein Gerät 29 zurückgibt, ist dies keine Übereinstimmung.
- Wenn ein Gerät den Wert 31 zurückgibt, ist dies eine Übereinstimmung.
- Die SE-Richtlinienversion muss 25.0–∞ oder 26.0–∞ sein. Andernfalls ist es keine
Übereinstimmung. (Das "
-3" nach "26.0" ist rein zu Informationszwecken.)
AVB-Version stimmt überein
Die AVB-Version enthält eine Hauptversion und eine Nebenversion im Format „Hauptversion“ und „Nebenversion“. als 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 Bootloaderro.boot.avb_versionist dielibavb-Version in Android-Betriebssystem (init/fs_mgr)
Die Systemeigenschaft wird nur angezeigt, wenn die entsprechende libavb-Datei verwendet wurde. um die AVB-Metadaten zu überprüfen (und gibt „OK“) zurück. Er wird nicht angegeben, wenn bei der Bestätigung ein Fehler auftritt. oder gar keine Bestätigung erfolgt ist.
Bei einer Kompatibilitätsübereinstimmung wird Folgendes verglichen:
- Sysprop
ro.boot.vbmeta.avb_versionmitavb.vbmeta-versionaus der Framework-Kompatibilitätsmatrix; <ph type="x-smartling-placeholder">- </ph>
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 enthält möglicherweise zwei Kopien von libavb
Bibliotheken mit jeweils einer anderen MAJOR-Version für Upgradegeräte und Markteinführung
Geräte. In diesem Fall kann dasselbe nicht signierte System-Image freigegeben werden,
Die endgültigen signierten System-Images unterscheiden sich (mit unterschiedlichen
avb.vbmeta-version):
Abbildung 1: AVB-Version stimmt überein (/system ist P, alle anderen Partitionen sind O).
Abbildung 2: AVB-Version stimmt überein (alle Partitionen haben den Status P).
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
AVB-Version während des OTA-Updates abgleichen
Für Geräte, die mit Android 9 oder niedriger auf den Markt gebracht wurden, bei der Aktualisierung auf Android 10, die AVB Versionsanforderungen in der Framework-Kompatibilitätsmatrix werden mit dem aktuellen AVB abgeglichen. Version auf dem Gerät. Wenn die AVB-Version während eines OTA-Updates (z. B. von 0.0 auf 1.0), gibt die VINTF-Prüfung auf Kompatibilität im OTA-Konto nicht die Kompatibilität nach das Onlinereisebüro.
Um das Problem zu beheben, kann ein OEM eine gefälschte AVB-Version im OTA-Paket platzieren.
(compatibility.zip), um die Prüfung zu bestehen. Gehen Sie dazu so vor:
- Wählen Sie die folgenden CLs in der Android 9-Quellstruktur aus: <ph type="x-smartling-placeholder">
- Definieren Sie
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDEfür das Gerät. Sein Wert sollte der AVB-Version vor dem OTA-Konto entsprechen, also der AVB-Version des Geräts, eingeführt. - Erstellen Sie das OTA-Paket neu.
Diese Änderungen werden automatisch
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE als
compatibility-matrix.avb.vbmeta-version:
/system/compatibility_matrix.xml(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-Update wird der neue Wert in
Für Kompatibilitätsprüfungen wird stattdessen /system/etc/vintf/compatibility_matrix.xml verwendet.
VNDK-Version stimmt überein
Die Gerätekompatibilitätsmatrix deklariert die erforderliche VNDK-Version in
compatibility-matrix.vendor-ndk.version Wenn das Gerät
Kompatibilitätsmatrix hat kein <vendor-ndk>-Tag, nein
Anforderungen auferlegt werden und
daher es immer als Übereinstimmung gilt.
Wenn die Gerätekompatibilitätsmatrix eine <vendor-ndk> hat:
Tag, ein <vendor-ndk>-Eintrag mit einem übereinstimmenden
<version> wurde in der Übersicht der VNDK-Anbieter ermittelt
das vom Framework im Framework-Manifest bereitgestellt wird. Wenn ein solcher Eintrag
vorhanden sind, gibt es keine Übereinstimmung.
Wenn ein solcher Eintrag vorhanden ist, wird der Satz Bibliotheken auf dem Gerät aufgelistet. Kompatibilitätsmatrix muss eine Teilmenge der in der Framework-Manifest; Andernfalls gilt der Eintrag nicht als Übereinstimmung.
- Als Sonderfall, wenn auf dem Gerät keine Bibliotheken aufgezählt sind wird der Eintrag immer als Übereinstimmung angesehen, da das Feld ist eine Teilmenge eines beliebigen Sets.
Beispiel: Erfolgreicher Abgleich der VNDK-Version
Wenn in der Gerätekompatibilitätsmatrix die folgende VNDK-Anforderung aufgeführt 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,
weil die 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 die VNDK-Version 27 bereits im Framework enthalten ist,
Manifestdatei libjpeg.so vom Framework nicht unterstützt wird,
Snapshot. VNDK-Version 26 wird ignoriert.
System SDK-Version stimmt überein
In der Gerätekompatibilitätsmatrix ist eine Reihe erforderlicher System-SDKs deklariert.
Version in compatibility-matrix.system-sdk.version. Es gibt eine
stimmt nur überein, wenn es sich bei dem Set um eine Teilmenge der angegebenen System SDK-Versionen handelt
in manifest.system-sdk.version im Framework-Manifest.
- Als Sonderfall, wenn auf dem Gerät keine System SDK-Versionen aufgelistet sind wird dies immer als Übereinstimmung angesehen, da das Feld ist eine Teilmenge eines beliebigen Sets.
Beispiel: Erfolgreicher Versionsabgleich des System SDK
Wenn die Gerätekompatibilitätsmatrix die folgende Anforderung an das System SDK:
<!-- Example Device Compatibility Matrix -->
<system-sdk>
<version>26</version>
<version>27</version>
</system-sdk>
Dann muss das Framework 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 Version 27 des System SDK nicht bereitgestellt wird.