Matching-Regeln

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 bei einer Übereinstimmung zwischen der Framework-Kompatibilitätsmatrix und dem Gerätemanifest sowie zwischen dem Framework-Manifest und der Gerätekompatibilitätsmatrix erfolgreich.

Diese Überprüfung erfolgt zur Erstellungszeit, zur OTA -Aktualisierungspaketgenerierungszeit, zur Startzeit und in VTS-Kompatibilitätstests.

Die folgenden Abschnitte beschreiben Übereinstimmungsregeln, die von verschiedenen Komponenten verwendet werden.

Versionsübereinstimmungen der Framework-Kompatibilitätsmatrix

Um ein Gerätemanifest mit einer Framework-Kompatibilitätsmatrix abzugleichen, muss die durch manifest.target-level angegebene Versand-FCM-Version genau gleich der durch compatibility-matrix.level angegebenen FCM-Version sein. Sonst gibt es keine Übereinstimmung.

Wenn die Framework-Kompatibilitätsmatrix mit libvintf angefordert wird, ist diese Übereinstimmung immer erfolgreich, da libvintf das Gerätemanifest öffnet, die Versand-FCM-Version abruft und die Framework-Kompatibilitätsmatrix in dieser Versand-FCM-Version zurückgibt (plus einige optionale HALs von Kompatibilitätsmatrizen bei höheren FCM Versionen).

HAL-Spiele

Die HAL-Übereinstimmungsregel identifiziert die Versionen von hal -Elementen in einer Manifestdatei, die vom Eigentümer der entsprechenden Kompatibilitätsmatrix als unterstützt betrachtet werden.

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 derselben <hal> haben die ODER- Beziehung. Wenn zwei oder mehr angegeben sind, muss nur eine der Versionen implementiert werden. (Siehe DRM-Beispiel unten.)
  • Mehrere <instance> - und <regex-instance> -Elemente innerhalb derselben <hal> werden mit einer einzigen UND- Beziehung ausgewertet, wenn <hal> erforderlich ist. (Siehe die DRM-Beispiel unten.)

Beispiel: Erfolgreicher HAL-Match für ein Modul

Für eine 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 ist die mindestens erforderliche Version, was bedeutet, dass ein Manifest, das HAL 2.0-2.4 bereitstellt, nicht kompatibel ist.
  • 2.7 ist die maximale Version, die angefordert werden kann, was bedeutet, dass der Eigentümer der Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen über 2.7 hinaus anfordern wird. Der Eigentümer des übereinstimmenden Manifests kann immer noch Version 2.10 (als Beispiel) bereitstellen, wenn 2.7 angefordert wird. Der Eigentümer der Kompatibilitätsmatrix weiß nur, dass der angeforderte Dienst mit der API-Version 2.7 kompatibel ist.
  • -7 dient nur zu Informationszwecken und wirkt sich nicht auf den OTA-Aktualisierungsprozess aus.
Daher bleibt ein Gerät mit einer HAL in Version 2.10 in seiner Manifestdatei mit einem Framework kompatibel, das in seiner Kompatibilitätsmatrix 2.5-7 angibt.

Beispiel: Erfolgreicher HAL-Match für das 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 >= 0
ODER
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, mit der Ausnahme, 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 kennzeichnen.
  • Mehrere <instance> - und <regex-instance> -Elemente innerhalb derselben <hal> werden mit einer einzigen UND- Beziehung ausgewertet, wenn <hal> erforderlich ist. (Siehe die Vibrationsbeispiel unten.)

Beispiel: Erfolgreicher HAL-Match für ein Modul

Für eine 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 ist die mindestens erforderliche Version, was bedeutet, dass ein Manifest, das HAL 1-4 bereitstellt, nicht kompatibel ist.
  • 7 ist die maximale Version, die angefordert werden kann, was bedeutet, dass der Besitzer der Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen über 7 anfordert. Der Besitzer des übereinstimmenden Manifests kann immer noch Version 10 (als Beispiel) bereitstellen, wenn 7 angefordert wird . Der Besitzer der Kompatibilitätsmatrix weiß nur, dass der angeforderte Dienst mit der API-Version 7 kompatibel ist.
  • -7 dient nur zu Informationszwecken und wirkt sich nicht auf den OTA-Aktualisierungsprozess aus.
