Übereinstimmungsregeln

Die beiden Paare von Kompatibilitätsmatrizen und Manifesten sollen abgeglichen werden, um zu prüfen, ob das Framework und die Anbieterimplementierung miteinander funktionieren. Diese Überprüfung ist erfolgreich, wenn die Framework-Kompatibilitätsmatrix und das Gerätemanifest sowie das Framework-Manifest und die Gerätekompatibilitätsmatrix übereinstimmen.

Diese Überprüfung erfolgt zur Build-Zeit, bei der Generierung des OTA-Aktualisierungspakets, zur Boot-Zeit und in VTS-Kompatibilitätstests.

In den folgenden Abschnitten werden die von den verschiedenen Komponenten verwendeten Abgleichsregeln beschrieben.

Versionen der Framework-Kompatibilitätsmatrix stimmen überein

Damit ein Geräte-Manifest mit einer Framework-Kompatibilitätsmatrix übereinstimmt, muss die von manifest.target-level angegebene FCM-Version genau der von compatibility-matrix.level angegebenen FCM-Version entsprechen. Andernfalls gibt es keine Übereinstimmung.

Wenn die Framework-Kompatibilitätsmatrix mit libvintf angefordert wird, ist dieser Abgleich immer erfolgreich, da libvintf das Gerätemanifest öffnet, die ausgelieferte FCM-Version abruft und die Framework-Kompatibilitätsmatrix in dieser ausgelieferten FCM-Version zurückgibt (plus einiger optionaler HALs aus Kompatibilitätsmatrizen in höheren FCM-Versionen).

HAL-Übereinstimmungen

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

HIDL- und native HALs

Die Abgleichsregeln für HIDL- und native HALs sind wie folgt:

  • Mehrere <hal>-Elemente werden mit einer einzelnen UND-Beziehung ausgewertet.
  • <hal>-Elemente können <hal optional="true"> enthalten, um sie als nicht erforderlich zu markieren.
  • Mehrere <version>-Elemente innerhalb desselben <hal>-Elements haben eine ODER-Beziehung. Wenn zwei oder mehr angegeben sind, muss nur eine der Versionen implementiert werden. Weitere Informationen finden Sie unter Erfolgreicher HAL-Abgleich für DRM-Modul.
  • Mehrere <instance>- und <regex-instance>-Elemente innerhalb desselben <hal>-Elements werden mit einer einzelnen UND-Beziehung ausgewertet, wenn das <hal>-Element erforderlich ist. Weitere Informationen finden Sie unter Erfolgreicher HAL-Abgleich für DRM-Modul.

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

Für einen HAL in Version 2.5 lautet die Abgleichsregel so:

Matrix Passendes Manifest
2.5 2.5–2.∞. In der Kompatibilitätsmatrix ist 2.5 die Kurzform für 2.5-5.
2.5-7 2.5–2.∞. Gibt Folgendes an:
  • 2.5 ist die erforderliche Mindestversion. Ein Manifest mit HAL 2.0 bis 2.4 ist also nicht kompatibel.
  • 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 hinaus anfordern kann. Der Inhaber des übereinstimmenden Manifests kann weiterhin Version 2.10 (als Beispiel) 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 zur Information und hat keinen Einfluss auf den OTA-Aktualisierungsprozess.
Ein Gerät mit einem HAL in Version 2.10 in seiner Manifestdatei bleibt also mit einem Framework kompatibel, in dessen Kompatibilitätsmatrix 2.5-7 angegeben ist.

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

In der Framework-Kompatibilitätsmatrix werden die folgenden Versionsinformationen für die DRM HAL angegeben:

<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 muss 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

Android und höher unterstützt Versionen für AIDL-HALs in VINTF. Die Übereinstimmungsregeln für AIDL-HALs ähneln denen von HIDL- und nativen HALs. Es gibt jedoch keine Hauptversionen und genau eine Version pro HAL-Instanz (1, wenn die Version nicht angegeben ist):

  • Mehrere <hal>-Elemente werden mit einer einzelnen UND-Beziehung ausgewertet.
  • <hal>-Elemente können <hal optional="true"> enthalten, um sie als nicht erforderlich zu kennzeichnen.
  • Mehrere <instance>- und <regex-instance>-Elemente innerhalb desselben <hal> werden mit einer einzelnen UND-Beziehung ausgewertet, wenn das <hal> erforderlich ist. Weitere Informationen finden Sie unter Erfolgreicher HAL-Abgleich für mehrere Module.

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

