Versionsinformationen in AVB-Eigenschaften

Zur Unterstützung der Keymaster-Version Binding, Der Geräte-Bootloader muss die Betriebssystemversion (OS) bereitstellen und den Stand der Sicherheitsupdates für jede Partition. Die Betriebssystemversion und die Sicherheit Patchebene zwei separate Schlüssel/Wert-Paare im 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 Geräte-Bootloader kann diese AVB-Eigenschaften über ein VBmeta-Image abrufen. avb_property_lookup() Mehrere VBmeta-Bilder können über avb_slot_verify() und werden im AvbSlotVerifyData** out_data .

Das Standardformat der Versionsinformationen

Standardmäßig verwendet das Android-Build-System das folgende Format für das Betriebssystem Version bzw. den Sicherheitspatch.

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 diese nicht vorhanden ist
  • C: Sub-Minor-Version, wird standardmäßig auf null gesetzt, wenn sie nicht vorhanden ist

com.android.build.${partition}.security_patch hat das Format JJJJ-MM-TT.

Standardmäßig generiert das Build-System com.android.build.${partition}.security_patch für system, system_ext und product. Der Gerätehersteller ist wird voraussichtlich BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH und andere festlegen Patches für Nichtsystempartitionen. Beispiel:

  • BOOT_SECURITY_PATCH := 2022-01-05 generiert <ph type="x-smartling-placeholder">
      </ph>
    • com.android.build.boot.security_patch -> '2022-01-05'
  • VENDOR_SECURITY_PATCH := 2022-02-05 generiert <ph type="x-smartling-placeholder">
      </ph>
    • com.android.build.vendor.security_patch -> '2022-02-05'

Der Gerätehersteller kann *_SECURITY_PATCH festlegen auf $(PLATFORM_SECURITY_PATCH) wenn alle Partitionen immer auf die Version mit der gleichen Sicherheit aktualisiert werden Patch-Level.

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

Benutzerdefinierte Versionsinformationen angeben

Ab Android 13 kann jeder Geräte-Build eine Benutzerdefinierter Wert für die Version des Betriebssystems, die vom Geräte-Bootloader erkannt wird. Beispiel:

  • SYSTEM_OS_VERSION := 12.0.0 generiert <ph type="x-smartling-placeholder">
      </ph>
    • com.android.build.system.os_version -> '12.0.0'
  • BOOT_OS_VERSION := a.b.c generiert <ph type="x-smartling-placeholder">
      </ph>
    • com.android.build.boot.os_version -> 'a.b.c'
  • VENDOR_OS_VERSION := 12.0.1 generiert <ph type="x-smartling-placeholder">
      </ph>
    • com.android.build.vendor.os_version -> '12.0.1'

Informationen zur veralteten Version im Boot-Image-Header

Ab Android 9, Keymaster Versionsbindung schlägt vor, „os_version“ aus dem Header „boot.img“ zu entfernen.

Zum Vergleich: Die veraltete Nutzung des Abrufs der Versionsinformationen aus dem Boot-Image-Header wird auch hier beschrieben. Das Feld os_version im Boot-Header kombiniert die Betriebssystemversion und den Stand der Sicherheitsupdates in eine vorzeichenlose 32-Bit-Ganzzahl. Dieser Mechanismus geht davon aus, dass alle Bilder was nach der Partition-Modularisierung in Projekt Treble

// 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;