Somit bleibt ein Gerät mit einer HAL in Version 10 in seiner Manifestdatei mit einem Framework kompatibel, das in seiner Kompatibilitätsmatrix 5-7 angibt.

Beispiel: Erfolgreiches HAL-Match für mehrere Module

Die Framework-Kompatibilitätsmatrix enthält die folgenden Versionsinformationen für Vibrator- 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 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-Matches

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.

Match-Kernel-Zweige

Jedes Kernel-Zweig-Suffix (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 explizit die Kernel-FCM-Version im Gerätemanifest, /vendor/etc/vintf/manifest.xml , angibt, wenn einer der folgenden Punkte zutrifft:

  • Die Kernel-FCM-Version unterscheidet sich von der Ziel-FCM-Version. Zum Beispiel hat das oben erwähnte Gerät eine Ziel-FCM-Version 4 und seine Kernel-FCM-Version ist 5 (Kernel-Zweig-Suffix r ).
  • Die Kernel-FCM-Version ist größer oder gleich 5 (Kernel-Zweig-Suffix r ).

VTS-Tests erzwingen, dass, wenn die Kernel-FCM-Version angegeben ist, die Kernel-FCM-Version größer oder gleich der Ziel-FCM-Version im Gerätemanifest ist.

Beispiel: Ermitteln Sie den Kernel-Zweig

Wenn das Gerät über Ziel-FCM-Version 4 (veröffentlicht in Android 10) verfügt, aber einen 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 Kernel-Kompatibilität anhand der Anforderungen des 4.19-r Kernel-Zweigs, der in FCM-Version 5 angegeben ist. Diese Anforderungen werden aus kernel/configs/r/android-4.19 im Android-Quellbaum erstellt.

Beispiel: Ermitteln Sie den Kernel-Zweig für GKI

Wenn das Gerät das generische Kernel-Image (GKI) verwendet und die Kernel-Release-Zeichenfolge aus /proc/version wie folgt lautet:

5.4.42-android12-0-00544-ged21d463f856

Dann erhält das VINTF-Objekt die Android-Version von der Kernel-Version und verwendet sie, um die Kernel-FCM-Version zu bestimmen. In diesem Beispiel bedeutet android12 Kernel FCM Version 6 (veröffentlicht in Android 12).

Einzelheiten dazu, wie der Kernel-Release-String analysiert wird, finden Sie unter GKI-Versionierung .

Kernel-Versionen abgleichen

Eine Matrix kann mehrere <kernel> -Abschnitte enthalten, jeder mit einem anderen version unter Verwendung des folgenden Formats:

${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. Außerdem muss die Nebenrevision aus dem Kernel ein Wert aus der Kompatibilitätsmatrix sein ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Wenn kein Abschnitt <kernel> diese Anforderungen erfüllt, handelt es sich um eine Nichtübereinstimmung.

Beispiel: Anforderungen für den Abgleich auswählen

Stellen Sie sich den folgenden hypothetischen Fall vor, 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 (Nichtübereinstimmung der Nebenversion)
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 Kernel-Zweig)
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) nicht spezifiziert 4.4.107 Keine Übereinstimmung (kein 4.4-q Kernel-Zweig)
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 Kernel-Zweig)
4 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) nicht spezifiziert irgendein VTS schlägt fehl (muss die Kernel-FCM-Version für die Ziel-FCM-Version 5 angeben)
5 (R) 4 (Q) irgendein VTS schlägt fehl (Kernel-FCM-Version < Ziel-FCM-Version)
5 (R) 5 (R) 4.14.180 4.14-r

