Übereinstimmungsregeln

Die beiden Paare aus Kompatibilitätsmatrizen und Manifesten sollen abgeglichen werden, um zu prüfen, ob das Framework und die Anbieterimplementierung miteinander kompatibel sind. 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 übereinstimmt.

Diese Überprüfung erfolgt zum Zeitpunkt des Builds, beim Generieren des OTA-Aktualisierungspakets, beim Starten und in VTS-Kompatibilitätstests.

In den folgenden Abschnitten werden die Zuordnungsregeln beschrieben, die von verschiedenen Komponenten verwendet werden.

Übereinstimmung der Version der Framework-Kompatibilitätsmatrix

Damit ein Gerätemanifest mit einer Framework-Kompatibilitätsmatrix abgeglichen werden kann, muss die von manifest.target-level angegebene FCM-Version genau mit der von compatibility-matrix.level angegebenen FCM-Version übereinstimmen. 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, die freigegebene FCM-Version abruft und die Framework-Kompatibilitätsmatrix für diese freigegebene FCM-Version zurückgibt (zusätzlich zu einigen optionalen HALs aus Kompatibilitätsmatrizen für höhere FCM-Versionen).

HAL-Übereinstimmungen

Die HAL-Abgleichsregel gibt die Versionen der hal-Elemente in einer Manifestdatei an, die vom Inhaber der entsprechenden Kompatibilitätsmatrix als unterstützt betrachtet werden.

HIDL und native HALs

Die Abgleichsregeln für HIDL und native HALs sind folgende:

  • Mehrere <hal>-Elemente werden mit einer einzigen AND-Beziehung ausgewertet.
  • <hal>-Elemente können <hal optional="true"> enthalten, um sie als nicht erforderlich zu kennzeichnen.
  • Mehrere <version>-Elemente innerhalb desselben <hal> haben die Beziehung ODER. Wenn zwei oder mehr angegeben sind, muss nur eine der Versionen implementiert werden. Weitere Informationen finden Sie unten im Beispiel für digitale Rechteverwaltung.
  • Mehrere <instance>- und <regex-instance>-Elemente innerhalb derselben <hal> werden mit einer einzigen AND-Beziehung ausgewertet, wenn <hal> erforderlich ist. (Siehe <ahref="#drm">DRM-Beispiel unten.)</ahref="#drm">

Beispiel: Erfolgreiche HAL-Übereinstimmung für ein Modul

Für eine HAL der Version 2.5 lautet die Abgleichsregel:

Matrix Übereinstimmendes Manifest
2.5 2,5–2,∞. In der Kompatibilitätsmatrix steht 2.5 für 2.5-5.
2.5-7 2.5–2.∞. Zeigt Folgendes an:
  • 2.5 ist die erforderliche Mindestversion, was bedeutet, dass ein Manifest mit HAL 2.0-2.4 nicht kompatibel ist.
  • 2.7 ist die maximale Version, die angefordert werden kann. Das bedeutet, dass der Inhaber der Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen über 2.7 anfordert. Der Inhaber des übereinstimmenden Manifests kann beispielsweise Version 2.10 bereitstellen, wenn Version 2.7 angefordert wird. Der Inhaber der Kompatibilitätsmatrix weiß nur, dass der angeforderte Dienst mit API-Version 2.7 kompatibel ist.
  • „-7“ dient nur zu Informationszwecken und hat keinen Einfluss auf den Over-the-air-Update-Vorgang.
Ein Gerät mit einer HAL-Version 2.10 in der Manifestdatei bleibt also mit einem Framework kompatibel, das in seiner Kompatibilitätsmatrix 2.5-7 angibt.

Beispiel: Erfolgreiche HAL-Übereinstimmung 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:

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
ODER 
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

