W systemie Android 12 ogólny obraz boot
, określany jako ogólny obraz jądra (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
tylko z jądrem GKI.
W przypadku aktualizacji urządzeń, które nadal korzystają z systemu Android 12 lub starszych wersji jądra, ogólny ramdysk pozostaje tam, gdzie był, bez wymogu 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 znacznikach czasu.
Na urządzeniach, które:
Nie używaj dedykowanej partycji
recovery
, wszystkie bity odzyskiwania są przenoszone z ogólnego ramdysku do ramdyskuvendor_boot
.Użyj dedykowanej partycji
recovery
, nie jest wymagana żadna zmiana w ramdyskurecovery
, ponieważ ramdyskrecovery
jest samowystarczalny.
Architektura
Poniższe diagramy ilustrują architekturę urządzeń z systemem Android 12 lub nowszym. Urządzenia uruchamiane z systemem Android 13 mają nowy obraz init_boot
zawierający ogólny ramdysk. Urządzenia aktualizujące system z Androida 12 do Androida 13 korzystają z tej samej architektury, co w przypadku Androida 12.
Uruchom z systemem Android 13, bez dedykowanego odzyskiwania
Rysunek 1. Urządzenia uruchamiane lub aktualizowane do systemu Android 13 z GKI, bez dedykowanego odzyskiwania
Uruchom z systemem Android 13, dedykowanym i odzyskiwaniem A/B (dedykowany ramdysk)
Rysunek 2. Urządzenia uruchamiane lub aktualizowane do systemu Android 13 z GKI, odzyskiwaniem dedykowanym i A/B
Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycje recovery_a
i recovery_b
.
Uruchom z systemem Android 13, odzyskiwanie dedykowane i inne niż A/B (dedykowany ramdysk)
Rysunek 3. Urządzenia uruchamiane lub aktualizowane do systemu Android 13, z GKI, dedykowanym i odzyskiwaniem innym niż A/B
Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycję o nazwie recovery
bez sufiksu gniazda.
Uruchom lub zaktualizuj do Androida 12, bez dedykowanego odzyskiwania
Rysunek 4. Urządzenia uruchamiane lub aktualizowane do systemu Android 12 z GKI, bez dedykowanego odzyskiwania
Uruchom lub zaktualizuj do Androida 12, dedykowane i odzyskiwanie A/B (dedykowany ramdysk)
Rysunek 5. Urządzenia uruchamiane lub aktualizowane do systemu Android 12 z GKI, dedykowanym i odzyskiwaniem A/B
Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycje recovery_a
i recovery_b
.
Uruchom lub zaktualizuj do Androida 12, odzyskiwanie dedykowane i inne niż A/B (dedykowany ramdysk)
Rysunek 6. Urządzenia uruchamiane lub aktualizowane do systemu Android 12, z GKI, dedykowanym i odzyskiwaniem innym niż A/B
Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycję o nazwie recovery
bez sufiksu gniazda.
Uaktualnij do Androida 12, odzyskiwanie jako rozruch (odzyskiwanie jako ramdysk)
Rysunek 7. Urządzenia aktualizujące się do Androida 12, bez GKI, odzyskiwanie po uruchomieniu
Aktualizacja do Androida 12, dedykowane odzyskiwanie (dedykowany ramdysk)
Rysunek 8. Urządzenia aktualizujące się 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
do certyfikacji GKI boot.img (tylko wersja 4). Certyfikowany plik GKIboot.img
nie jest podpisany dla zweryfikowanego rozruchu. Producenci OEM nadal muszą podpisywać gotowy plikboot.img
kluczem AVB specyficznym dla urządzenia. - Ogólna
cmdline
(GENERIC_KERNEL_CMDLINE
) - Jądro GKI
-
- Ogólny obraz ramdysku
- Zawarte tylko w obrazach
boot
z Androida 12 i wcześniejszych
- Zawarte tylko w obrazach
- Wersja nagłówka V3 lub V4
vendor_boot
image (szczegółowe informacje można znaleźć w części Vendor Boot Partitions )- nagłówek
vendor_boot
-
cmdline
specyficzny 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
-
cmdline
specyficzne dla urządzenia do odzyskiwania, jeśli to konieczne - W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielna; zobacz Obrazy odzyskiwania . Na przykład:
-
cmdline
nie jest połączona zboot
ivendor_boot
cmdline
. - Nagłówek określa DTBO odzyskiwania, jeśli to konieczne.
- W przypadku partycji odzyskiwania A/B zawartość można połączyć lub wywnioskować z
boot
ivendor_boot
. Na przykład: -
cmdline
jest połączone zboot
ivendor_boot
cmdline
. - DTBO można wywnioskować z nagłówka
vendor_boot
.
-
- 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ć
init
. - W przypadku partycji odzyskiwania A/B, ramdysk odzyskiwania jest dołączany do ogólnego dysku ram i
vendor_boot
, dlatego nie musi być autonomiczny. Na przykład: -
lib/modules
może zawierać tylko dodatkowe moduły jądra wymagane do uruchomienia trybu odzyskiwania 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 etapu/init
w obrazie rozruchowym.
- 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 montowania:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
-
first_stage_ramdisk/
- Zduplikowane puste katalogi dla punktów montowania:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
- Zduplikowane puste katalogi dla punktów montowania:
Integracja obrazu rozruchowego
Flagi kompilacji kontrolują sposób tworzenia obrazów init_boot
, boot
, recovery
i vendor_boot
. Wartość boolowskiej zmiennej planszowej musi być łańcuchem znaków true
lub być pusta (co jest wartością domyślną).
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 skompilowanego 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, a zasoby odzyskiwania należy przenieść dovendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Ta zmienna wskazuje, że płyta korzysta z GKI. Ta zmienna nie ma wpływu na sysprops aniPRODUCT_PACKAGES
.To jest przełącznik GKI na poziomie płyty; wszystkie zmienne wymienione poniżej są ograniczone przez tę zmienną.
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
. Ta zmienna kontroluje, czy zasoby odzyskiwania z ramdysku są budowane navendor_boot
.W przypadku ustawienia wartości
true
zasoby odzyskiwania są budowane tylko navendor-ramdisk/
i nie są budowane narecovery/root/
.Gdy jest pusta, 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ą budowane navendor_boot
.Po ustawieniu na
true
, jeśliBOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
:Jest ustawiony, klucze GSI AVB są zbudowane na
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb
.Jest nieskonfigurowany, klucze GSI AVB są zbudowane na
$ANDROID_PRODUCT_OUT/vendor-ramdisk/avb
.
Gdy jest pusty, jeśli
BOARD_RECOVERY_AS_ROOT
:Jest ustawiony, klucze GSI AVB są budowane na
$ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb
.Jest nieskonfigurowany, 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 używające funkcji innej niż A/B muszą ustawić tę zmienną nafalse
, aby obraz odzyskiwania był samowystarczalny.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, czyinit_boot.img
jest generowany i określa jego rozmiar. Po ustawieniu ogólny ramdysk jest dodawany doinit_boot.img
zamiastboot.img
i wymaga ustawienia zmiennychBOARD_AVB_INIT_BOOT*
dla powiązanej vbmeta
Dozwolone kombinacje
Składnik lub zmienna | Aktualizowanie urządzenia bez partycji recovery | Aktualizowanie 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ą. Dla tych urządzeń, jeśli ustawiono BOARD_RECOVERYIMAGE_PARTITION_SIZE
, tworzony jest obraz recovery
.
Włącz połączoną vbmeta do rozruchu
Łańcuch vbmeta musi być włączony dla obrazów boot
i init_boot
. 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
Przykład można znaleźć w tej zmianie .
System jako root
System-as-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. System-as-root również nie jest obsługiwany w przypadku urządzeń korzystających z partycji dynamicznych.
Konfiguracje produktów
Urządzenia korzystające z ogólnego ramdysku muszą zainstalować listę plików, które mogą być instalowane w ramdysku. Aby to zrobić, określ następujące elementy w device.mk
:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
Plik generic_ramdisk.mk
zapobiega również przypadkowemu instalowaniu 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ę między urządzeniami uruchamianymi z systemem Android 13, aktualizacją do systemu Android 12 i uruchamianiem z systemem Android 12. Konfiguracja systemu Android 13 jest podobna do konfiguracji systemu Android 12
Urządzenia uaktualniające do Androida 12:
Może zachować wartość
BOARD_USES_RECOVERY_AS_BOOT
. Jeśli to robią, używają starszych konfiguracji, a nowe zmienne kompilacji muszą być puste. Jeśli 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 puste. Jeśli to robią, używają nowych konfiguracji. Jeśli takie urządzenia:Nie używaj dedykowanej partycji
recovery
, architektura jest taka, jak pokazano na rysunku 1 , a opcja konfiguracji urządzenia to Opcja 1 .Użyj dedykowanej partycji
recovery
, architektura jest taka, jak pokazano 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 pustą i korzystać z nowych konfiguracji. Jeśli takie urządzenia:Nie używaj dedykowanej partycji
recovery
, architektura jest taka, jak pokazano na rysunku 1 , a opcja konfiguracji urządzenia to Opcja 1 .Użyj dedykowanej partycji
recovery
, architektura jest taka, jak pokazano 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
lub odzyskiwanie), nie jest to kompletny cel. Aby zapoznać się z konfiguracjami kompilacji aosp_arm64
, zapoznaj się z generic_arm64
.
Opcja 1: Brak dedykowanej partycji odzyskiwania
Urządzenia bez partycji recovery
zawierają ogólny obraz boot
na partycji boot
. Ramdysk vendor_boot
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
Inicjuj pliki binarne i dowiązania symboliczne
Ramdysk vendor_boot
może zawierać dowiązanie symboliczne /init
do /system/bin/init
oraz init_second_stage.recovery
w /system/bin/init
. Ponieważ jednak ogólny ramdysk jest łączony po ramdysku vendor_boot
, dowiązanie symboliczne /init
jest zastępowane. Gdy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init
jest potrzebny do obsługi drugiego etapu init. Zawartość vendor_boot
+ ogólne ramdyski 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ólny ramdysk do vendor_ramdisk
. Przykład można znaleźć w tej zmianie .
Instalowanie modułów
Jeśli chcesz, możesz zainstalować moduły specyficzne dla urządzenia na vendor_ramdisk
(pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania).
Użyj wariantu
vendor_ramdisk
modułu, gdy moduł jest instalowany na/first_stage_ramdisk
. Ten moduł powinien być dostępny po tym, jakinit
przełączy roota na/first_stage_ramdisk
, ale zaniminit
przełączy roota na/system
. Aby zapoznać się z przykładami, zobacz Sumy kontrolne metadanych i Wirtualna kompresja A/B .Użyj wariantu
recovery
modułu, gdy moduł jest instalowany w katalogu/
. Ten moduł 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 etapu .
Konsola pierwszego stopnia
Ponieważ konsola pierwszego etapu uruchamia się przed przełączeniem programu init
na katalog główny /first_stage_ramdisk
, należy 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 makefile urządzenia dziedziczy z tego pliku, nie trzeba jawnie instalować wariantu recovery
.
Aby jawnie zainstalować moduły odzyskiwania, wykonaj następujące czynności.
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
Gwarantuje to, że linker
, sh
i toybox
zostaną zainstalowane w $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, który następnie zostanie zainstalowany w /system/bin
pod vendor_ramdisk
.
Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), użyj poniższego.
PRODUCT_PACKAGES += adbd.recovery
Gwarantuje to, że określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, który następnie zostanie zainstalowany w /system/bin
w katalogu vendor_ramdisk
.
Sumy kontrolne metadanych
Aby obsługiwać sumy kontrolne metadanych podczas montowania na pierwszym etapie, urządzenia, które nie obsługują 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 \
Przykład można znaleźć w tej liście 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 vendor_ramdisk
snapuserd
.
Zmiany w procesie rozruchu
Proces uruchamiania w trybie odzyskiwania lub w systemie Android nie zmienia się, z następującym wyjątkiem:
- Ramdysk
build.prop
przenosi się do/second_stage_resources
, abyinit
drugiego etapu mógł odczytać znacznik czasu kompilacji rozruchu.
Ponieważ zasoby są przenoszone z ramdysku ogólnego do ramdysku vendor_boot
, wynik łączenia ogólnego dysku ram z dyskiem ramdysku vendor_boot
nie zmienia się.
Udostępnianie e2fsck
Makefile urządzeń 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 root na /first_stage_ramdisk
a następnie wykonuje /system/bin/e2fsck
.
Opcja 2a: Partycja dedykowana i partycja odzyskiwania A/B
Użyj tej opcji dla urządzeń z partycjami recovery
A/B; oznacza to, że urządzenie ma partycję recovery_a
i recovery_b partition
. Takie urządzenia obejmują urządzenia A/B i wirtualne urządzenia A/B, których partycję odzyskiwania można aktualizować, o następującej konfiguracji:
AB_OTA_PARTITIONS += recovery
Ramdysk 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
Inicjuj 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 dysk rozruchowy jest łączony po dysku recovery
, dowiązanie symboliczne /init
jest zastępowane. 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 ramdyski 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 system Android, zawartość vendor_boot
+ ogólne ramdyski są następujące:
-
/init
(z ogólnego ramdysku, zbudowanego zinit_first_stage
)
Przenoszenie plików fstab
Przenieś wszystkie pliki fstab
, które zostały zainstalowane na ogólny ramdysk do vendor_ramdisk
. Przykład można znaleźć w tej zmianie .
Instalowanie modułów
Jeśli chcesz, możesz zainstalować moduły specyficzne dla urządzenia na vendor_ramdisk
(pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). Init
nie zmienia roota. Wariant vendor_ramdisk
modułów instaluje się w katalogu głównym vendor_ramdisk
. Aby zapoznać się z przykładami instalowania modułów na vendor_ramdisk
, zobacz Konsola pierwszego etapu , Sumy kontrolne metadanych i Wirtualna kompresja A/B .
Konsola pierwszego stopnia
Aby zainstalować wariant vendor_ramdisk
modułów, użyj następujących elementów:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Gwarantuje to, że linker
, sh
i toybox
zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, który następnie zostanie zainstalowany w /system/bin
pod vendor_ramdisk
.
Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), włącz wariant vendor_ramdisk
tych modułów, przesyłając odpowiednie łatki do AOSP, a następnie użyj następujących:
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 ładowany w trybie odzyskiwania, moduł jest również dostępny w recovery
. Jeśli ramdysk vendor_boot
nie jest załadowany w trybie odzyskiwania, urządzenie może opcjonalnie zainstalować adbd.recovery
.
Sumy kontrolne metadanych
Aby obsługiwać sumy kontrolne metadanych podczas montowania na pierwszym etapie, urządzenia, które nie obsługują 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 \
Przykład można znaleźć w tej liście 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 vendor_ramdisk
snapuserd
.
Zmiany w procesie rozruchu
Podczas uruchamiania systemu Android proces uruchamiania się nie zmienia. vendor_boot
+ ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z wyjątkiem tego, ż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 zmienia się. Recovery + vendor_boot
+ ogólny ramdysk jest podobny do istniejącego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot
zamiast z obrazu recovery
. Proces uruchamiania w trybie odzyskiwania jest następujący.
Bootloader uruchamia się, a następnie wykonuje następujące czynności:
- Wypycha odzyskiwanie +
vendor_boot
+ ogólny ramdysk do/
. (Jeśli producent OEM duplikuje 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/init
z ogólnego ramdysku.Rozpoczyna się init pierwszego etapu, a następnie wykonuje następujące czynności:
- Ustawia
IsRecoveryMode() == true
iForceNormalBoot() == false
. - Ładuje moduły jądra dostawcy z
/lib/modules
. - Wywołuje
DoFirstStageMount()
, ale pomija montowanie, ponieważIsRecoveryMode() == true
. (Urządzenie nie zwalnia ramdysku (ponieważ/
jest wciąż taki sam), ale wywołujeSetInitAvbVersionInRecovery()
.) - Uruchamia init drugiego etapu z
/system/bin/init
z ramdyskurecovery
.
- Ustawia
Udostępnianie e2fsck
Makefile urządzeń 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 i nie-A/B partycja odzyskiwania
Użyj tej opcji dla urządzeń z partycją recovery
inną niż A/B; oznacza to, że urządzenie ma partycję o nazwie recovery
bez sufiksu gniazda. Do takich urządzeń należą:
- urządzenia inne niż A/B;
- Urządzenia A/B i wirtualne urządzenia A/B, których partycji odzyskiwania nie można aktualizować. (To jest niezwykłe.)
Ramdysk 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ć samowystarczalny. Musi zawierać wszystkie wymagane zasoby 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
- Init binarny drugiego etapu
/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
Inicjuj 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.
Gdy urządzenie uruchamia się 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 system Android, zawartość vendor_boot
+ ogólne ramdyski są następujące:
-
/init
(z ramdysku, zbudowany zinit_first_stage
)
Przenoszenie plików fstab
Przenieś wszystkie pliki fstab
, które zostały zainstalowane na ogólny ramdysk do vendor_ramdisk
i recovery
ramdysk. Przykład można znaleźć w tej zmianie .
Instalowanie modułów
Jeśli chcesz, możesz zainstalować moduły specyficzne dla urządzenia na vendor_ramdisk
i recovery
ramdisk (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). init
nie zmienia roota. Wariant vendor_ramdisk
modułów instaluje się w katalogu głównym vendor_ramdisk
. Wariant recovery
modułów jest instalowany w katalogu głównym ramdysku recovery
. Aby zapoznać się z przykładami instalowania modułów na dysku vendor_ramdisk
i dysku recovery
, zobacz Konsola pierwszego etapu i sumy kontrolne metadanych .
Konsola pierwszego stopnia
Aby zainstalować wariant vendor_ramdisk
modułów, użyj następujących elementów:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Gwarantuje to, że linker
, sh
i toybox
zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, który następnie zostanie zainstalowany w /system/bin
pod vendor_ramdisk
.
Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), włącz wariant vendor_ramdisk
tych modułów, przesyłając odpowiednie łatki do AOSP, a następnie użyj następujących:
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 montowania na pierwszym etapie, urządzenia, które nie obsługują 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 podczas odzyskiwania, włącz wariant odzyskiwania tych modułów i również je zainstaluj.
Zmiany w procesie rozruchu
Podczas uruchamiania systemu Android proces uruchamiania się nie zmienia. vendor_boot
+ ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z wyjątkiem tego, ż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 zmienia się. 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.
Bootloader uruchamia się, a następnie wykonuje następujące czynności:
- Wypycha ramdysk odzyskiwania do
/
. - Uruchamia jądro z partycji
recovery
.
- Wypycha ramdysk odzyskiwania do
Jądro montuje ramdysk w
/
następnie wykonuje/init
, które jest dowiązaniem symbolicznym do/system/bin/init
z ramdyskurecovery
.Rozpoczyna się init pierwszego etapu, a następnie wykonuje następujące czynności:
- Ustawia
IsRecoveryMode() == true
iForceNormalBoot() == false
. - Ładuje moduły jądra dostawcy z
/lib/modules
. - Wywołuje
DoFirstStageMount()
, ale pomija montowanie, ponieważIsRecoveryMode() == true
. (Urządzenie nie zwalnia ramdysku (ponieważ/
jest wciąż taki sam), ale wywołujeSetInitAvbVersionInRecovery()
.) - Uruchamia init drugiego etapu z
/system/bin/init
z ramdyskurecovery
.
- Ustawia
Sygnatury czasowe obrazu rozruchowego
Poniższy kod to przykładowy plik 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 pierwszy etap
init
kopiuje pliki z ramdysku dotmpfs
przed zwolnieniem ramdysku, aby drugi etapinit
mógł odczytać ten plik i ustawić właściwości znacznika czasu obrazuboot
.