Für einen HAL in Version 5 lautet die Abgleichsregel so:

Matrix Passendes Manifest
5 5–∞. In der Kompatibilitätsmatrix ist 5 die Kurzform für 5-5.
5-7 5–∞: Gibt Folgendes an:
  • 5 ist die erforderliche Mindestversion. Ein Manifest mit HAL 1–4 ist also nicht kompatibel.
  • 7 ist die maximale Version, die angefordert werden kann. Das bedeutet, dass der Inhaber der Kompatibilitätsmatrix (Framework oder Gerät) keine Versionen über 7 hinaus anfordert. Der Inhaber des übereinstimmenden Manifests kann weiterhin Version 10 (als Beispiel) 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 zur Information und hat keinen Einfluss auf den OTA-Aktualisierungsprozess.
Ein Gerät mit einem HAL der Version 10 in seiner Manifestdatei bleibt also mit einem Framework kompatibel, das 5-7 in seiner Kompatibilitätsmatrix angibt.

Beispiel: Erfolgreicher HAL-Abgleich für mehrere Module

In der Framework-Kompatibilitätsmatrix werden die folgenden Versionsinformationen für Vibrator- und Kamera-HALs angegeben:

<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 zum Kernel abgeglichen werden, die vom VINTF-Objekt des Geräts gemeldet werden.

Kernel-Branches abgleichen

Jedes Kernel-Branch-Suffix (z. B. 5.4-r) wird einer eindeutigen Kernel-FCM-Version (z. B. 5) zugeordnet. Die Zuordnung ist dieselbe wie die Zuordnung zwischen Release-Buchstaben (z. B. R) und FCM-Versionen (z. B. 5).

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

  • Die Kernel-FCM-Version unterscheidet sich von der Ziel-FCM-Version. Das oben erwähnte Gerät hat beispielsweise die Ziel-FCM-Version 4 und die Kernel-FCM-Version 5 (Kernel-Branch-Suffix r).
  • Die Kernel-FCM-Version ist mindestens 5 (Kernel-Branch-Suffix r).

VTS-Tests erzwingen, dass die Kernel-FCM-Version, falls angegeben, größer oder gleich der Ziel-FCM-Version im Gerätemanifest 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 aus dem 4.19-r-Branch stammt, sollte im Gerätemanifest Folgendes angegeben werden: 

<manifest version="2.0" type="device" t<arget-level="4"&g<t;
   kernel target-level="5" />
/manifest>

Das VINTF-Objekt prüft die Kernelkompatibilität anhand der Anforderungen für den 4.19-r-Kernelzweig, der in FCM-Version 5 angegeben ist. Diese Anforderungen basieren auf kernel/configs/r/android-4.19 im Android-Quellbaum.

Beispiel: Kernel-Branch für GKI ermitteln

Wenn auf dem Gerät das Generic Kernel Image (GKI) verwendet wird und der Kernel-Release-String aus /proc/version so aussieht:

5.4.42-android12-0-00544-ged21d463f856

Das VINTF-Objekt ruft dann die Android-Version aus der Kernel-Version ab und verwendet sie, um die Kernel-FCM-Version zu bestimmen. In diesem Beispiel steht android12 für die Kernel-FCM-Version 6 (veröffentlicht in Android 12).

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

Kernel-Versionen abgleichen

Eine Matrix kann mehrere <kernel>-Abschnitte enthalten, die jeweils ein anderes version-Attribut im folgenden Format verwenden:

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

