Informações de versão nas propriedades do AVB

Para oferecer suporte à versão do Keymaster vinculação, o carregador de inicialização do dispositivo deve fornecer a versão do sistema operacional (SO) e o nível do patch de segurança de cada partição. A versão do SO e os requisitos de nível de patch são dois pares de chave-valor separados na AVB do Terraform. Exemplo:

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

O carregador de inicialização do dispositivo pode obter essas propriedades AVB de uma imagem vbmeta usando avb_property_lookup(). Várias imagens vbmeta podem ser carregadas por avb_slot_verify() e são armazenados AvbSlotVerifyData** out_data parâmetro de saída.

O formato padrão das informações de versão

Por padrão, o sistema de build do Android usa o seguinte formato para o SO e o patch de segurança, respectivamente.

O formato de com.android.build.${partition}.os_version é A[.B.C], Por exemplo, 12 ou 12.0.0:

  • A: a versão principal
  • B: versão secundária, o padrão é zero quando está ausente
  • C: versão subsecundária, o padrão é zero quando está ausente

O formato de com.android.build.${partition}.security_patch é AAAA-MM-DD.

Por padrão, o sistema de build gera com.android.build.${partition}.security_patch para system, system_ext e product. O fabricante do dispositivo é deve definir BOOT_SECURITY_PATCH, VENDOR_SECURITY_PATCH e outros patches para partições que não sejam do sistema. Exemplo:

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

O fabricante do dispositivo pode definir *_SECURITY_PATCH como $(PLATFORM_SECURITY_PATCH) caso ele sempre atualize todas as partições para uma versão com a mesma segurança em nível de patch.

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

Especificar informações da versão personalizada

A partir do Android 13, cada build do dispositivo pode ter uma o valor personalizado para a versão do SO que pode ser reconhecido pelo carregador de inicialização do dispositivo. Exemplo:

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

As informações de versão obsoletas no cabeçalho da imagem de inicialização

Do Android 9 em diante, o Keymaster vinculação de versão sugere a remoção de os_version do cabeçalho boot.img.

Para comparação, o uso obsoleto de obtenção das informações de versão do do cabeçalho da imagem de inicialização também é descrito aqui. Observe que o os_version no cabeçalho de inicialização combina a versão do SO e o nível do patch de segurança em um um número inteiro não assinado de 32 bits. E esse mecanismo pressupõe que todas as imagens serão atualizados juntos, que se tornam obsoletos após a modularização de partições em Projeto 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;