Kernel-Konfigurationen abgleichen

Wenn der Abschnitt <kernel> übereinstimmt, wird der Prozess fortgesetzt, indem versucht wird, Konfigurationselemente mit config /proc/config.gz . Für jedes Konfigurationselement in der Kompatibilitätsmatrix wird nach /proc/config.gz , um zu sehen, ob die Konfiguration vorhanden ist. Wenn ein Konfigurationselement in der Kompatibilitätsmatrix für den übereinstimmenden Abschnitt <kernel> auf n gesetzt ist, darf 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 auch nicht.

Beispiel: Kernel-Konfigurationen abgleichen

  • <value type="string">bar</value> stimmt mit "bar" überein. Anführungszeichen werden in der Kompatibilitätsmatrix weggelassen, sind aber in /proc/config.gz vorhanden.
  • <value type="int">4096</value> entspricht 4096 oder 0x1000 oder 0X1000 .
  • <value type="int">0x1000</value> entspricht 4096 oder 0x1000 oder 0X1000 .
  • <value type="int">0X1000</value> entspricht 4096 oder 0x1000 oder 0X1000 .
  • <value type="tristate">y</value> stimmt mit y überein.
  • <value type="tristate">m</value> stimmt mit m überein.
  • <value type="tristate">n</value> bedeutet, dass das Konfigurationselement NICHT in /proc/config.gz existieren darf.
  • <value type="range">1-0x3</value> entspricht 1 , 2 oder 3 oder dem hexadezimalen Äquivalent.

Beispiel: Erfolgreicher Kernel-Match

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-Zweig 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:

  • 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 stattdessen die Kernel-Anforderungen aus der Matrix bei FCM-Version 2.

