Versionsinformationen in AVB-Properties

Zur Unterstützung der KeyMint-Versionsbindung (ehemals Keymaster) muss der Bootloader des Geräts die Betriebssystemversion und die Sicherheitsupdate-Ebene für jede Partition bereitstellen. Die Betriebssystemversion und die Sicherheits update-Ebene sind zwei separate Schlüssel-Wert-Paare in den AVB Eigenschaften. Beispiel:

  • com.android.build.system.os_version -> '12'
  • com.android.build.system.security_patch -> '2022-02-05'
  • com.android.build.vendor.os_version -> '12'
  • com.android.build.vendor.security_patch -> '2022-02-05'
  • com.android.build.boot.os_version -> '12'
  • com.android.build.boot.security_patch -> '2022-02-05'

Der Bootloader des Geräts kann diese AVB-Eigenschaften mit avb_property_lookup() aus einem vbmeta-Image abrufen. Mehrere vbmeta-Images können mit avb_slot_verify() geladen und im AvbSlotVerifyData** out_data Ausgabeparameter gespeichert werden.

Standardformat der Versionsinformationen

Standardmäßig verwendet das Android-Buildsystem das folgende Format für die Betriebssystemversion bzw. das Sicherheitsupdate.

Das Format von com.android.build.${partition}.os_version ist A[.B.C], z. B. 12 oder 12.0.0:

  • A: Hauptversion
  • B: Nebenversion, standardmäßig null, wenn nicht vorhanden
  • C: Unterversion, standardmäßig null, wenn nicht vorhanden

Das Format von com.android.build.${partition}.security_patch ist JJJJ-MM-TT.

Standardmäßig generiert das Build-System com.android.build.${partition}.security_patch für die system, system_ext, und product Partitionen. Der Gerätehersteller muss BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH und andere Updates für Nicht-Systempartitionen festlegen. Beispiel:

  • BOOT_SECURITY_PATCH := 2022-01-05 generiert
    • com.android.build.boot.security_patch -> '2022-01-05'
  • VENDOR_SECURITY_PATCH := 2022-02-05 generiert
    • com.android.build.vendor.security_patch -> '2022-02-05'

Der Gerätehersteller kann *_SECURITY_PATCH auf $(PLATFORM_SECURITY_PATCH) festlegen, wenn alle Partitionen immer auf die Version mit derselben Sicherheitsupdate-Ebene aktualisiert werden.

  • BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
  • VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)

Benutzerdefinierte Versionsinformationen angeben

Ab Android 13 kann jeder Gerätebuild einen benutzerdefinierten Wert für die Betriebssystemversion haben, der vom Bootloader des Geräts erkannt werden kann. Beispiel:

  • SYSTEM_OS_VERSION := 12.0.0 generiert
    • com.android.build.system.os_version -> '12.0.0'
  • BOOT_OS_VERSION := a.b.c generiert
    • com.android.build.boot.os_version -> 'a.b.c'
  • VENDOR_OS_VERSION := 12.0.1 generiert
    • com.android.build.vendor.os_version -> '12.0.1'

Die veralteten Versionsinformationen im Boot-Image-Header

In Android 9 und höher wird bei der Keymaster 4's Versionsbindung empfohlen, os_version aus dem boot.img Header zu entfernen.

Zum Vergleich wird hier auch die veraltete Verwendung zum Abrufen der Versionsinformationen aus dem Boot-Image-Header beschrieben. Beachten Sie, dass das os_version Feld im Boot-Header sowohl die Betriebssystemversion als auch die Sicherheitsupdate-Ebene in einer 32-Bit-Ganzzahl ohne Vorzeichen kombiniert. Dieser Mechanismus geht davon aus, dass alle Images zusammen aktualisiert werden. Das ist nach der Partitionierung in Project Treble veraltet.

// Operating system version and security patch level.
// For version "A.B.C" and patch level "Y-M-D":
//   (7 bits for each of A, B, C; 7 bits for (Y-2000), 4 bits for M)
//   A = os_version[31:25]
//   B = os_version[24:18]
//   C = os_version[17:11]
//   Y = 2000 + os_version[10:4]
//   M = os-version[3:0]

uint32_t os_version;