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

Pour prendre en charge la liaison de version KeyMint (anciennement Keymaster), le bootloader de l'appareil doit fournir la version de l'OS et le niveau du correctif de sécurité pour chaque partition. La version de l'OS et le niveau du correctif de sécurité sont deux paires clé-valeur distinctes dans les propriétés AVB. 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 à l'aide de avb_property_lookup(). Plusieurs images vbmeta peuvent être chargées par avb_slot_verify() et sont stockées dans le paramètre de sortie AvbSlotVerifyData** out_data.

Format par défaut des informations sur la version

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

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, définie sur zéro par défaut en l'absence de valeur
  • C : version mineure, définie par défaut sur zéro si elle est absente

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 les partitions system, system_ext et product. Le fabricant de l'appareil est censé définir BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH et d'autres correctifs pour les partitions non système. Exemple :

  • BOOT_SECURITY_PATCH := 2022-01-05 génère
    • com.android.build.boot.security_patch -> '2022-01-05'
  • VENDOR_SECURITY_PATCH := 2022-02-05 génère
    • 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 correctif de sécurité.

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

Spécifier des informations de version personnalisées

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

  • SYSTEM_OS_VERSION := 12.0.0 génère
    • com.android.build.system.os_version -> '12.0.0'
  • BOOT_OS_VERSION := a.b.c génère
    • com.android.build.boot.os_version -> 'a.b.c'
  • VENDOR_OS_VERSION := 12.0.1 génère
    • com.android.build.vendor.os_version -> '12.0.1'

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

Dans Android 9 et versions ultérieures, la liaison de version de Keymaster 4 suggère de supprimer os_version de l'en-tête boot.img.

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