Dann wird die Kernel-Version abgeglichen. Wenn ein Gerät in uname() meldet:

  • 4.9.84 (keine Übereinstimmung mit Matrix, es sei denn, es gibt einen separaten Kernelabschnitt mit <kernel version="4.9.x"> , wobei x <= 84 )
  • 4.14.41 (keine Übereinstimmung mit Matrix, kleiner als version )
  • 4.14.42 (Übereinstimmung mit Matrix)
  • 4.14.43 (Übereinstimmung mit Matrix)
  • 4.1.22 (keine Übereinstimmung mit Matrix, es sei denn, es gibt einen separaten Kernelabschnitt mit <kernel version="4.1.x"> wobei x <= 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> genau mit dem Text nach dem Gleichheitszeichen (einschließlich Anführungszeichen) bis zum Zeilenumbruchzeichen oder # übereinstimmt, wobei führende und abschließende Leerzeichen abgeschnitten werden.

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

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 einen dieser Bereiche fallen, um mit dem Framework kompatibel zu sein. Übereinstimmungsregeln ähneln HAL-Versionen; es ist eine Übereinstimmung, wenn die sepolicy-Version höher oder gleich der Mindestversion für den Bereich ist. Die maximale Version ist rein informativ.
  • <kernel-sepolicy-version> dh policydb-Version. Muss kleiner sein als die vom Gerät gemeldete security_policyvers() .

Beispiel: Erfolgreiche SE-Richtlinienübereinstimmung

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 ist es keine Übereinstimmung. Zum Beispiel:
    • Wenn ein Gerät 29 zurückgibt, ist es keine Übereinstimmung.
    • Wenn ein Gerät 31 zurückgibt, ist es eine Übereinstimmung.
  • Die SE-Richtlinienversion muss 25.0-∞ oder 26.0-∞ sein. Sonst passt es nicht. (Das „ -3 “ nach „ 26.0 “ ist rein informativ.)

AVB-Version passt

Die AVB-Version enthält eine MAJOR-Version und eine MINOR-Version mit dem Format MAJOR.MINOR (z. B. 1.0, 2.1). Einzelheiten finden Sie unter Versionierung 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 im Android OS ( init/fs_mgr )

Die Systemeigenschaft wird nur angezeigt, wenn die entsprechende libavb verwendet wurde, um AVB-Metadaten zu überprüfen (und OK zurückgibt). Es fehlt, wenn ein Überprüfungsfehler aufgetreten ist (oder überhaupt keine Überprüfung stattgefunden hat).

Ein Kompatibilitätsmatch vergleicht Folgendes:

  • sysprop ro.boot.vbmeta.avb_version mit avb.vbmeta-version aus 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 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 kann zwei Kopien von libavb Bibliotheken enthalten, jede mit einer anderen MAJOR-Version für Upgrade-Geräte und Startgeräte. In diesem Fall kann dasselbe nicht signierte Systemabbild geteilt werden, aber die endgültigen signierten Systemabbilder sind unterschiedlich (mit unterschiedlicher avb.vbmeta-version ):

Abbildung 1. AVB-Versionsübereinstimmungen ( /system ist P, alle anderen Partitionen sind O).


Abbildung 2. AVB-Versionsübereinstimmungen (alle Partitionen sind 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 

Passende AVB-Version während OTA

Für Geräte, 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 Hauptversions-Upgrade hat (z. B. von 0.0 auf 1.0), spiegelt die VINTF-Prüfung auf Kompatibilität in OTA nicht die Kompatibilität nach dem OTA wider.

Um das Problem zu mindern, kann ein OEM eine gefälschte AVB-Version in das OTA-Paket ( compatibility.zip ) einfügen, um die Prüfung zu bestehen. Dazu:

  1. Wählen Sie die folgenden CLs für den Quellbaum von Android 9 aus:
  2. Definieren Sie BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE für das Gerät. Sein Wert sollte der AVB-Version vor dem OTA entsprechen, dh der AVB-Version des Geräts, als es gestartet wurde.
  3. Erstellen Sie das OTA-Paket neu.

Diese Änderungen platzieren automatisch BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE als compatibility-matrix.avb.vbmeta-version in den folgenden Dateien:

  • /system/compatibility_matrix.xml (die in Android 9 nicht verwendet wird) 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 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 auferlegt, und daher wird sie immer als Übereinstimmung betrachtet.

Wenn die Gerätekompatibilitätsmatrix über ein <vendor-ndk> -Tag verfügt, wird ein <vendor-ndk> -Eintrag mit einer übereinstimmenden <version> aus dem Satz von VNDK-Anbieter-Snapshots gesucht, die vom Framework im Framework-Manifest bereitgestellt werden. 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 ein Teilsatz des Satzes von Bibliotheken sein, der im Rahmenmanifest angegeben ist; Andernfalls wird der Eintrag nicht als Übereinstimmung betrachtet.

  • Wenn in der Gerätekompatibilitätsmatrix keine Bibliotheken aufgeführt sind, wird der Eintrag als Sonderfall immer als Übereinstimmung betrachtet, da eine leere Menge eine Teilmenge einer beliebigen Menge ist.

Beispiel: Erfolgreicher VNDK-Versionsabgleich

Wenn die Gerätekompatibilitätsmatrix die folgende Anforderung an VNDK angibt:

<!-- 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 sich VNDK Version 27 im Framework-Manifest befindet, wird libjpeg.so nicht vom Framework in diesem Snapshot 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 der Satz eine Teilmenge der bereitgestellten System-SDK-Versionen ist, wie in manifest.system-sdk.version im Frameworkmanifest deklariert.

  • Wenn in der Gerätekompatibilitätsmatrix keine System-SDK-Versionen aufgeführt sind, gilt dies als Sonderfall immer als Übereinstimmung, da eine leere Menge eine Teilmenge einer beliebigen Menge ist.

Beispiel: Erfolgreicher System-SDK-Versionsabgleich

Wenn die Gerätekompatibilitätsmatrix die folgende Anforderung an das System SDK angibt:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Dann muss das Framework System SDK Version 26 und 27 passend 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 System SDK Version 27 nicht bereitgestellt wird.