UND müssen außerdem alle diese Instanzen implementiert sein:

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 ab Android 11 (außer Android 11) unterstützen Versionen für AIDL HALs in VINTF. Die Abgleichsregeln für AIDL-HALs ähneln denen von HIDL- und nativen HALs, mit der Ausnahme, dass es keine Hauptversionen gibt und genau eine Version pro HAL-Instanz vorhanden ist (1, wenn die Version nicht angegeben ist).

  • Mehrere <hal>-Elemente werden mit einer einzigen AND-Beziehung ausgewertet.
  • <hal>-Elemente können <hal optional="true"> enthalten, um sie als nicht erforderlich zu kennzeichnen.
  • Mehrere <instance>- und <regex-instance>-Elemente innerhalb derselben <hal> werden mit einer einzigen AND-Beziehung ausgewertet, wenn die <hal> erforderlich ist. Siehe dazu das <ahref="#vibrator">Vibrator-Beispiel unten.</ahref="#vibrator">

Beispiel: Erfolgreiche HAL-Übereinstimmung für ein Modul

Für einen HAL in Version 5 lautet die Übereinstimmungsregel:

Matrix Übereinstimmendes Manifest
5 5–∞. In der Kompatibilitätsmatrix steht 5 für 5-5.
5-7 5–∞. Gibt Folgendes an:
  • 5 ist die erforderliche Mindestversion. Das bedeutet, dass ein Manifest mit HAL 1–4 nicht kompatibel ist.
  • 7 ist die maximale Version, die angefordert werden kann. Das bedeutet, dass der Inhaber der Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen nach Version 7 anfordert. Der Inhaber des übereinstimmenden Manifests kann beispielsweise Version 10 bereitstellen, wenn Version 7 angefordert wird. Der Inhaber der Kompatibilitätsmatrix weiß nur, dass der angeforderte Dienst mit API-Version 7 kompatibel ist.
  • „-7“ dient nur zu Informationszwecken und hat keinen Einfluss auf den Over-the-air-Update-Vorgang.
Ein Gerät mit einer HAL-Version 10 in der Manifestdatei bleibt also mit einem Framework kompatibel, das in seiner Kompatibilitätsmatrix 5-7 angibt.

Beispiel: Erfolgreiche HAL-Übereinstimmung 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 diese Instanzen implementieren:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

Kernel-Übereinstimmungen

Im Abschnitt <kernel> der Framework-Kompatibilitätsmatrix werden die Anforderungen des Frameworks an den Linux-Kernel auf dem Gerät beschrieben. Diese Informationen sollen mit den Informationen über den Kernel abgeglichen werden, die vom VINTF-Objekt des Geräts gemeldet werden.

Übereinstimmung mit Kernel-Zweigen

Jedem Kernel-Zweig-Suffix (z. B. 5.4-r) wird eine eindeutige Kernel-FCM-Version (z. B. 5) zugeordnet. Die Zuordnung entspricht der Zuordnung zwischen Releasebuchstaben (z. B. R) und FCM-Versionen (z. B. 5).

Bei VTS-Tests wird erzwungen, dass das Gerät die FCM-Version des Kernels im Gerätemanifest /vendor/etc/vintf/manifest.xml explizit angibt, wenn eine der folgenden Bedingungen zutrifft:

  • Die FCM-Version des Kernels unterscheidet sich von der Ziel-FCM-Version. Beispiel: Das oben genannte Gerät hat als Ziel-FCM-Version 4 und die FCM-Kernel-Version 5 (Kernel-Zweig-Suffix r).
  • Die FCM-Version des Kernels ist mindestens 5 (Suffix des Kernelzweigs r).

VTS-Tests erzwingen, dass bei Angabe der FCM-Kernel-Version die FCM-Kernel-Version der FCM-Zielversion im Gerätemanifest entspricht oder höher ist.

Beispiel: Kernel-Branch ermitteln

Wenn auf dem Gerät die FCM-Zielversion 4 (veröffentlicht in Android 10) ausgeführt wird, aber der Kernel vom Zweig 4.19-r ausgeführt wird, sollte im Gerätemanifest Folgendes angegeben werden: 

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

Das VINTF-Objekt prüft die Kernelkompatibilität anhand der Anforderungen an 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 abgeleitet.

Beispiel: Kernel-Branch für GKI ermitteln

Wenn das Gerät das generische Kernel-Image (GKI) verwendet und der Kernel-Releasestring von /proc/version so lautet:

