Untuk mendukung versi Keymaster binding, bootloader perangkat diharapkan menyediakan versi sistem operasi (OS) dan {i>security patch<i} untuk setiap partisi. Versi OS dan keamanan adalah dua pasangan nilai kunci terpisah dalam paket AVB properti. Contoh:
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'
Bootloader perangkat bisa mendapatkan properti AVB
tersebut dari image vbmeta menggunakan
avb_property_lookup()
Beberapa gambar vbmeta dapat dimuat oleh
avb_slot_verify()
dan disimpan di
AvbSlotVerifyData**
out_data
parameter output.
Format default informasi versi
Secara default, sistem build Android menggunakan format berikut untuk OS dan {i>security patch<i}.
Format com.android.build.${partition}.os_version
adalah A[.B.C],
misalnya, 12
atau 12.0.0
:
- A: versi utama
- B: versi minor, ditetapkan secara default ke nol jika tidak ada
- C: versi sub-minor, didefaultkan ke nol jika tidak ada
Format com.android.build.${partition}.security_patch
adalah YYYY-MM-DD.
Secara default, sistem build menghasilkan
com.android.build.${partition}.security_patch
untuk system
,
Partisi system_ext
, dan product
. Produsen perangkat ini
diperkirakan akan menetapkan BOOT_SECURITY_PATCH
, VENDOR_SECURITY_PATCH
, dan lainnya
{i>patch<i}, untuk partisi nonsistem. Contoh:
BOOT_SECURITY_PATCH := 2022-01-05
menghasilkancom.android.build.boot.security_patch -> '2022-01-05'
VENDOR_SECURITY_PATCH := 2022-02-05
menghasilkancom.android.build.vendor.security_patch -> '2022-02-05'
Produsen perangkat dapat menyetel *_SECURITY_PATCH
ke
$(PLATFORM_SECURITY_PATCH)
jika selalu mengupdate semua partisi ke versi dengan keamanan yang sama
level patch.
BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
Menentukan informasi versi kustom
Mulai Android 13, setiap build perangkat dapat memiliki nilai kustom untuk versi OS yang dapat dikenali oleh bootloader perangkat. Contoh:
SYSTEM_OS_VERSION := 12.0.0
menghasilkancom.android.build.system.os_version -> '12.0.0'
BOOT_OS_VERSION := a.b.c
menghasilkancom.android.build.boot.os_version -> 'a.b.c'
VENDOR_OS_VERSION := 12.0.1
menghasilkancom.android.build.vendor.os_version -> '12.0.1'
Informasi versi yang sudah tidak berlaku di header image booting
Mulai dari Android 9, Keymaster
binding versi
Sebaiknya hapus os_version
dari header boot.img
.
Sebagai perbandingan, penggunaan yang sudah tidak berlaku untuk memperoleh informasi versi dari
header image boot juga dijelaskan di sini. Perhatikan bahwa
os_version
isian di {i>header<i} {i>booting<i} menggabungkan versi OS dan
tingkat {i>security patch<i} menjadi
bilangan bulat 32-bit tanpa tanda tangan. Mekanisme ini mengasumsikan bahwa semua gambar akan
diupdate secara bersamaan, yang sudah tidak digunakan lagi setelah modularisasi partisi di
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;