Aby obsługiwać wiązanie wersji Keymastera, bootloader urządzenia powinien udostępniać wersję systemu operacyjnego i poziom poprawek zabezpieczeń dla każdej partycji. wersję systemu operacyjnego i zabezpieczenia; to dwie różne pary klucz-wartość w AVB. usługi. Na przykład:
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'
Program rozruchowy urządzenia może pobrać te właściwości AVB z obrazu vbmeta za pomocą polecenia
avb_property_lookup()
Można wczytać wiele obrazów vbmetaavb_slot_verify()
i przechowywać je w parametrze wyjściowymAvbSlotVerifyData**
out_data
.
Domyślny format informacji o wersji
Domyślnie system kompilacji Androida używa tego formatu odpowiednio dla wersji systemu operacyjnego i łatki zabezpieczeń.
Format pola com.android.build.${partition}.os_version
to A[.B.C],
na przykład 12
lub 12.0.0
:
- A: wersja główna
- B: wersja podrzędna; w przypadku jego braku domyślnie ustawiona jest wartość 0
- C: wersja podrzędna, domyślnie 0, gdy nie ma tej wartości
Format pola com.android.build.${partition}.security_patch
to RRRR-MM-DD.
Domyślnie system kompilacji generuje
com.android.build.${partition}.security_patch
dla: system
,
system_ext
i product
partycji. Producent urządzenia to
ma ustawić BOOT_SECURITY_PATCH
, VENDOR_SECURITY_PATCH
i inne
dla partycji innych niż systemowe. Na przykład:
BOOT_SECURITY_PATCH := 2022-01-05
generujecom.android.build.boot.security_patch -> '2022-01-05'
VENDOR_SECURITY_PATCH := 2022-02-05
generujecom.android.build.vendor.security_patch -> '2022-02-05'
Producent urządzenia może ustawić wartość *_SECURITY_PATCH
na
$(PLATFORM_SECURITY_PATCH)
jeśli zawsze aktualizuje wszystkie partycje do wersji z tym samym poziomem poprawek zabezpieczeń.
BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
Określanie niestandardowych informacji o wersji
Począwszy od Androida 13 każda kompilacja urządzeń może mieć niestandardową wartość dla wersji systemu operacyjnego, którą program rozruchowy urządzenia może rozpoznać. Na przykład:
SYSTEM_OS_VERSION := 12.0.0
generujecom.android.build.system.os_version -> '12.0.0'
BOOT_OS_VERSION := a.b.c
generujecom.android.build.boot.os_version -> 'a.b.c'
VENDOR_OS_VERSION := 12.0.1
generujecom.android.build.vendor.os_version -> '12.0.1'
nieaktualne informacje o wersji w nagłówku obrazu rozruchowego,
Począwszy od Androida 9 wiązanie wersji Keymastera sugeruje usunięcie os_version
z nagłówka boot.img
.
Dla porównania – niepotrzebne uzyskiwanie informacji o wersji z
nagłówek obrazu rozruchowego. Pamiętaj, że pole os_version
w nagłówku rozruchu łączy wersję systemu operacyjnego i poziom aktualizacji zabezpieczeń w 32-bitową liczbę bez znaku. Mechanizm ten zakłada, że wszystkie obrazy
zaktualizowane razem, co jest nieaktualne po modułowości partycji w
Projekt 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;