Das VINTF-Objekt berücksichtigt nur den <kernel>-Abschnitt des FCM mit passender FCM-Version mit derselben ${ver} und ${major_rev} wie der Geräte-Kernel (d. h. version="${ver}.${major_rev}.${matrix_minor_rev}")). Andere Abschnitte werden ignoriert. Außerdem muss die Nebenversionsnummer des Kernels ein Wert aus der Kompatibilitätsmatrix (${kernel_minor_rev} >= ${matrix_minor_rev}) sein. Wenn kein <kernel>-Abschnitt diese Anforderungen erfüllt, liegt keine Übereinstimmung vor.

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 Footer-Tags werden weggelassen):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" le<vel="3"/>
!-- See kernel/configs/p/android-4.4/ fo>r< 4.4-p requirements --
kernel versio<n="4.9.84" level="3"/>
!-- See kernel/co>n<figs/p/android-4.9/ for 4.9-p require<ments --
kernel version="4.14.42" level="3"/&>gt<;
!-- See kernel/configs/p/androi>d<-4.14/ for 4.14-p requirements --

!-<- compatibility_matrix.4.xml --
kernel version="4.9.165&qu>o<t; level="4"/>
!-- See ke<rnel/configs/q/android-4.9/ for 4.9-q requirements --
kernel vers>i<on="4.14.105" level="4<"/>
!-- See kernel/configs/q/android-4.14/ for 4.14-q req>ui<rements --
kernel version="4>.<19.42" level="4"/>
!<-- See kernel/configs/q/android-4.19/ for 4.19-q requirements --<>/span>

<!-- compatibility_matrix.5.xml --
kern<el version="4.14.180" level="5"/>
!-- See >k<ernel/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 legen gemeinsam die Kernelanforderungen der FCMs fest:

FCM-ZielversionKernel-FCM-VersionKernel-VersionAbgleichen mit
3 (P)Ohne Angabe4.4.106Keine Übereinstimmung (geringfügige Versionsabweichung)
3 (P)Ohne Angabe4.4.1074.4-p
3 (P)Ohne Angabe4.19.424.19-q (siehe Hinweis nach der Tabelle)
3 (P)Ohne Angabe5.4.415.4-r (siehe Hinweis nach der Tabelle)
3 (P)3 (P)4.4.1074.4-p
3 (P)3 (P)4.19.42Keine Übereinstimmung (kein 4.19-p-Kernelzweig)
3 (P)4 (Q)4.19.424.19-q
4 (Q)Ohne Angabe4.4.107Keine Übereinstimmung (kein 4.4-q-Kernelzweig)
4 (Q)Ohne Angabe4.9.1654.9-q
4 (Q)Ohne Angabe5.4.415.4-r (siehe Hinweis nach der Tabelle)
4 (Q)4 (Q)4.9.1654.9-q
4 (Q)4 (Q)5.4.41Keine Übereinstimmung (kein 5.4-q-Kernelzweig)
4 (Q)5 (R)4.14.1054.14-r
4 (Q)5 (R)5.4.415.4-r
5 (R)Ohne AngabebeliebigVTS-Fehler (die Kernel-FCM-Version muss für die Ziel-FCM-Version 5 angegeben werden)
5 (R)4 (Q)beliebigVTS-Fehler (Kernel-FCM-Version < Ziel-FCM-Version)
5 (R)5 (R)4.14.1804.14-r

Kernelkonfigurationen abgleichen

Wenn der Abschnitt <kernel> übereinstimmt, wird der Prozess fortgesetzt, indem versucht wird, config-Elemente mit /proc/config.gz abzugleichen. Für jedes Konfigurationselement in der Kompatibilitätsmatrix wird in /proc/config.gz nachgesehen, ob die Konfiguration vorhanden ist. Wenn ein Konfigurationselement im entsprechenden <kernel>-Abschnitt der Kompatibilitätsmatrix auf n gesetzt ist, muss 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 nicht.

Beispiel: Kernelkonfigurationen abgleichen

  • <value type="string">bar</value> entspricht "bar". Anführungszeichen werden in der Kompatibilitätsmatrix ausgelassen, sind aber in /proc/config.gz vorhanden.
  • <value type="int">4096</value> entspricht 4096, 0x1000 oder 0X1000.
  • <value type="int">0x1000</value> entspricht 4096, 0x1000 oder 0X1000.
  • <value type="int">0X1000</value> entspricht 4096, 0x1000 oder 0X1000.
  • <value type="tristate">y</value> entspricht y.
  • <value type="tristate">m</value> entspricht m.
  • <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 dem hexadezimalen Äquivalent.

