Übereinstimmungsregeln

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">
    </ph>
  • 2.5 ist die erforderliche Mindestversion, d. h. ein Manifest, das HAL bereitstellt 2.0-2.4 ist nicht kompatibel.
  • 2.7 ist die maximale Version, die angefordert werden kann, d. h. der Eigentümer von fordert die Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen an über 2,7 hinaus. Der Inhaber des übereinstimmenden Manifests kann weiterhin Version 2.10 bereitstellen. (z. B.), wenn Version 2.7 angefordert wird. Der Eigentümer der Kompatibilitätsmatrix weiß, nur, dass der angeforderte Dienst mit API-Version 2.7 kompatibel ist.
  • -7 dient nur zu Informationszwecken und hat keine Auswirkungen auf die OTA-Aktualisierung.
Daher bleibt ein Gerät mit einem HAL in Version 2.10 in seiner Manifest-Datei ist mit einem Framework kompatibel, das besagt, 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 >= 0
ODER 
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">
    </ph>
  • 5 ist die erforderliche Mindestversion, d. h. ein Manifest, das HAL bereitstellt 1–4 ist nicht kompatibel.
  • 7 ist die Höchstversion, die angefordert werden kann, d. h. der Eigentümer von fordert die Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen an über 7 hinaus. Der Inhaber des übereinstimmenden Manifests kann trotzdem Version 10 bereitstellen (z. B.), wenn 7 angefordert wird. Der Eigentümer der Kompatibilitätsmatrix weiß, dass der angeforderte Dienst mit API-Version 7 kompatibel ist.
  • -7 dient nur zu Informationszwecken und hat keine Auswirkungen auf die OTA-Aktualisierung.
Daher bleibt ein Gerät mit einem HAL von Version 10 in seiner Manifest-Datei ist mit einem Framework kompatibel, das besagt, 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-ZielversionFCM-Kernel-VersionKernel-VersionAbgleichen mit
3 (P)nicht angegeben4.4.106 Keine Übereinstimmung (Nebenversion stimmt nicht überein)
3 (P)nicht angegeben4.4.107 4.4-p
3 (P)nicht angegeben4.19.42 4.19-q (siehe Hinweis unten)
3 (P)nicht angegeben5.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 angegeben4.4.107 Keine Übereinstimmung (kein 4.4-q-Kernel-Branch)
4 (Q)nicht angegeben4.9.165 4.9-q
4 (Q)nicht angegeben5.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.1054.14-r
4 (Q)5 (R) 5.4.41 5.4-r
5 (R)nicht angegebenbeliebig 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.1804.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> Übereinstimmungen 4096, 0x1000 oder 0X1000.
  • <value type="int">0x1000</value> Übereinstimmungen 4096, 0x1000 oder 0X1000.
  • <value type="int">0X1000</value> Übereinstimmungen 4096, 0x1000 oder 0X1000.
  • <value type="tristate">y</value> Übereinstimmungen y.
  • <value type="tristate">m</value> Übereinstimmungen m.
  • <value type="tristate">n</value> steht für die Konfiguration. Element darf in /proc/config.gz NICHT vorhanden sein.
  • <value type="range">1-0x3</value> Übereinstimmungen 1, 2 oder 3 oder 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">, wobei x <= 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">, wobei x <= 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 die security_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_version ist die libavb-Version. im Bootloader
  • ro.boot.avb_version ist die libavb-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_version mit avb.vbmeta-version aus der Framework-Kompatibilitätsmatrix; <ph type="x-smartling-placeholder">
      </ph>
    • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
  • Sysprop ro.boot.avb_version mit avb.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 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:

  1. Wählen Sie die folgenden CLs in der Android 9-Quellstruktur aus: <ph type="x-smartling-placeholder">
  2. Definieren Sie BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE für das Gerät. Sein Wert sollte der AVB-Version vor dem OTA-Konto entsprechen, also der AVB-Version des Geräts, eingeführt.
  3. 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ät
  • system_matrix.xml in compatibility.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-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.