Informations sur la version dans les propriétés AVB

Pour prendre en charge la version Keymaster binding, le bootloader de l'appareil doit fournir la version du système d'exploitation (OS) et le niveau du correctif de sécurité pour chaque partition. La version de l'OS et la sécurité correctif sont deux paires clé/valeur distinctes dans AVB propriétés. Exemple :

  • 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'

Le bootloader de l'appareil peut obtenir ces propriétés AVB à partir d'une image vbmeta en utilisant avb_property_lookup() Plusieurs images vbmeta peuvent être chargées avb_slot_verify() et sont stockées dans AvbSlotVerifyData** out_data paramètre de sortie.

Format par défaut des informations de version

Par défaut, le système de compilation Android utilise le format suivant pour l'OS et le correctif de sécurité.

Le format de com.android.build.${partition}.os_version est A[.B.C], par exemple, 12 ou 12.0.0:

  • A: version majeure
  • B: version mineure, la valeur par défaut est zéro en cas d'absence
  • C: version de correction, valeur par défaut zéro en l'absence de version

Le format de com.android.build.${partition}.security_patch est AAAA-MM-JJ.

Par défaut, le système de compilation génère com.android.build.${partition}.security_patch pour system, system_ext et product. Le fabricant de l'appareil est vous devez définir BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH et d'autres pour les partitions non système. Exemple :

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

Le fabricant de l'appareil peut définir *_SECURITY_PATCH sur $(PLATFORM_SECURITY_PATCH) s'il met toujours à jour toutes les partitions vers la version avec le même niveau de sécurité au niveau du correctif.

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

Spécifier les informations de version personnalisée

À partir d'Android 13, chaque build d'appareil peut avoir un Valeur personnalisée pour la version de l'OS pouvant être reconnue par le bootloader de l'appareil. Exemple :

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

Informations de version obsolètes dans l'en-tête de l'image de démarrage

À partir d'Android 9, Keymaster liaison de version suggère de supprimer os_version de l'en-tête boot.img.

À titre de comparaison, l'utilisation obsolète de l'obtention des informations de version à partir du de l'image de démarrage est également décrite ici. Notez que os_version dans l'en-tête de démarrage combine la version du système d'exploitation et le niveau du correctif de sécurité dans un entier non signé de 32 bits. Ce mécanisme suppose que toutes les images mis à jour ensemble, ce qui est obsolète après la modularisation de la partition dans Projet 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;