Informações de versão nas propriedades AVB

Para suportar a ligação de versão do Keymaster, espera-se que o carregador de inicialização do dispositivo forneça a versão do sistema operacional (SO) e o nível do patch de segurança para cada partição. A versão do sistema operacional e o nível do patch de segurança são dois pares chave-valor separados nas propriedades do AVB . por 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 bootloader do dispositivo pode obter essas propriedades AVB de uma imagem vbmeta via avb_property_lookup() . Várias imagens vbmeta podem ser carregadas por avb_slot_verify() e serão armazenadas no parâmetro de saída AvbSlotVerifyData** out_data .

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

Por padrão, o sistema de compilação do Android usará o seguinte formato para a versão do sistema operacional e o patch de segurança, respectivamente.

O formato de com.android.build.${partition}.os_version é A[.BC], por exemplo, '12' ou '12.0.0':

  • R: versão principal
  • B: versão secundária, o padrão é zero quando está ausente
  • C: versão submenor, 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 compilação gerará apenas com.android.build.${partition}.security_patch para system , system_ext e partições product . Espera-se que o fabricante do dispositivo defina BOOT_SECURITY_PATCH , VENDOR_SECURITY_PATCH , etc., para partições que não sejam do sistema. por 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) se sempre atualizar todas as partições para a versão com o mesmo nível de patch de segurança.

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

Especificando informações de versão customizadas

A partir do Android 13, cada build de dispositivo pode ter um valor personalizado para a versão do sistema operacional que pode ser reconhecido pelo carregador de inicialização do dispositivo. por exemplo,

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

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

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

Para efeito de comparação, o uso obsoleto de obter informações de versão do cabeçalho da imagem de inicialização também é descrito aqui. Observe que o campo os_version no cabeçalho de inicialização combina a versão do sistema operacional e o nível do patch de segurança em um número inteiro não assinado de 32 bits. E esse mecanismo pressupõe que todas as imagens serão atualizadas juntas, o que fica obsoleto após a modularização da partição no 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;