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

Para admitir la versión de Keymaster vinculación, Se espera que el bootloader del dispositivo proporcione la versión del sistema operativo (SO). y el nivel de parche de seguridad de cada partición. La versión del SO y la configuración a nivel de parche son dos pares clave-valor separados en el AVB propiedades. 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 de vbmeta con avb_property_lookup(). avb_slot_verify() puede cargar varias imágenes de vbmeta y se almacenan en el parámetro de salida AvbSlotVerifyData**out_data.

Es el 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: La versión menor, que se establece de forma predeterminada en cero cuando no está presente
  • C: La versión secundaria, que se establece en cero de forma predeterminada cuando no está presente

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 system, system_ext y product. El fabricante del dispositivo es se espera que establezcan BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH y otras 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 la misma configuración de seguridad a nivel de parche.

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

Especifica la información de la versión personalizada

A partir de Android 13, cada compilación del 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 versión obsoleta en el encabezado de la imagen de arranque

A partir de Android 9, el vinculado de versiones de Keymaster sugiere quitar os_version del encabezado boot.img.

A modo de comparación, el uso obsoleto de la obtención de información de la versión del el encabezado de imagen de arranque también se describe aquí. Ten en cuenta que 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 de 32 bits sin firma. Este mecanismo supone que todas las imágenes se actualicen juntos, lo cual quedó obsoleto después de la modularización de particiones Proyecto 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;