5.4.42-android12-0-00544-ged21d463f856

Das VINTF-Objekt ruft dann den Android-Release vom Kernel-Release ab und ermittelt damit die FCM-Kernel-Version. In diesem Beispiel steht android12 für die FCM-Version 6 des Kernels (veröffentlicht in Android 12).

Weitere Informationen zum Parsen des Kernel-Release-Strings finden Sie unter GKI-Versionierung.

Kernel-Versionen abgleichen

Eine Matrix kann mehrere <kernel>-Abschnitte mit jeweils einem anderen version-Attribut im folgenden Format enthalten:

${ver}.${major_rev}.${kernel_minor_rev}

Im VINTF-Objekt wird nur der Abschnitt <kernel> aus dem FCM mit der übereinstimmenden FCM-Version mit denselben ${ver} und ${major_rev} wie der Gerätekernel berücksichtigt (d.h. version="${ver}.${major_rev}.${matrix_minor_rev}"); andere Abschnitte werden ignoriert. Außerdem muss die Minor-Revision des Kernels ein Wert aus der Kompatibilitätsmatrix (${kernel_minor_rev} >= ${matrix_minor_rev};) sein. Wenn kein <kernel>-Abschnitt diese Anforderungen erfüllt, ist keine Übereinstimmung vorhanden.

Beispiel: Anforderungen für den Abgleich auswählen

