W systemie Android 12 ogólny obraz boot
, nazywany Generic Kernel Image (GKI) , zawiera ogólny ramdysk i jądro GKI.
W przypadku urządzeń uruchamianych z systemem Android 13 ogólny ramdysk jest usuwany z obrazu boot
i umieszczany w osobnym obrazie init_boot
. Ta zmiana pozostawia obraz boot
zawierający tylko jądro GKI.
W przypadku aktualizacji urządzeń, które nadal korzystają z Androida 12 lub starszych wersji jądra, ogólny ramdysk pozostaje na swoim miejscu, bez konieczności tworzenia nowego obrazu init_boot
.
Aby zbudować ogólny ramdysk, przenieś zasoby specyficzne dla dostawcy z ramdysku w taki sposób, aby ogólny ramdysk zawierał tylko init
pierwszego etapu i plik właściwości zawierający informacje o sygnaturze czasowej.
Na urządzeniach, które:
Nie używaj dedykowanej partycji
recovery
, wszystkie bity odzyskiwania zostaną przeniesione z ogólnego RAMdysku do RAMdyskuvendor_boot
.Należy używać dedykowanej partycji
recovery
. Nie są potrzebne żadne zmiany w ramdyskurecovery
, ponieważ ramdyskrecovery
jest samodzielny.
Architektura
Poniższe diagramy ilustrują architekturę urządzeń z systemem Android 12 i nowszym. Urządzenie uruchamiane z systemem Android 13 ma nowy obraz init_boot
zawierający ogólny ramdysk. Urządzenia uaktualniające się z Androida 12 do Androida 13 korzystają z tej samej architektury, co w przypadku Androida 12.
Uruchom z Androidem 13, bez dedykowanego odzyskiwania
Rysunek 1. Urządzenia uruchamiające się lub aktualizujące do Androida 13 z GKI, bez dedykowanego odzyskiwania
Uruchom z Androidem 13, dedykowanym i odzyskiwaniem A/B (dedykowany ramdysk)
Rysunek 2. Urządzenia uruchamiające się lub aktualizujące do Androida 13 z GKI, dedykowanym i odzyskiwaniem A/B
Skorzystaj z tego rysunku, jeśli urządzenie ma partycje recovery_a
i recovery_b
.
Uruchom z Androidem 13, dedykowanym odzyskiwaniem i innym niż A/B (dedykowany ramdysk)
Rysunek 3. Urządzenia uruchamiające się lub aktualizujące do Androida 13 z GKI, dedykowanym odzyskiwaniem innym niż A/B
Skorzystaj z tego rysunku, jeśli urządzenie ma partycję o nazwie recovery
bez przyrostka gniazda.
Uruchom lub zaktualizuj system do Androida 12, bez dedykowanego odzyskiwania
Rysunek 4. Urządzenia uruchamiające się lub aktualizujące do Androida 12, z GKI, bez dedykowanego odzyskiwania
Uruchom lub zaktualizuj do Androida 12, dedykowane i odzyskiwanie A/B (dedykowany ramdysk)
Rysunek 5. Urządzenia uruchamiające się lub aktualizujące do Androida 12 z GKI, dedykowanym i odzyskiwaniem A/B
Skorzystaj z tego rysunku, jeśli urządzenie ma partycje recovery_a
i recovery_b
.
Uruchomienie lub uaktualnienie do systemu Android 12, dedykowane odzyskiwanie i przywracanie inne niż A/B (dedykowany dysk RAM)
Rysunek 6. Urządzenia uruchamiające się lub aktualizujące do systemu Android 12 z GKI, dedykowanym odzyskiwaniem innym niż A/B
Skorzystaj z tego rysunku, jeśli urządzenie ma partycję o nazwie recovery
bez przyrostka gniazda.
Uaktualnij do Androida 12, odzyskiwanie podczas rozruchu (odzyskiwanie jako ramdysk)
Rysunek 7. Aktualizacja urządzeń do Androida 12, bez GKI, odzyskiwanie podczas rozruchu
Aktualizacja do Androida 12, dedykowane odzyskiwanie (dedykowany ramdysk)
Rysunek 8. Aktualizacja urządzeń do Androida 12, bez GKI, dedykowane odzyskiwanie
Zawartość obrazów rozruchowych
Obrazy rozruchowe systemu Android zawierają następujące elementy.
Dodano obraz
init_boot
dla urządzeń uruchamianych z systemem Android 13- Wersja nagłówka V4
- Ogólny obraz ramdysku
Ogólny obraz
boot
- Wersja nagłówka V3 lub V4
-
boot_signature
dla certyfikatu GKI boot.img (tylko wersja 4). Certyfikowany plik GKIboot.img
nie jest podpisany w celu zweryfikowania rozruchu. Producenci OEM nadal muszą podpisać wstępnie skompilowanyboot.img
kluczem AVB specyficznym dla urządzenia. - Ogólna
cmdline
(GENERIC_KERNEL_CMDLINE
) - Jądro GKI
-
- Ogólny obraz ramdysku
- Uwzględniane tylko w obrazach
boot
z Androida 12 i wcześniejszych wersji
- Uwzględniane tylko w obrazach
- Wersja nagłówka V3 lub V4
obraz
vendor_boot
(szczegółowe informacje można znaleźć w sekcji Partycje rozruchowe dostawcy )- nagłówek
vendor_boot
-
cmdline
specyficzne dla urządzenia (BOARD_KERNEL_CMDLINE
)
-
- obraz ramdysku
vendor_boot
-
lib/modules
- Zasoby odzyskiwania (jeśli nie ma dedykowanego odzyskiwania)
-
- obraz
dtb
- nagłówek
obraz
recovery
- Wersja nagłówka V2
- W razie potrzeby
cmdline
specyficznych dla urządzenia do odzyskiwania - W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielna; zobacz Obrazy odzyskiwania . Na przykład:
-
cmdline
nie jest połączone z poleceniemboot
ivendor_boot
cmdline
. - Nagłówek określa DTBO odzyskiwania, jeśli to konieczne.
- W przypadku partycji odzyskiwania A/B zawartość może być łączona lub wywnioskowana z
boot
ivendor_boot
. Na przykład: -
cmdline
jest połączone z poleceniamiboot
ivendor_boot
cmdline
. - Wartość DTBO można wywnioskować z nagłówka
vendor_boot
.
- W razie potrzeby
- obraz ramdysku
recovery
- Zasoby odzyskiwania
- W przypadku partycji odzyskiwania innej niż A/B zawartość ramdysku musi być samodzielna; zobacz Obrazy odzyskiwania . Na przykład:
-
lib/modules
musi zawierać wszystkie moduły jądra wymagane do uruchomienia trybu odzyskiwania - Ramdysk odzyskiwania musi zawierać plik
init
. - W przypadku partycji odzyskiwania A/B ramdysk odzyskiwania jest dołączany do dysku ramdisku ogólnego i dysku
vendor_boot
, dlatego nie musi być samodzielny. Na przykład: -
lib/modules
może zawierać tylko dodatkowe moduły jądra wymagane do trybu przywracania rozruchu, oprócz modułów jądra w ramdyskuvendor_boot
. - Dowiązanie symboliczne w
/init
może istnieć, ale jest przyćmione przez plik binarny pierwszego stopnia/init
w obrazie startowym.
- Wersja nagłówka V2
Ogólna zawartość obrazu ramdysku
Ogólny ramdysk zawiera następujące komponenty.
-
init
- Dodano
system/etc/ramdisk/build.prop
-
ro. PRODUCT .bootimg.* build
- Puste katalogi dla punktów podłączenia:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
-
first_stage_ramdisk/
- Zduplikowane puste katalogi dla punktów podłączenia:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
- Zduplikowane puste katalogi dla punktów podłączenia:
Integracja obrazu rozruchowego
Flagi kompilacji kontrolują sposób tworzenia obrazów init_boot
, boot
, recovery
i vendor_boot
. Wartość zmiennej tablicy logicznej musi być ciągiem znaków true
lub być pusta (co jest ustawieniem domyślnym).
TARGET_NO_KERNEL
. Ta zmienna wskazuje, czy kompilacja używa wstępnie skompilowanego obrazu rozruchowego. Jeśli ta zmienna jest ustawiona natrue
, ustawBOARD_PREBUILT_BOOTIMAGE
na lokalizację wstępnie zbudowanego obrazu rozruchowego (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img
)BOARD_USES_RECOVERY_AS_BOOT
. Ta zmienna wskazuje, czy urządzenie używa obrazurecovery
jako obrazuboot
. Podczas korzystania z GKI ta zmienna jest pusta i zasoby odzyskiwania powinny zostać przeniesione dovendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Ta zmienna wskazuje, że płyta używa GKI. Ta zmienna nie ma wpływu na sysprops aniPRODUCT_PACKAGES
.To jest przełącznik GKI na poziomie płytki; wszystkie zmienne wymienione poniżej są ograniczone przez tę zmienną.
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
. Ta zmienna kontroluje, czy zasoby odzyskiwania ramdysku są budowane wvendor_boot
.Po ustawieniu na
true
zasoby odzyskiwania są budowane tylko wvendor-ramdisk/
i nie są budowane w trybierecovery/root/
.Gdy są puste, zasoby odzyskiwania są budowane tylko w trybie
recovery/root/
i nie są budowane wvendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
. Ta zmienna kontroluje, czy klucze GSI AVB są zbudowane wvendor_boot
.Gdy ustawione na
true
, jeśliBOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
:Jest ustawione, klucze GSI AVB są budowane na
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb
.Nie jest ustawione, klucze GSI AVB są zbudowane na
$ANDROID_PRODUCT_OUT/vendor-ramdisk/avb
.
Gdy pusty, jeśli
BOARD_RECOVERY_AS_ROOT
:Jest ustawione, klucze GSI AVB są budowane na
$ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb
.Nie jest ustawione, klucze GSI AVB są zbudowane na
$ANDROID_PRODUCT_OUT/ramdisk/avb
.
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE
. Ta zmienna kontroluje, czy obrazrecovery
zawiera jądro, czy nie. Urządzenia uruchamiane z systemem Android 12 i korzystające z partycjirecovery
A/B muszą ustawić tę zmienną natrue
. Urządzenia uruchamiane z systemem Android 12 i korzystające z systemu innego niż A/B muszą ustawić tę zmienną nafalse
, aby obraz odzyskiwania był niezależny.BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES
. Ta zmienna kontroluje, czy$OUT/boot*.img
jest kopiowany doIMAGES/
w plikach docelowych.aosp_arm64
musi ustawić tę zmienną natrue
.Inne urządzenia muszą pozostawić tę zmienną pustą.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE
. Ta zmienna kontroluje, czy generowany jestinit_boot.img
i ustawia jego rozmiar. Po ustawieniu ogólny ramdysk jest dodawany doinit_boot.img
zamiastboot.img
i wymaga ustawienia zmiennychBOARD_AVB_INIT_BOOT*
dla połączonego vbmeta
Dozwolone kombinacje
Składnik lub zmienna | Aktualizacja urządzenia bez partycji recovery | Aktualizacja urządzenia za pomocą partycji recovery | Uruchom urządzenie bez partycji recovery | Uruchom urządzenie z partycją recovery A/B | Uruchom urządzenie z partycją recovery inną niż A/B | aosp_arm64 |
---|---|---|---|---|---|---|
Zawiera boot | Tak | Tak | Tak | Tak | Tak | Tak |
Zawiera init_boot (Android 13) | NIE | NIE | Tak | Tak | Tak | Tak |
Zawiera vendor_boot | opcjonalny | opcjonalny | Tak | Tak | Tak | NIE |
Zawiera recovery | NIE | Tak | NIE | Tak | Tak | NIE |
BOARD_USES_RECOVERY_AS_BOOT | true | pusty | pusty | pusty | pusty | pusty |
BOARD_USES_GENERIC_KERNEL_IMAGE | pusty | pusty | true | true | true | true |
PRODUCT_BUILD_RECOVERY_IMAGE | pusty | true lub puste | pusty | true lub puste | true lub puste | pusty |
BOARD_RECOVERYIMAGE_PARTITION_SIZE | pusty | > 0 | pusty | > 0 | > 0 | pusty |
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT | pusty | pusty | true | pusty | pusty | pusty |
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT | pusty | pusty | true | true | true | pusty |
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE | pusty | pusty | pusty | true | pusty | pusty |
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES | pusty | pusty | pusty | pusty | pusty | true |
Urządzenia z dedykowaną partycją recovery
mogą ustawić PRODUCT_BUILD_RECOVERY_IMAGE
na true
lub pustą. W przypadku tych urządzeń, jeśli ustawiono BOARD_RECOVERYIMAGE_PARTITION_SIZE
, tworzony jest obraz recovery
.
Włącz łańcuchową vbmeta dla rozruchu
Dla obrazów boot
i init_boot
musi być włączona łańcuchowa vbmeta. Określ następujące informacje:
BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2
BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3
Na przykład odwołaj się do tej zmiany .
System jako root
System jako root nie jest obsługiwany w przypadku urządzeń korzystających z GKI. Na takich urządzeniach BOARD_BUILD_SYSTEM_ROOT_IMAGE
musi być pusty. Opcja System-as-root również nie jest obsługiwana w przypadku urządzeń korzystających z partycji dynamicznych.
Konfiguracje produktu
Urządzenia korzystające z ogólnego ramdysku muszą zainstalować listę plików, które mogą być instalowane na ramdysku. Aby to zrobić, określ następujące elementy w device.mk
:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
generic_ramdisk.mk
zapobiega także przypadkowemu zainstalowaniu innych plików na ramdysku przez inne pliki makefile (zamiast tego przenieś takie pliki do vendor_ramdisk
).
Konfigurowanie urządzeń
Instrukcje konfiguracji różnią się w przypadku urządzeń uruchamianych z Androidem 13, aktualizujących do Androida 12 i uruchamiających się z Androidem 12. Android 13 jest skonfigurowany podobnie jak w przypadku Androida 12
Urządzenia aktualizujące do Androida 12:
Może zachować wartość
BOARD_USES_RECOVERY_AS_BOOT
. Jeśli to zrobią, używają starszych konfiguracji, a nowe zmienne kompilacji muszą być puste. Jeżeli takie urządzenia:Ustaw
BOARD_USES_RECOVERY_AS_BOOT
natrue
, architektura jest pokazana na rysunku 3 .Ustaw
BOARD_USES_RECOVERY_AS_BOOT
na pusty, architektura jest taka, jak pokazano na rysunku 4 .
Można ustawić
BOARD_USES_RECOVERY_AS_BOOT
na pusty. Jeśli to zrobią, użyją nowych konfiguracji. Jeżeli takie urządzenia:Nie używaj dedykowanej partycji
recovery
, architektura jest pokazana na rysunku 1 , a opcja konfiguracji urządzenia to Opcja 1 .Użyj dedykowanej partycji
recovery
, architektura jest pokazana na rysunku 2a lub rysunku 2b , a opcja konfiguracji urządzenia to Opcja 2a lub Opcja 2b .
Urządzenia uruchamiane z systemem Android 12 muszą ustawić
BOARD_USES_RECOVERY_AS_BOOT
na puste i korzystać z nowych konfiguracji. Jeżeli takie urządzenia:Nie używaj dedykowanej partycji
recovery
, architektura jest pokazana na rysunku 1 , a opcja konfiguracji urządzenia to Opcja 1 .Użyj dedykowanej partycji
recovery
, architektura jest pokazana na rysunku 2a lub rysunku 2b , a opcja konfiguracji urządzenia to Opcja 2a lub Opcja 2b .
Ponieważ aosp_arm64
buduje tylko GKI (a nie vendor_boot
czy recovery), nie jest to kompletny cel. Informacje na temat konfiguracji kompilacji aosp_arm64
można znaleźć w generic_arm64
.
Opcja 1: Brak dedykowanej partycji odzyskiwania
Urządzenia bez partycji recovery
zawierają ogólny obraz boot
na partycji boot
. Dysk vendor_boot
dostawcy zawiera wszystkie zasoby odzyskiwania, w tym lib/modules
(z modułami jądra dostawcy). Na takich urządzeniach konfiguracja produktu dziedziczy z generic_ramdisk.mk
.
Ustawianie wartości BOARD
Ustaw następujące wartości:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Inicjacyjne pliki binarne i dowiązania symboliczne
Ramdysk vendor_boot
może zawierać dowiązanie symboliczne /init
do /system/bin/init
i init_second_stage.recovery
w /system/bin/init
. Jednakże, ponieważ ogólny ramdysk jest łączony po ramdysku vendor_boot
, dowiązanie symboliczne /init
zostaje nadpisane. Kiedy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init
jest potrzebny do obsługi drugiego etapu init. Zawartość vendor_boot
+ ogólnych ramdysków jest następująca:
-
/init
(z ogólnego ramdysku, zbudowanego zinit_first_stage
) -
/system/bin/init
(zvendor_ramdisk
, zbudowany zinit_second_stage.recovery
)
Przenoszenie plików fstab
Przenieś wszystkie pliki fstab
, które zostały zainstalowane na ogólnym ramdysku do vendor_ramdisk
. Na przykład odwołaj się do tej zmiany .
Instalowanie modułów
W razie potrzeby możesz zainstalować moduły specyficzne dla urządzenia vendor_ramdisk
(pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania).
Użyj wariantu modułu
vendor_ramdisk
, gdy moduł instaluje się na dysku/first_stage_ramdisk
. Moduł ten powinien być dostępny po tym, jakinit
przełączy root na/first_stage_ramdisk
, ale zaniminit
przełączy root na/system
. Przykłady można znaleźć w artykule Sumy kontrolne metadanych i wirtualna kompresja A/B .Użyj wariantu
recovery
modułu, gdy moduł instaluje się w/
. Moduł ten powinien być dostępny zaniminit
przełączy root na/first_stage_ramdisk
. Aby uzyskać szczegółowe informacje na temat instalowania modułów w/
, zobacz Konsola pierwszego stopnia .
Konsola pierwszego stopnia
Ponieważ konsola pierwszego etapu uruchamia się, zanim init
przełączy root na /first_stage_ramdisk
, musisz zainstalować wariant recovery
modułów. Domyślnie oba warianty modułów są instalowane w build/make/target/product/base_vendor.mk
, więc jeśli plik makefile urządzenia dziedziczy z tego pliku, nie trzeba jawnie instalować wariantu recovery
.
Aby jawnie zainstalować moduły odzyskiwania, użyj poniższych opcji.
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
Zapewnia to, że linker
, sh
i toybox
zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, który następnie zostanie zainstalowany w /system/bin
na dysku vendor_ramdisk
.
Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), użyj poniższego polecenia.
PRODUCT_PACKAGES += adbd.recovery
Dzięki temu określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, który następnie zostanie zainstalowany w /system/bin
na vendor_ramdisk
.
Sumy kontrolne metadanych
Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia nie obsługujące GKI instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Na przykład zapoznaj się z tą listą zmian .
Wirtualna kompresja A/B
Aby obsługiwać wirtualną kompresję A/B, snapuserd
musi być zainstalowany na vendor_ramdisk
. Urządzenie powinno dziedziczyć z virtual_ab_ota/compression.mk
, który instaluje wariant snapuserd
vendor_ramdisk
.
Zmiany w procesie uruchamiania
Proces uruchamiania w trybie odzyskiwania lub w systemie Android nie ulega zmianie, z następującym wyjątkiem:
- Ramdysk
build.prop
przenosi się do/second_stage_resources
, dzięki czemuinit
drugiego etapu może odczytać znacznik czasu kompilacji rozruchu.
Ponieważ zasoby są przenoszone z ogólnego RAMdysku do RAMdysku vendor_boot
, wynik połączenia ogólnego RAMdysku z ramdyskiem vendor_boot
dostawcy nie ulega zmianie.
Udostępnienie e2fsck
Pliki makefile urządzenia mogą dziedziczyć z:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
, jeśli urządzenie obsługuje wirtualne A/B, ale nie obsługuje kompresji.virtual_ab_ota/compression.mk
, jeśli urządzenie obsługuje wirtualną kompresję A/B.
Pliki Makefile produktu instalują $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck
. W czasie wykonywania pierwszy etap init
przełącza katalog główny na /first_stage_ramdisk
a następnie wykonuje /system/bin/e2fsck
.
Opcja 2a: Partycja dedykowana i partycja odzyskiwania A/B
Użyj tej opcji w przypadku urządzeń z partycjami recovery
A/B; oznacza to, że urządzenie ma partycję recovery_a
i recovery_b partition
. Do takich urządzeń zaliczają się urządzenia A/B i wirtualne A/B, których partycję odzyskiwania można aktualizować, w następującej konfiguracji:
AB_OTA_PARTITIONS += recovery
Ramdysk_rozruchowy vendor_boot
zawiera bity dostawcy ramdysku i modułów jądra dostawcy, w tym:
Pliki
fstab
specyficzne dla urządzenialib/modules
(zawiera moduły jądra dostawcy)
Ramdysk recovery
zawiera wszystkie zasoby odzyskiwania. Na takich urządzeniach konfiguracja produktu dziedziczy z generic_ramdisk.mk
.
Ustawianie wartości BOARD
Ustaw następujące wartości dla urządzeń z partycją recovery
A/B:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Inicjacyjne pliki binarne i dowiązania symboliczne
Ramdysk recovery
może zawierać dowiązanie symboliczne /init -> /system/bin/init
i init_second_stage.recovery
w /system/bin/init
. Ponieważ jednak ramdysk rozruchowy jest łączony po ramdysku recovery
, dowiązanie symboliczne /init
zostaje nadpisane. Gdy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init
jest potrzebny do obsługi drugiego etapu init.
Gdy urządzenie uruchamia się w trybie recovery
, zawartość recovery
+ vendor_boot
+ ogólne dyski ramkowe jest następująca:
-
/init
(z ramdysku, zbudowany zinit_first_stage
) -
/system/bin/init
(z ramdyskurecovery
, zbudowany zinit_second_stage.recovery
i wykonany z/init
)
Gdy urządzenie uruchamia się w systemie Android, zawartość ramdysku vendor_boot
+ ogólne jest następująca:
-
/init
(z ogólnego ramdysku, zbudowanego zinit_first_stage
)
Przenoszenie plików fstab
Przenieś wszystkie pliki fstab
, które zostały zainstalowane na ogólnym ramdysku do vendor_ramdisk
. Na przykład odwołaj się do tej zmiany .
Instalowanie modułów
W razie potrzeby możesz zainstalować moduły specyficzne dla urządzenia vendor_ramdisk
(pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). Init
nie przełącza roota. Wariant modułów vendor_ramdisk
instaluje się w katalogu głównym vendor_ramdisk
. Przykłady instalowania modułów na vendor_ramdisk
można znaleźć w artykułach Konsola pierwszego stopnia , Sumy kontrolne metadanych i Wirtualna kompresja A/B .
Konsola pierwszego stopnia
Aby zainstalować wariant modułów vendor_ramdisk
, użyj następujących poleceń:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Zapewnia to, że linker
, sh
i toybox
zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, który następnie zostanie zainstalowany w /system/bin
w obszarze vendor_ramdisk
.
Aby dodać moduły potrzebne do konsoli pierwszego stopnia (na przykład adbd), włącz wariant vendor_ramdisk
tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie użyj poniższych poleceń:
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Dzięki temu określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
. Jeśli ramdysk vendor_boot
jest załadowany w trybie odzyskiwania, moduł jest również dostępny w recovery
. Jeśli ramdysk vendor_boot
nie jest załadowany w trybie odzyskiwania, na urządzeniu można opcjonalnie zainstalować również adbd.recovery
.
Sumy kontrolne metadanych
Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia nie obsługujące GKI instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Na przykład zapoznaj się z tą listą zmian .
Wirtualna kompresja A/B
Aby obsługiwać wirtualną kompresję A/B, snapuserd
musi być zainstalowany na vendor_ramdisk
. Urządzenie powinno dziedziczyć z virtual_ab_ota/compression.mk
, który instaluje wariant snapuserd
vendor_ramdisk
.
Zmiany w procesie uruchamiania
Podczas uruchamiania systemu Android proces uruchamiania nie ulega zmianie. vendor_boot
+ ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z tą różnicą, że fstab
ładuje się z vendor_boot
. Ponieważ system/bin/recovery
nie istnieje, first_stage_init
obsługuje to jako normalny rozruch.
Podczas uruchamiania w trybie odzyskiwania proces uruchamiania ulega zmianie. Odzyskiwanie + vendor_boot
+ ogólny ramdysk jest podobny do istniejącego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot
, a nie z obrazu recovery
. Proces uruchamiania w trybie odzyskiwania jest następujący.
Program ładujący zostanie uruchomiony, a następnie wykona następujące czynności:
- Wypycha odzyskiwanie +
vendor_boot
+ ogólny ramdysk do/
. (Jeśli producent OEM powiela moduły jądra w ramdysku odzyskiwania, dodając je doBOARD_RECOVERY_KERNEL_MODULES
),vendor_boot
jest opcjonalny.) - Uruchamia jądro z partycji
boot
.
- Wypycha odzyskiwanie +
Jądro montuje ramdysk do
/
a następnie wykonuje polecenie/init
z ogólnego ramdysku.Rozpoczyna się pierwszy etap inicjowania, po którym wykonywane są następujące czynności:
- Ustawia
IsRecoveryMode() == true
iForceNormalBoot() == false
. - Ładuje moduły jądra dostawcy z
/lib/modules
. - Wywołuje funkcję
DoFirstStageMount()
, ale pomija montowanie, ponieważIsRecoveryMode() == true
. (Urządzenie nie zwalnia ramdysku (ponieważ/
jest nadal takie samo), ale wywołujeSetInitAvbVersionInRecovery()
.) - Uruchamia drugi etap init z
/system/bin/init
z dysku ramdyskurecovery
.
- Ustawia
Udostępnienie e2fsck
Pliki makefile urządzenia mogą dziedziczyć z:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
, jeśli urządzenie obsługuje wirtualne A/B, ale nie obsługuje kompresji.virtual_ab_ota/compression.mk
, jeśli urządzenie obsługuje wirtualną kompresję A/B.
Pliki Makefile produktu instalują $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck
. W czasie wykonywania pierwszy etap init
wykonuje /system/bin/e2fsck
.
Opcja 2b: Dedykowana partycja odzyskiwania inna niż A/B
Użyj tej opcji w przypadku urządzeń z partycją recovery
inną niż A/B; oznacza to, że urządzenie ma partycję o nazwie recovery
bez przyrostka gniazda. Do takich urządzeń należą:
- urządzenia inne niż A/B;
- Urządzenia A/B i wirtualne A/B, których partycji odzyskiwania nie można aktualizować. (To niezwykłe.)
Ramdysk_rozruchowy vendor_boot
zawiera bity dostawcy ramdysku i modułów jądra dostawcy, w tym:
- Pliki
fstab
specyficzne dla urządzenia -
lib/modules
(zawiera moduły jądra dostawcy)
Obraz recovery
musi być samodzielny. Musi zawierać wszystkie zasoby wymagane do uruchomienia trybu odzyskiwania, w tym:
- Obraz jądra
- Obraz DTBO
- Moduły jądra w
lib/modules
- Init pierwszego etapu jako dowiązanie symboliczne
/init -> /system/bin/init
- Binarny plik inicjujący drugiego stopnia
/system/bin/init
- Pliki
fstab
specyficzne dla urządzenia - Wszystkie inne zasoby odzyskiwania, w tym plik binarny
recovery
itp. - itp.
Na takich urządzeniach konfiguracja produktu dziedziczy z generic_ramdisk.mk
.
Ustawianie wartości BOARD
Ustaw następujące wartości dla urządzeń innych niż A/B:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Inicjacyjne pliki binarne i dowiązania symboliczne
Ramdysk recovery
musi zawierać dowiązanie symboliczne /init -> /system/bin/init
i init_second_stage.recovery
w /system/bin/init
. Gdy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init
jest potrzebny do obsługi zarówno pierwszego, jak i drugiego etapu init.
Po uruchomieniu urządzenia w trybie recovery
zawartość ramdysków recovery
jest następująca:
-
/init -> /system/bin/init
(z ramdyskurecovery
) -
/system/bin/init
(z ramdyskurecovery
, zbudowany zinit_second_stage.recovery
i wykonany z/init
)
Gdy urządzenie uruchamia się w systemie Android, zawartość ramdysku vendor_boot
+ ogólne jest następująca:
-
/init
(z ramdysku, zbudowany zinit_first_stage
)
Przenoszenie plików fstab
Przenieś wszystkie pliki fstab
, które zostały zainstalowane na ogólnym ramdysku do RAMdysku vendor_ramdisk
i dysku recovery
. Na przykład odwołaj się do tej zmiany .
Instalowanie modułów
W razie potrzeby możesz zainstalować moduły specyficzne dla urządzenia vendor_ramdisk
i ramdysku recovery
(pomiń ten krok, jeśli nie masz do zainstalowania żadnych modułów specyficznych dla urządzenia). init
nie przełącza roota. Wariant modułów vendor_ramdisk
instaluje się w katalogu głównym vendor_ramdisk
. Wariant recovery
modułów instaluje się w katalogu głównym dysku ramdysku recovery
. Przykłady instalowania modułów na vendor_ramdisk
i ramdysku recovery
można znaleźć w sekcji Konsola pierwszego stopnia i Sumy kontrolne metadanych .
Konsola pierwszego stopnia
Aby zainstalować wariant modułów vendor_ramdisk
, użyj następujących poleceń:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Zapewnia to, że linker
, sh
i toybox
zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, który następnie zostanie zainstalowany w /system/bin
w obszarze vendor_ramdisk
.
Aby dodać moduły potrzebne do konsoli pierwszego stopnia (na przykład adbd), włącz wariant vendor_ramdisk
tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie użyj poniższych poleceń:
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Dzięki temu określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
.
Aby zainstalować wariant recovery
modułów, zamień vendor_ramdisk
na recovery
:
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
adbd.recovery \
Sumy kontrolne metadanych
Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia nie obsługujące GKI instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania w procesie odzyskiwania, włącz wariant odzyskiwania tych modułów i również je zainstaluj.
Zmiany w procesie uruchamiania
Podczas uruchamiania systemu Android proces uruchamiania nie ulega zmianie. vendor_boot
+ ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z tą różnicą, że fstab
ładuje się z vendor_boot
. Ponieważ system/bin/recovery
nie istnieje, first_stage_init
obsługuje to jako normalny rozruch.
Podczas uruchamiania w trybie odzyskiwania proces uruchamiania nie ulega zmianie. Ramdysk odzyskiwania jest ładowany w taki sam sposób, jak istniejący proces odzyskiwania. Jądro jest ładowane z obrazu recovery
. Proces uruchamiania w trybie odzyskiwania jest następujący.
Program ładujący zostanie uruchomiony, a następnie wykona następujące czynności:
- Wypycha ramdysk odzyskiwania do
/
. - Uruchamia jądro z partycji
recovery
.
- Wypycha ramdysk odzyskiwania do
Jądro montuje ramdysk do
/
następnie wykonuje polecenie/init
, które jest dowiązaniem symbolicznym do/system/bin/init
z dysku RAMrecovery
.Rozpoczyna się pierwszy etap inicjowania, po którym wykonywane są następujące czynności:
- Ustawia
IsRecoveryMode() == true
iForceNormalBoot() == false
. - Ładuje moduły jądra dostawcy z
/lib/modules
. - Wywołuje funkcję
DoFirstStageMount()
, ale pomija montowanie, ponieważIsRecoveryMode() == true
. (Urządzenie nie zwalnia ramdysku (ponieważ/
jest nadal takie samo), ale wywołujeSetInitAvbVersionInRecovery()
.) - Uruchamia drugi etap init z
/system/bin/init
z dysku ramdyskurecovery
.
- Ustawia
Sygnatury czasowe obrazu rozruchowego
Poniższy kod jest przykładowym plikiem sygnatury czasowej obrazu boot
.
####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file
W czasie kompilacji do ogólnego ramdysku dodawany jest plik
system/etc/ramdisk/build.prop
. Ten plik zawiera informacje o sygnaturze czasowej kompilacji.W czasie wykonywania
init
pierwszego etapu kopiuje pliki z ramdysku dotmpfs
przed zwolnieniem ramdysku, dzięki czemuinit
drugiego etapu może odczytać ten plik w celu ustawienia właściwości znacznika czasu obrazuboot
.