Información de la versión en las propiedades AVB

Para admitir la vinculación de versión de KeyMint (anteriormente Keymaster), se espera que el bootloader del dispositivo proporcione la versión del sistema operativo (SO) y el nivel de parche de seguridad para cada partición. La versión del SO y el nivel de parche de seguridad son dos pares clave-valor independientes en las propiedades de AVB. Por ejemplo:

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

El bootloader del dispositivo puede obtener esas propiedades de AVB de una imagen vbmeta con avb_property_lookup(). avb_slot_verify() puede cargar varias imágenes de vbmeta, que se almacenan en el parámetro de salida AvbSlotVerifyData** out_data.

Formato predeterminado de la información de la versión

De forma predeterminada, el sistema de compilación de Android usa el siguiente formato para la versión del SO y el parche de seguridad, respectivamente.

El formato de com.android.build.${partition}.os_version es A[.B.C], por ejemplo, 12 o 12.0.0:

  • A: Versión principal
  • B: Versión secundaria. El valor predeterminado es cero cuando no está presente.
  • C: Versión secundaria, el valor predeterminado es cero cuando está ausente

El formato de com.android.build.${partition}.security_patch es AAAA-MM-DD.

De forma predeterminada, el sistema de compilación genera com.android.build.${partition}.security_patch para las particiones system, system_ext y product. Se espera que el fabricante del dispositivo establezca BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH y otros parches para las particiones que no son del sistema. Por ejemplo:

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

El fabricante del dispositivo puede establecer *_SECURITY_PATCH en $(PLATFORM_SECURITY_PATCH) si siempre actualiza todas las particiones a la versión con el mismo nivel de parche de seguridad.

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

Cómo especificar información de versión personalizada

A partir de Android 13, cada compilación de dispositivo puede tener un valor personalizado para la versión del SO que el bootloader del dispositivo puede reconocer. Por ejemplo:

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

La información de la versión obsoleta en el encabezado de la imagen de arranque

En Android 9 y versiones posteriores, la vinculación de versión de Keymaster 4 sugiere quitar os_version del encabezado boot.img.

Para comparar, aquí también se describe el uso obsoleto de la obtención de la información de la versión del encabezado de la imagen de inicio. Ten en cuenta que el campo os_version en el encabezado de inicio combina la versión del SO y el nivel de parche de seguridad en un número entero sin signo de 32 bits. Además, este mecanismo supone que todas las imágenes se actualizarán juntas, lo que es obsoleto después de la modularización de particiones en 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;