Informations de version dans les propriétés AVB

Pour prendre en charge la liaison de version Keymaster, le chargeur de démarrage de l'appareil doit fournir la version du système d'exploitation (OS) et le niveau de correctif de sécurité pour chaque partition. La version du système d'exploitation et le niveau du correctif de sécurité sont deux paires clé -> valeur distinctes dans les propriétés AVB . par 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 chargeur de démarrage de l'appareil peut obtenir ces propriétés AVB à partir d'une image vbmeta via avb_property_lookup() . Plusieurs images vbmeta peuvent être chargées par avb_slot_verify() et seront stockées dans le paramètre de sortie AvbSlotVerifyData** out_data .

Le format par défaut des informations de version

Par défaut, le système de construction Android utilisera le format suivant pour la version du système d'exploitation et le correctif de sécurité, respectivement.

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

  • A : version majeure
  • B : version mineure, par défaut à zéro lorsqu'il est absent
  • C : version sous-mineure, par défaut à zéro lorsqu'il est absent

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

Par défaut, le système de construction ne générera que com.android.build.${partition}.security_patch pour les partitions system , system_ext et product . Le fabricant de l'appareil doit définir BOOT_SECURITY_PATCH , VENDOR_SECURITY_PATCH , etc., pour les partitions non système. par 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 mettra 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écification des informations de version personnalisées

À partir d'Android 13, chaque version d'appareil peut avoir une valeur personnalisée pour la version du système d'exploitation qui peut être reconnue par le chargeur de démarrage de l'appareil. par exemple,

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

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

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

À titre de comparaison, l'utilisation obsolète consistant à obtenir les 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 dans l'en-tête de démarrage combine à la fois la version du système d'exploitation et le niveau du correctif de sécurité dans un entier non signé 32 bits. Et 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;