Betrachten Sie den folgenden hypothetischen Fall, in dem FCMs in /system/etc/vintf die folgenden Anforderungen deklarieren (Header- und 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 -->

Anhand der Ziel-FCM-Version, der Kernel-FCM-Version und der Kernelversion werden die Kernelanforderungen aus den FCMs ausgewählt:

Ziel-FCM-VersionFCM-Kernel-VersionKernel-VersionAbgleichen mit
3 (P)nicht angegeben4.4.106 Keine Übereinstimmung (Unterscheidung zwischen Minor-Versionen nicht möglich)
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-Zweig)
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-Zweig)
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 (Sie müssen die Kernel-FCM-Version für die Ziel-FCM-Version 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

Kernelkonfigurationen abgleichen

Wenn der Abschnitt <kernel> übereinstimmt, wird versucht, config-Elemente mit /proc/config.gz abzugleichen. Für jedes Konfigurationselement in der Kompatibilitätsmatrix wird in /proc/config.gz geprüft, ob die Konfiguration vorhanden ist. Wenn ein Konfigurationselement in der Kompatibilitätsmatrix für den übereinstimmenden <kernel>-Abschnitt auf n festgelegt ist, darf es in /proc/config.gz nicht enthalten sein. Schließlich kann ein Konfigurationselement, das nicht in der Kompatibilitätsmatrix enthalten ist, in /proc/config.gz vorhanden sein oder nicht.

Beispiel: Kernelkonfigurationen abgleichen

  • <value type="string">bar</value> 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, 0x1000 oder 0X1000.
  • <value type="int">0x1000</value> stimmt mit 4096, 0x1000 oder 0X1000 überein.
  • <value type="int">0X1000</value> entspricht 4096, 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 vorhanden sein darf.
  • <value type="range">1-0x3</value> entspricht 1, 2 oder 3 oder einem hexadezimalen Äquivalent.

Beispiel: Erfolgreiche Kernelübereinstimmung

Eine Framework-Kompatibilitätsmatrix mit FCM-Version 1 enthält die folgenden Kernelinformationen:

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

Der Kernel-Branch wird zuerst abgeglichen. Der Kernel-Branch wird im Gerätemanifest unter manifest.kernel.target-level angegeben. Wenn dieser nicht angegeben ist, wird standardmäßig manifest.level verwendet. Wenn der Kernel-Branch im Gerätemanifest:

  • ist, wird mit dem nächsten Schritt fortgefahren und die Kernelversion wird geprüft.
  • ist 2, keine Übereinstimmung mit Matrix. Bei VINTF-Objekten werden die Kernelanforderungen stattdessen aus der Matrix in der FCM-Version 2 gelesen.

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">, wobei x <= 84)
  • 4.14.41 (keine Übereinstimmung mit Matrix, kleiner als version)
  • 4.14.42 (mit Matrix abgleichen)
  • 4.14.43 (mit Matrix abgleichen)
  • 4.1.22 (keine Übereinstimmung mit Matrix, es sei denn, es gibt einen separaten Kernelbereich mit <kernel version="4.1.x"> anstelle von x <= 22)

Nachdem der entsprechende <kernel>-Abschnitt ausgewählt wurde, erwarten wir, dass für jedes <config>-Element mit einem anderen Wert als n der entsprechende Eintrag in /proc/config.gz vorhanden ist. Für jedes <config>-Element mit dem Wert n gehen wir davon aus, dass der entsprechende Eintrag in /proc/config.gz nicht vorhanden ist. Der Inhalt von <value> muss genau mit dem Text nach dem Gleichheitszeichen (einschließlich Anführungszeichen) bis zum Zeilenumbruchszeichen oder # übereinstimmen. Anführende und abschließende Leerzeichen werden abgeschnitten.

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

Übereinstimmungen mit SE-Richtlinien

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 gibt eine Übereinstimmung, wenn die Sepolicy-Version höher oder gleich der Mindestversion für den Bereich ist. Die maximale Version dient nur zu Informationszwecken.
  • <kernel-sepolicy-version>, d.h. die policydb-Version. Muss kleiner als der vom Gerät gemeldete Wert security_policyvers() sein.

Beispiel: Erfolgreiche Übereinstimmung mit einer SE-Richtlinie

In der Framework-Kompatibilitätsmatrix sind die folgenden Informationen zu SEPolicy enthalten: 

<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 gibt es keine Übereinstimmung. Beispiel:
    • Wenn ein Gerät 29 zurückgibt, gibt es keine Übereinstimmung.
    • Wenn ein Gerät 31 zurückgibt, ist es eine Übereinstimmung.
  • Die Version der SE-Richtlinie muss 25.0-∞ oder 26.0-∞ sein. Andernfalls stimmt sie nicht überein. (Das „-3“ nach „26.0“ dient nur zu Informationszwecken.)

Übereinstimmungen der AVB-Version

Die AVB-Version enthält eine MAJOR- und eine MINOR-Version im Format MAJOR.MINOR (z.B. 1.0, 2.1). Weitere Informationen finden Sie unter Versionsverwaltung und Kompatibilität. Die AVB-Version hat die folgenden Systemeigenschaften:

  • ro.boot.vbmeta.avb_version ist die libavb-Version im Bootloader.
  • ro.boot.avb_version ist die libavb-Version des Android-Betriebssystems (init/fs_mgr).

Die Systemeigenschaft wird nur angezeigt, wenn die entsprechende libavb zur Überprüfung von AVB-Metadaten verwendet wurde (und „OK“ zurückgibt). Sie ist nicht vorhanden, wenn ein Überprüfungsfehler aufgetreten ist (oder keine Überprüfung stattgefunden hat).

Bei einer Kompatibilitätsübereinstimmung werden folgende Elemente verglichen:

  • sysprop ro.boot.vbmeta.avb_version mit avb.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 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- und Launch-Geräte. In diesem Fall kann dasselbe unsignierte System-Image freigegeben werden, die endgültigen signierten System-Images sind jedoch unterschiedlich (mit unterschiedlichen avb.vbmeta-version):

Abbildung 1. Die AVB-Version stimmt überein (/system ist P, alle anderen Partitionen sind O).



Abbildung 2: AVB-Version stimmt überein (alle Partitionen sind P).

Beispiel: Erfolgreiche Übereinstimmung der AVB-Version

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 der OTA-Aktualisierung abgleichen

Bei Geräten, die mit Android 9 oder niedriger auf den Markt gebracht wurden, werden die Anforderungen an die AVB-Version in der Framework-Kompatibilitätsmatrix beim Aktualisieren auf Android 10 mit der aktuellen AVB-Version auf dem Gerät abgeglichen. Wenn die AVB-Version während eines Over-the-air-Updates (OTA) ein Hauptversionsupgrade durchläuft (z. B. von 0.0 auf 1.0), entspricht die VINTF-Kompatibilitätsprüfung bei OTA nicht der Kompatibilität nach dem OTA.

Um das Problem zu vermeiden, 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 so vor:

  1. Fügen Sie die folgenden CLs dem Android 9-Quellbaum hinzu:
  2. Definieren Sie BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE für das Gerät. Der Wert muss der AVB-Version vor der OTA-Aktualisierung entsprechen, also der AVB-Version des Geräts bei der Markteinführung.
  3. Erstellen Sie das OTA-Paket neu.

Durch diese Änderungen wird BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE in den folgenden Dateien automatisch als compatibility-matrix.avb.vbmeta-version angezeigt:

  • /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 haben keine Auswirkungen auf andere Framework-Kompatibilitätsmatrizen, einschließlich /system/etc/vintf/compatibility_matrix.xml. Nach der Over-the-air-Aktualisierung wird stattdessen der neue Wert in /system/etc/vintf/compatibility_matrix.xml für die Kompatibilitätsprüfung verwendet.

Übereinstimmung der VNDK-Version

In der Gerätekompatibilitätsmatrix wird die erforderliche VNDK-Version in compatibility-matrix.vendor-ndk.version angegeben. Wenn die Gerätekompatibilitätsmatrix kein <vendor-ndk>-Tag enthält, werden keine Anforderungen festgelegt und es wird daher immer als Übereinstimmung betrachtet.

Wenn die Gerätekompatibilitätsmatrix ein <vendor-ndk>-Tag hat, wird ein <vendor-ndk>-Eintrag mit einem übereinstimmenden <version> aus dem Satz von VNDK-Anbieter-Snapshots abgerufen, der vom Framework im Framework-Manifest bereitgestellt wird. Wenn ein solcher Eintrag nicht existiert, gibt es keine Übereinstimmung.

Wenn ein solcher Eintrag vorhanden ist, muss die in der Gerätekompatibilitätsmatrix aufgeführte Gruppe von Bibliotheken eine Teilmenge der im Framework-Manifest angegebenen Bibliotheken sein. Andernfalls wird der Eintrag nicht als Übereinstimmung betrachtet.

  • Als Sonderfall gilt: Wenn in der Gerätekompatibilitätsmatrix keine Bibliotheken aufgeführt sind, wird der Eintrag immer als Übereinstimmung betrachtet, da ein leerer Satz eine Teilmenge eines beliebigen Satzes ist.

Beispiel: Erfolgreiche Übereinstimmung 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 ein Treffer, da VNDK-Version 27 im Framework-Manifest und in {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} enthalten ist. 

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

Beispiel B ist keine Übereinstimmung. Obwohl VNDK-Version 27 im Framework-Manifest enthalten ist, wird libjpeg.so in diesem Snapshot vom Framework nicht unterstützt. VNDK-Version 26 wird ignoriert.

System SDK-Version stimmt überein

In der Gerätekompatibilitätsmatrix wird in compatibility-matrix.system-sdk.version eine Reihe erforderlicher System-SDK-Versionen deklariert. Es gibt nur dann eine Übereinstimmung, wenn die Gruppe eine Teilmenge der bereitgestellten System-SDK-Versionen ist, wie in manifest.system-sdk.version im Framework-Manifest angegeben.

  • Als Sonderfall gilt: Wenn in der Gerätekompatibilitätsmatrix keine System-SDK-Versionen aufgeführt sind, wird immer eine Übereinstimmung angenommen, da ein leerer Satz eine Teilmenge eines beliebigen Satzes ist.

Beispiel: Erfolgreiche Übereinstimmung der System-SDK-Version

Wenn in der Gerätekompatibilitätsmatrix die folgende Anforderung an das System-SDK angegeben ist: 

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

Das Framework muss dann die System-SDK-Versionen 26 und 27 bereitstellen, damit sie übereinstimmen.

<!-- 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 ein Treffer.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

Beispiel C passt nicht, da die System-SDK-Version 27 nicht angegeben ist.