Beispiel: Erfolgreiche Kernel-Übereinstimmung

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

<kernel version="4.1>4.42<">
   con<fig>
      key<CONF>IG_TRI/<key
      value type=>&<quot;t>rist<ate&quo>t;y/<value
>   /con<fig>
   config
   <   k>eyCONFI<G_NOEXIST/key
      v>a<lue ty>pe=&<quot;tr>ista<te&quo>t;n/val<ue<>/span>
   /config<
   >config
<      keyCONFIG_>DEC/<key
  >    <value t>ype=<">int&quo<t;4>096/value
<   />config
<   config
      >keyCON<FIG_HE>X/ke<y
     > val<ue typ>e="<;in>t"0XD<EAD/>value
 <  /config
   config>
  <    ke>yCON<FIG_STR>/key<
     > value <typ>e="stri<ng&q>uot;str</value
   /config
 ><  conf>ig
 <     ke>y<CONFIG_>EMPTY/key
      value type="string"/value
   /config
/kernel

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

  • Wenn der Kernel-Branch im Geräte-Manifest 1 ist, wird mit dem nächsten Schritt fortgefahren und die Kernel-Version wird geprüft.
  • Wenn der Kernel-Branch im Gerätemanifest 2 ist, gibt es keine Übereinstimmung mit der Matrix. VINTF-Objekte lesen die Kernelanforderungen stattdessen aus der Matrix in FCM-Version 2.

Anschließend wird die Kernelversion abgeglichen. Wenn ein Gerät in uname() Folgendes meldet:

  • 4.9.84 (keine Übereinstimmung mit der Matrix, sofern es keinen separaten Kernel-Abschnitt mit <kernel version="4.9.x"> gibt, wobei x <= 84)
  • 4.14.41 (keine Übereinstimmung mit Matrix, kleiner als version)
  • 4.14.42 (entspricht der Matrix)
  • 4.14.43 (mit Matrix abgleichen)
  • 4.1.22 (keine Übereinstimmung mit der Matrix, sofern kein separater Kernelabschnitt mit <kernel version="4.1.x"> vorhanden ist, wobei x <= 22)

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

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

SEPolicy-Übereinstimmungen

Für SEPolicy sind die folgenden Übereinstimmungen erforderlich:

  • <sepolicy-version> definiert für jede Hauptversion einen geschlossenen Bereich von Nebenversionen. Die vom Gerät gemeldete SEPolicy-Version muss in einem dieser Bereiche liegen, damit sie mit dem Framework kompatibel ist. Abgleichsregeln ähneln HAL-Versionen. Es liegt ein Abgleich vor, 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 Policy-DB-Version, muss kleiner als security_policyvers() sein, die vom Gerät gemeldet wird.

Beispiel: Erfolgreicher SEPolicy-Abgleich

Die Framework-Kompatibilitätsmatrix enthält die folgenden SEPolicy-Informationen: 

<sepolicy>
 <   kernel-sepolicy-version<>30/kernel-sepolicy-version<>
    sepolicy-ver<sion>25.0/sepolicy-v<ersion>
    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 liegt keine Übereinstimmung vor. Beispiel:
    • Wenn ein Gerät „29“ zurückgibt, liegt keine Übereinstimmung vor.
    • Wenn ein Gerät 31 zurückgibt, ist es ein Match.
  • Die SEPolicy-Version muss 25.0–∞ oder 26.0–∞ sein. Andernfalls liegt keine Übereinstimmung vor. Die -3 nach 26.0 dient nur zur Information.

AVB-Versionsübereinstimmungen

Die AVB-Version enthält eine MAJOR-Version 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 im Android-Betriebssystem (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 Bestätigungsfehler aufgetreten ist oder keine Bestätigung stattgefunden hat.

Bei einem Kompatibilitätsabgleich werden die folgenden 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, jeweils mit einer anderen MAJOR-Version für Upgrade- und Launch-Geräte. In diesem Fall kann dasselbe nicht signierte 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 AVB-Versionsübereinstimmung

In der Framework-Kompatibilitätsmatrix sind die folgenden AVB-Informationen angegeben:

<avb>
 <   vbmeta-version&<gt;2.1/vbmeta-ver<sion>
/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

Bei Geräten, die mit Android 9 oder niedriger auf den Markt gekommen sind, werden beim Aktualisieren 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 erhält (z. B. von 0.0 auf 1.0), spiegelt die VINTF-Prüfung der Kompatibilität im OTA nicht die Kompatibilität nach dem OTA wider.

Um das Problem zu beheben, kann ein OEM eine gefälschte AVB-Version in das OTA-Paket (compatibility.zip) einfügen, damit die Prüfung bestanden wird. Gehen Sie dazu folgendermaßen vor:

  1. Wählen Sie die folgenden CLs für den Android 9-Quellbaum aus:
  2. Definieren Sie BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE für das Gerät. Der Wert sollte der AVB-Version vor dem OTA entsprechen, d. h. der AVB-Version des Geräts bei der Markteinführung.
  3. Erstelle das OTA-Paket neu.

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

  • /system/compatibility_matrix.xml (wird in Android 9 nicht verwendet) 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 dem OTA wird stattdessen der neue Wert in /system/etc/vintf/compatibility_matrix.xml für Kompatibilitätsprüfungen verwendet.

VNDK-Version stimmt überein

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

Wenn die Gerätekompatibilitätsmatrix ein <vendor-ndk>-Tag enthält, wird aus der Menge der VNDK-Anbietersnapshots, die vom Framework im Framework-Manifest bereitgestellt werden, ein <vendor-ndk>-Eintrag mit einem passenden <version> gesucht. Wenn ein solcher Eintrag nicht vorhanden ist, gibt es keine Übereinstimmung.

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

  • Als Sonderfall gilt ein Eintrag immer als Übereinstimmung, wenn in der Gerätekompatibilitätsmatrix keine Bibliotheken aufgeführt sind, da eine leere Menge eine Teilmenge jeder Menge ist.

Beispiel: Erfolgreiche VNDK-Versionsübereinstimmung

Wenn in der Gerätekompatibilitätsmatrix die folgende VNDK-Anforderung angegeben ist: 

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
 <   version<>27/version<>
    library&g<t;libjpeg.so/l<ibrary>
    lib<rary>li<bbase.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&g<t;libjpeg.so/l<ibrary>
    lib<rary>libbas<e.so/library>
<    librar<y>libfoo.so/library>
/vendor-ndk>

Beispiel A ist eine Übereinstimmung, da die VNDK-Version 27 im Framework-Manifest und {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} enthalten ist. 

<!-- Framework Manifest Example B -->
<vendor-ndk>
 <   version<>26/version<>
    library&g<t;libjpeg.so/l<ibrary>
    lib<rary>li<bbase.so/libr<ary>
/vendor-<ndk>
ve<ndor-ndk>
 <   version>27/v<ersion><
    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 nicht vom Framework unterstützt. VNDK-Version 26 wird ignoriert.

System‑SDK-Version stimmt überein

In der Gerätekompatibilitätsmatrix wird eine Reihe von erforderlichen System-SDK-Versionen in compatibility-matrix.system-sdk.version angegeben. Eine Übereinstimmung liegt nur vor, wenn die Menge eine Teilmenge der bereitgestellten System-SDK-Versionen ist, die im Framework-Manifest in manifest.system-sdk.version deklariert sind.

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

Beispiel: Erfolgreicher Abgleich der System‑SDK-Version

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

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

Das Framework muss dann die System-SDK-Versionen 26 und 27 bereitstellen:

<!-- Framework Manifest Example A -->
<system-sdk>
 <   version<>26/version<>
    v<ersion><27/version>
/system-sdk>

Beispiel A ist eine Übereinstimmung:

<!-- Framework Manifest Example B -->
<system-sdk>
 <   version<>26/version<>
    v<ersion>27/v<ersion><
    versi<on>28/version>
/system-sdk>

Beispiel B ist eine Übereinstimmung:

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

Beispiel C ist keine Übereinstimmung, da die System-SDK-Version 27 nicht angegeben ist.