Ogólna partycja rozruchu

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W Androidzie 12 ogólny obraz boot, zwany ogólnym obrazem jądra (GKI), zawiera ogólny obraz ramdisk i jądro GKI.

W przypadku urządzeń uruchamianych z Androidem 13 ogólny obraz ramdisk jest usuwany z obrazu boot i przenoszony do oddzielnego obrazu init_boot. Ta zmiana powoduje, że obraz boot zawiera tylko jądro GKI.

W przypadku urządzeń, które nadal używają Androida 12 lub starszych wersji jądra, ogólny obraz pamięci RAM pozostaje w tym samym miejscu, bez konieczności korzystania z nowego obrazu init_boot.

Aby utworzyć ogólny dysk RAM, usuń zasoby specyficzne dla dostawcy z dysku RAM, tak aby ogólny dysk RAM zawierał tylko plik init pierwszego etapu i plik usługi zawierający informacje o sygnaturze czasowej.

Na urządzeniach, które:

• Nie używaj partycji recovery, ponieważ wszystkie bity odzyskiwania zostaną przeniesione z ramdysk ogólnego do ramdysk vendor_boot.

• Użyj dedykowanej partycji recovery. Nie musisz zmieniać pliku ramdysk recovery, ponieważ jest on samodzielny.recovery

Architektura

Na diagramach poniżej pokazano architekturę urządzeń z Androidem 12 lub nowszym. Urządzenia z Androidem 13 mają nowy obraz init_boot zawierający ogólny dysk RAM. Urządzenia, które przechodzą z Androida 12 na Androida 13, korzystają z tej samej architektury co w Androidzie 12.

Uruchom z Androidem 13 bez dedykowanego odzyskiwania

Rysunek 1. Urządzenia z Androidem 13 lub z aktualizacją do tej wersji z Google Play Ki. Nie ma dedykowanego odzyskiwania.

Uruchom z Androidem 13, dedykowanym i A/B odzyskiem (dedykowany dysk RAM)

Rysunek 2. Urządzenia z Androidem 13, które są uruchamiane lub aktualizowane do tej wersji, z Google Play jako interfejsem graficznym, z osobnym odzyskiem i z odzyskiem A/B.

Jeśli na urządzeniu są partycje recovery_a i recovery_b, zapoznaj się z tą ilustracją.

Uruchom z Androidem 13, dedykowanym i niestandardowym odzyskiem (dedykowany dysk RAM).

Rysunek 3. Urządzenia z Androidem 13, które uruchamiają system lub są aktualizowane do niego, z interfejsem GKI i specjalnym trybem odzyskiwania, który nie obsługuje funkcji A/B.

Zapoznaj się z tą ilustracją, jeśli na urządzeniu jest partycja o nazwie recovery bez sufiksu slotu.

Uruchomienie lub uaktualnienie do Androida 12 bez specjalnego odzyskiwania

Rysunek 4. Urządzenia uruchamiające lub aktualizujące Androida 12 z Google Keyboard, bez dedykowanego odzyskiwania.

Uruchom lub zaktualizuj Androida 12, dedykowane i A/B odzyskiwanie (dedykowany dysk RAM)

Rysunek 5. Urządzenia z Androidem 12, które uruchamiają ten system lub przechodzą na niego z użyciem GKI, przywracania dedykowanego lub A/B.

Jeśli na urządzeniu są partycje recovery_a i recovery_b, zapoznaj się z tą ilustracją.

uruchomić lub uaktualnić Androida 12, dedykowane i niestandardowe odzyskiwanie (dedykowany dysk RAM), które nie jest związane z odzyskiwaniem A/B;

Rysunek 6. Urządzenia z Androidem 12, które uruchamiają ten system lub przechodzą na niego z użyciem GKI, z przywróceniem dedykowanym lub nieobsługującym funkcji A/B.

Zapoznaj się z tą ilustracją, jeśli na urządzeniu jest partycja o nazwie recovery bez sufiksu slotu.

Przejście na Androida 12, recovery-as-boot (recovery-as-ramdisk)

Rysunek 7. Urządzenia przechodzące na Androida 12 bez GKI, z trybem odzyskiwania jako trybem rozruchu.

Uaktualnienie do Androida 12, specjalny tryb odzyskiwania (specjalny dysk RAM)

Rysunek 8. Urządzenia przechodzące na Androida 12 bez GKI, specjalne odzyskiwanie.

Zawartość obrazów rozruchowych

Obrazy rozruchu Androida zawierają:

• init_boot dodano obraz dla urządzeń z Androidem 13

  • Wersja nagłówka: V4
  • Ogólny obraz dysku RAM

• Zdjęcie ogólne boot

  • Wersja nagłówka: V3 lub V4
    • boot_signature dla certyfikatu GKI boot.img (tylko w wersji 4). Certyfikowany GKI boot.img nie jest podpisany w celu weryfikacji podczas uruchamiania. Producenci OEM muszą nadal podpisywać wstępnie utworzone boot.img za pomocą klucza AVB odpowiedniego dla danego urządzenia.
    • Ogólne cmdline (GENERIC_KERNEL_CMDLINE)
    • Jądro GKI
  • Ogólny obraz dysku RAM
    • Dotyczy tylko obrazów boot w Androidzie 12 i starszych

• obraz vendor_boot (szczegóły znajdziesz w partycjach rozruchu dostawcy)

  • vendor_boot nagłówek
    • Specyficzne dla urządzenia cmdline (BOARD_KERNEL_CMDLINE)
  • vendor_boot obraz dysku RAM
    • lib/modules
    • Zasoby dotyczące przywracania (jeśli nie ma dedykowanego narzędzia do przywracania)
  • dtb obraz

• recovery obraz

  • Wersja nagłówka V2
    • W razie potrzeby informacje o przywróceniu cmdline dotyczące urządzenia
    • W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielna (patrz Obrazy odzyskiwania). Przykład:
    • cmdline nie jest złączany z boot i vendor_boot cmdline.
    • W nagłówku w razie potrzeby określono DTBO odzyskiwania.
    • W przypadku partycji odzyskiwania A/B treści mogą być łączone lub wywnioskowane z poziomów boot i vendor_boot. Przykład:
    • cmdline jest złączone z boot i vendor_boot cmdline.
    • DTBO można określić na podstawie nagłówka vendor_boot.
  • recovery obraz dysku RAM
    • Zasoby do odzyskiwania
    • W przypadku partycji odzyskiwania innej niż A/B zawartość dysku RAM musi być samodzielna (patrz obrazy odzyskiwania). Przykład:
    • lib/modules musi zawierać wszystkie moduły jądra wymagane do uruchomienia trybu odzyskiwania.
    • Pamięć RAM dysku odzyskiwania musi zawierać init.
    • W przypadku partycji odzyskiwania A/B dysk RAM odzyskiwania jest dodawany na początku ogólnego dysku RAM i dysku RAM vendor_boot, dlatego nie musi być samodzielny. Przykład:
    • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do uruchamiania trybu odzyskiwania, oprócz modułów jądra w pliku ramdysk vendor_boot.
    • Plik symboliczny w katalogu /init może istnieć, ale jest przysłonięty przez binarne dane /init pierwszego etapu w pliku obrazu rozruchowego.

Treści ogólnego obrazu dysku RAM

Ogólny dysk RAM zawiera te komponenty:

• init
• system/etc/ramdisk/build.prop
• ro.PRODUCT.bootimg.* build rekwizyty
• Pustych katalogów dla punktów zamontowania: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
• first_stage_ramdisk/
  • Zduplikowane puste katalogi dla punktów zamontowania: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Integracja obrazu rozruchowego

Flagi kompilacji określają sposób kompilowania obrazów init_boot, boot, recovery i vendor_boot. Wartość zmiennej logicznej na planszy musi być ciągiem tekstowym true lub pustym (co jest domyślną wartością).

• TARGET_NO_KERNEL. Ta zmienna wskazuje, czy kompilacja używa wstępnie utworzonego obrazu rozruchu. Jeśli ta zmienna ma wartość true, ustaw BOARD_PREBUILT_BOOTIMAGE na lokalizację wstępnie utworzonego obrazu rozruchowego (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

• BOARD_USES_RECOVERY_AS_BOOT. Ta zmienna wskazuje, czy urządzenie używa obrazu recovery jako obrazu boot. Gdy używasz GKI, ta zmienna jest pusta, a zasoby do odzyskiwania należy przenieść do vendor_boot.

• BOARD_USES_GENERIC_KERNEL_IMAGE. Ta zmienna wskazuje, że tablica używa interfejsu graficznego GKI. Ta zmienna nie ma wpływu na zmienne sysprops ani PRODUCT_PACKAGES.

  Jest to przełącznik GKI na poziomie tablicy. Wszystkie kolejne zmienne są ograniczone przez tę zmienną.

• BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Ta zmienna określa, czy zasoby do odzyskiwania danych z pamięci RAM są budowane w vendor_boot.

  • Gdy ustawisz wartość true, zasoby odzyskiwania są tworzone tylko w wersji vendor-ramdisk/, a nie w wersji recovery/root/.

  • Jeśli są puste, zasoby do odzyskiwania są tworzone tylko do recovery/root/, a nie do vendor-ramdisk/.

• BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Ta zmienna określa, czy klucze GSI AVB są tworzone w vendor_boot.

  • Gdy ustawisz wartość true, jeśli BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

    • Jeśli jest ustawiona, klucze GSI AVB są tworzone w celu $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

    • Nie ustawiono, klucze GSI AVB są tworzone do $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

  • Jeśli BOARD_RECOVERY_AS_ROOT jest pusty:

    • Jeśli jest ustawiona, klucze GSI AVB są tworzone w celu $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

    • Nie ustawiono, klucze GSI AVB są tworzone do $ANDROID_PRODUCT_OUT/ramdisk/avb.

• BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Ta zmienna określa, czy obraz recovery zawiera rdzeń. Urządzenia uruchamiane z Androidem 12 i korzystające z partycji A/B recovery muszą mieć tę zmienną ustawioną na true. Urządzenia uruchamiane z Androidem 12 i korzystające z niestandardowych wersji A/B muszą mieć tę zmienną ustawioną na false, aby obraz odzyskiwania był samodzielny.

• BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Ta zmienna określa, czy $OUT/boot*.img ma być kopiowana do IMAGES/ w plikach docelowych.

  • Zmienna aosp_arm64 musi mieć wartość true.

  • Inne urządzenia muszą pozostawić to pole puste.

• BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Ta zmienna określa, czy ma być generowany element init_boot.img, oraz ustawia jego rozmiar. Gdy jest ustawiona, ogólna pamięć ramdisk jest dodawana do init_boot.img zamiast boot.img i wymaga ustawienia zmiennych BOARD_AVB_INIT_BOOT* dla łańcucha vbmeta.

Dozwolone kombinacje

Na urządzeniach z osobnym partycją recovery można ustawić wartość PRODUCT_BUILD_RECOVERY_IMAGE na true lub pustą. W przypadku tych urządzeń, jeśli ustawiona jest opcja BOARD_RECOVERYIMAGE_PARTITION_SIZE, tworzony jest obraz recovery.

Włączanie łańcucha vbmeta na potrzeby rozruchu

W przypadku obrazów boot i init_boot musi być włączona połączona wartość vbmeta. Podaj te 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ładem takiej zmiany jest ta.

System jako root

System jako root nie jest obsługiwany na urządzeniach, które korzystają z GKI. Na takich urządzeniach wartość BOARD_BUILD_SYSTEM_ROOT_IMAGE musi być pusta. System jako root nie jest też obsługiwany na urządzeniach, które korzystają z partycji dynamicznych.

Konfiguracje usług

Urządzenia, które korzystają z urządzenia typu generic ramdisk, muszą zainstalować listę plików, które mogą być zainstalowane na tym urządzeniu. Aby to zrobić, w polu device.mk podaj te informacje:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

Plik generic_ramdisk.mk uniemożliwia też przypadkowe zainstalowanie innych plików na dysku RAM (zamiast tego przenieś takie pliki do folderu vendor_ramdisk).

Konfigurowanie urządzeń

Instrukcje konfiguracji różnią się w zależności od tego, czy urządzenie ma Androida 13, czy jest aktualizowane do Androida 12, czy też ma Androida 12. Android 13, są konfigurowane podobnie jak w Androidzie 12.

• Urządzenia aktualizowane do Androida 12:

  • Może zachować wartość BOARD_USES_RECOVERY_AS_BOOT. Jeśli tak się stanie, oznacza to, że używasz starszych konfiguracji, a nowe zmienne kompilacji muszą być puste. Jeśli takie urządzenia:

    • Ustaw BOARD_USES_RECOVERY_AS_BOOT na true, a architektura będzie wyglądać tak jak na rysunku 3.

    • Jeśli BOARD_USES_RECOVERY_AS_BOOT jest pusty, architektura wygląda tak, jak na rysunku 4.

  • Można ustawić BOARD_USES_RECOVERY_AS_BOOT jako puste. Jeśli tak, oznacza to, że używają nowych konfiguracji. Jeśli takie urządzenia:

    • Nie używaj dedykowanego partycji recovery, architektura jest taka jak na rysunku 1, a opcja konfiguracji urządzenia to Opcja 1.

    • Użyj dedykowanego recovery partycji. Architektura jest taka jak na rysunku 2a lub rysunku 2b, a opcja konfiguracji urządzenia to Opcja 2a lub Opcja 2b.

• Urządzenia uruchamiane z Androidem 12 muszą mieć pusty parametr BOARD_USES_RECOVERY_AS_BOOT i wykorzystywać nowe konfiguracje. Jeśli takie urządzenia:

  • Nie używaj dedykowanego partycji recovery, architektura jest taka jak na rysunku 1, a opcja konfiguracji urządzenia to Opcja 1.

  • Użyj dedykowanego recovery partycji. Architektura jest taka jak na rysunku 2a lub rysunku 2b, a opcja konfiguracji urządzenia to Opcja 2a lub Opcja 2b.

Funkcja aosp_arm64 tworzy tylko GKI (a nie vendor_boot ani odzyskiwanie), więc nie jest to pełny cel. Informacje o konfiguracjach kompilacji aosp_arm64 znajdziesz w artykule generic_arm64.

Opcja 1. Brak dedykowanej partycji odzyskiwania

Urządzenia bez partycji recovery zawierają ogólne zdjęcie boot w partycji boot. Pamięć RAM vendor_boot zawiera wszystkie zasoby odzyskiwania, w tym lib/modules (z modułami jądra dostawcy). Na takich urządzeniach konfiguracja produktu przejmuje ustawienia z generic_ramdisk.mk.

Ustawianie wartości BOARD

Ustaw te 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

Binarne i symboliczne pliki binarne

Dysk RAM vendor_boot może zawierać symboliczny link /init do /system/bin/init oraz init_second_stage.recovery w /system/bin/init. Ponieważ jednak ogólny dysk RAM jest łączony po dysku RAM vendor_boot, /initsymlink zostanie nadpisany. Gdy urządzenie uruchomi się w trybie odzyskiwania, potrzebny jest plik binarny /system/bin/init, aby umożliwić inicjalizację drugiego etapu. Zawartość vendor_boot + generic ramdisks:

• /init (z ram dysku ogólnego, utworzonego z init_first_stage)
• /system/bin/init (z vendor_ramdisk, utworzony na podstawie pliku init_second_stage.recovery)

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab, które zostały zainstalowane na typowym dysku RAM, do folderu vendor_ramdisk. Przykładem takiej zmiany jest ta.

Instalowanie modułów

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).

• Podczas instalowania modułu na /first_stage_ramdisk użyj jego wariantu vendor_ramdisk. Ten moduł powinien być dostępny po tym, jak init przełączy się na /first_stage_ramdisk, ale zanim init przełączy się na /system. Przykłady znajdziesz w artykułach Sumy kontrolne metadanych i Wirtualna kompresja A/B.

• Podczas instalowania modułu na urządzeniu / użyj jego wersji recovery. Ten moduł powinien być dostępny, zanim init przełączy się na /first_stage_ramdisk. Szczegółowe informacje o instalowaniu modułów w konsoli First Stage znajdziesz w artykule Konsola First Stage./

Konsola pierwszego etapu

Ponieważ konsola pierwszego etapu uruchamia się, zanim init przełączy się na /first_stage_ramdisk, musisz zainstalować wariant modułów recovery. Domyślnie oba warianty modułu są instalowane w pliku build/make/target/product/base_vendor.mk, więc jeśli plik makefile urządzenia dziedziczy z tego pliku, nie musisz instalować wariantu recovery.

Aby wyraźnie zainstalować moduły odzyskiwania, wykonaj te czynności.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Dzięki temu aplikacje linker, sh i toybox zostaną zainstalowane na urządzeniu $ANDROID_PRODUCT_OUT/recovery/root/system/bin, które następnie zainstaluje aplikację /system/bin na urządzeniu vendor_ramdisk.

Aby dodać moduły potrzebne do konsoli pierwszego etapu (np. adbd), wykonaj te czynności.

PRODUCT_PACKAGES += adbd.recovery

Dzięki temu określone moduły zostaną zainstalowane w folderze $ANDROID_PRODUCT_OUT/recovery/root/system/bin, a następnie w folderze /system/bin w folderze vendor_ramdisk.

Suma kontrolna metadanych

Aby obsługiwać suma kontrolna metadanych podczas pierwszego etapu montowania, urządzenia, które nie obsługują GKI, instalują wersję ramdisk tych modułów. Aby dodać obsługę GKI, przenieś moduły do folderu $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Przykładem takiej listy jest ta lista zmian.

Wirtualna kompresja A/B

Aby umożliwić kompresję A/B w przypadku wirtualnych urządzeń, musisz zainstalować snapuserd na vendor_ramdisk. Urządzenie powinno dziedziczyć ustawienia z virtual_ab_ota/compression.mk, która instaluje wariant vendor_ramdisk aplikacji snapuserd.

Zmiany w procesie rozruchu

Proces uruchamiania trybu odzyskiwania lub Androida nie ulegnie zmianie, z jednym wyjątkiem:

• Ramdisk build.prop przechodzi do poziomu /second_stage_resources, aby drugi etap init mógł odczytać sygnaturę czasową kompilacji podczas uruchamiania.

Zasoby są przenoszone z ramdisku ogólnego do ramdisku vendor_boot, więc wynik złączenia ramdisku ogólnego z ramdiskiem vendor_boot się nie zmienia.

Udostępnianie e2fsck

Pliki make urządzenia mogą dziedziczyć z:

• virtual_ab_ota/launch_with_vendor_ramdisk.mk, jeśli urządzenie obsługuje wirtualny A/B, ale nie kompresję.

• virtual_ab_ota/compression.mk jeśli urządzenie obsługuje wirtualne kompresowanie A/B.

Instalacja plików make produktu$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. W czasie wykonywania kodu pierwszy etap init przełącza root na /first_stage_ramdisk, a potem wykonuje /system/bin/e2fsck.

Opcja 2a: partycja z odzyskiwaniem danych z partycji dedykowanej i partycji A/B

Użyj tej opcji w przypadku urządzeń z partycjami A/B, czyli z recovery i recovery_a.recovery_b partition Do takich urządzeń należą: A/B i wirtualne A/B, których partycja odzyskiwania jest aktualizowana, z tą konfiguracją:

AB_OTA_PARTITIONS += recovery

Pamięć RAM vendor_boot zawiera bity dostawcy pamięci RAM i modułów jądra dostawcy, w tym:

• Pliki fstab na urządzeniu

• lib/modules (obejmuje moduły jądra dostawcy)

Dysk RAM recovery zawiera wszystkie zasoby do odzyskiwania. Na takich urządzeniach konfiguracja produktu przejmuje ustawienia z generic_ramdisk.mk.

Ustawianie wartości BOARD

W przypadku urządzeń z partycją A/B recovery ustaw te wartości:

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

binarne i symboliczne pliki binarne,

Plik ramdysk recovery może zawierać symboliczny link /init -> /system/bin/init i init_second_stage.recovery w /system/bin/init. Ponieważ jednak dysk RAM rozruchu jest łączony po dysku RAM recovery, łącznik symboliczny /init zostaje zastąpiony. Gdy urządzenie uruchomi się w trybie odzyskiwania, potrzebny jest plik binarne /system/bin/init do obsługi drugiej fazy inicjalizacji.

Gdy urządzenie uruchamia się w trybie recovery, zawartość recovery + vendor_boot + ogólne dyski RAM wygląda tak:

• /init (z ramdisku, utworzone z init_first_stage)
• /system/bin/init (z ramdysk recovery, utworzonego z init_second_stage.recovery i uruchamianego z /init)

Gdy urządzenie uruchamia Androida, zawartość vendor_boot + genericzne ramdiski wygląda tak:

• /init (z ram dysku ogólnego, utworzonego z init_first_stage)

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab, które zostały zainstalowane na typowym dysku RAM, do folderu vendor_ramdisk. Przykładem takiej zmiany jest ta.

Instalowanie modułów

Opcjonalnie możesz zainstalować na urządzeniu vendor_ramdisk moduły przeznaczone dla konkretnych urządzeń (pomiń ten krok, jeśli nie masz żadnych takich modułów). Initnie przełącza roota. Moduł vendor_ramdisk jest instalowany w poziomie głównym vendor_ramdisk. Przykłady instalacji modułów w vendor_ramdisk znajdziesz w artykułach Konsola pierwszego etapu, Sumy kontrolne metadanych i Kompresja wirtualna A/B.

Konsola pierwszego etapu

Aby zainstalować wariant vendor_ramdisk modułów, wykonaj te czynności:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu aplikacje linker, sh i toybox zostaną zainstalowane na urządzeniu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, które następnie zainstaluje aplikację /system/bin na urządzeniu vendor_ramdisk.

Aby dodać moduły potrzebne do konsoli pierwszego etapu (np. adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie wykonaj te czynności:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Dzięki temu określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Jeśli dysk RAM vendor_boot jest wczytany w trybie odzyskiwania, moduł jest też dostępny w recovery. Jeśli w trybie odzyskiwania nie zostanie załadowany dysk RAM vendor_boot, na urządzeniu można opcjonalnie zainstalować dysk adbd.recovery.

Suma kontrolna metadanych

Aby obsługiwać suma kontrolna metadanych podczas pierwszego etapu montowania, urządzenia, które nie obsługują GKI, instalują wersję ramdisk tych modułów. Aby dodać obsługę GKI, przenieś moduły do folderu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Przykładem takiej listy jest ta lista zmian.

Wirtualna kompresja A/B

Aby zapewnić obsługę kompresji Virtual A/B, na urządzeniu vendor_ramdisk musi być zainstalowany pakiet vendor_ramdisk.snapuserd Urządzenie powinno dziedziczyć ustawienia z virtual_ab_ota/compression.mk, która instaluje wariant vendor_ramdisk aplikacji snapuserd.

Zmiany w procesie rozruchu

Podczas uruchamiania Androida proces uruchamiania się nie zmienia. vendor_boot + generic ramdisk jest podobny do dotychczasowego procesu uruchamiania, z tą różnicą, że fstab wczytuje 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 się zmienia. Tryb odzyskiwania + vendor_boot + ogólny dysk RAM jest podobny do dotychczasowego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot, a nie recovery. Proces uruchamiania trybu odzyskiwania wygląda następująco.

1. Program rozruchowy uruchamia się, a potem wykonuje te czynności:

   1. Przesyłanie danych do odzyskiwania + vendor_boot + generic ramdisk do /. (jeśli OEM powiela moduły jądra w ramdisku odzyskiwania, dodając je do BOARD_RECOVERY_KERNEL_MODULES), vendor_boot jest opcjonalny.
   2. Uruchamia jądro z partycji boot.

2. Rdzeń montuje pamięć RAM na /, a następnie wykonuje /init z ogólnego dysku RAM.

3. Rozpoczyna się pierwsza faza inicjalizacji, która wykonuje te czynności:

   1. Ustawia wartości IsRecoveryMode() == true i ForceNormalBoot() == false.
   2. Ładuje moduły jądra dostawcy z adresu /lib/modules.
   3. wywołuje DoFirstStageMount(), ale pomija montowanie, ponieważ IsRecoveryMode() == true. (Urządzenie nie zwalnia pamięci ramdisk (ponieważ / jest nadal taki sam), ale wywołuje funkcję SetInitAvbVersionInRecovery()).
   4. Rozpoczyna się drugi etap inicjalizacji z poziomu /system/bin/init na dysku RAM recovery.

Udostępnianie e2fsck

Pliki make urządzenia mogą dziedziczyć z:

• virtual_ab_ota/launch_with_vendor_ramdisk.mk, jeśli urządzenie obsługuje wirtualny A/B, ale nie kompresję.

• virtual_ab_ota/compression.mk jeśli urządzenie obsługuje wirtualne kompresowanie A/B.

Instalacja plików make produktu$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. W czasie wykonywania pierwszy etap init wykonuje /system/bin/e2fsck.

Opcja 2b: partycja odzyskiwania niebędąca partycją A/B

Użyj tej opcji w przypadku urządzeń z partycją recovery, która nie jest partycją A/B, czyli z partycją o nazwie recovery bez sufiksu slotu. 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 zaktualizować. (To nietypowa sytuacja).

Pamięć RAM vendor_boot zawiera bity dostawcy pamięci RAM i modułów jądra dostawcy, w tym:

• Pliki fstab na urządzeniu
• lib/modules (obejmuje 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ł jądra w lib/modules
• Inicjalizacja pierwszego etapu jako skrót symboliczny /init -> /system/bin/init
• Drugoetapowa inicjalizacja binarna /system/bin/init
• Pliki fstab na urządzeniu
• wszystkie inne zasoby do odzyskiwania, w tym plik binarny recovery;

Na takich urządzeniach konfiguracja produktu przejmuje ustawienia z generic_ramdisk.mk.

Ustawianie wartości BOARD

W przypadku urządzeń innych niż A/B ustaw te wartości:

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

binarne i symboliczne pliki binarne,

Dysk RAM recovery musi zawierać symboliczny link /init -> /system/bin/init oraz init_second_stage.recovery w katalogu /system/bin/init. Gdy urządzenie uruchamia się w trybie odzyskiwania, binarny plik /system/bin/init jest potrzebny do obsługi zarówno pierwszego, jak i drugiego etapu inicjalizacji.

Gdy urządzenie uruchamia się w trybie recovery, zawartość recovery w ramdysk wygląda tak:

• /init -> /system/bin/init (z recovery dysku RAM)
• /system/bin/init (z ramdysk recovery, utworzonego z init_second_stage.recovery i uruchamianego z /init)

Gdy urządzenie uruchamia Androida, zawartość vendor_boot + genericzne ramdiski wygląda tak:

• /init (z ramdisku, utworzone z init_first_stage)

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab, które zostały zainstalowane na typowym dysku RAM, do dysków RAM vendor_ramdisk i recovery. Przykładem takiej zmiany jest ta.

Instalowanie modułów

Na dysku RAM vendor_ramdisk i recovery możesz zainstalować moduły przeznaczone dla konkretnego urządzenia (pomiń ten krok, jeśli nie musisz instalować żadnych modułów). initnie przełącza roota. Moduł vendor_ramdisk jest instalowany w poziomie głównym vendor_ramdisk. Wariant recovery modułów jest instalowany w głównym katalogu dysku RAM recovery. Przykłady instalowania modułów na dysku RAM vendor_ramdisk i recovery znajdziesz w konsoli pierwszego etapu oraz w artykule Sumy kontrolne metadanych.

Konsola pierwszego etapu

Aby zainstalować wariant vendor_ramdisk modułów, wykonaj te czynności:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu aplikacje linker, sh i toybox zostaną zainstalowane na urządzeniu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, które następnie zainstaluje aplikację /system/bin na urządzeniu vendor_ramdisk.

Aby dodać moduły potrzebne do konsoli pierwszego etapu (np. adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie wykonaj te czynności:

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, zastąp vendor_ramdisk kodem recovery:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

Suma kontrolna metadanych

Aby obsługiwać suma kontrolna metadanych podczas pierwszego etapu montowania, urządzenia, które nie obsługują GKI, instalują wersję ramdisk tych modułów. Aby dodać obsługę GKI, przenieś moduły do folderu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Aby umożliwić sprawdzanie sum kontrolnych metadanych podczas pierwszego etapu montowania w przywracaniu, włącz wariant odzyskiwania tych modułów i je zainstaluj.

Zmiany w procesie rozruchu

Podczas uruchamiania Androida proces uruchamiania się nie zmienia. vendor_boot + generic ramdisk jest podobny do dotychczasowego procesu uruchamiania, z tą różnicą, że fstab wczytuje 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 się nie zmienia. Pamięć odzyskiwania jest ładowana w taki sam sposób jak w dotychczasowym procesie odzyskiwania. Kernel jest ładowany z obrazu recovery. Proces uruchamiania w trybie odzyskiwania wygląda tak.

1. Program rozruchowy uruchamia się, a potem wykonuje te czynności:

   1. Przesyłanie dysku odzyskiwania do /.
   2. Uruchamia jądro z partycji recovery.

2. Rdzeń montuje dysk ramowy na /, a następnie wykonuje /init, który jest linkiem symbolicznym do /system/bin/init z dysku ramowego recovery.

3. Rozpoczyna się pierwsza faza inicjalizacji, która wykonuje te czynności:

   1. Ustawia wartości IsRecoveryMode() == true i ForceNormalBoot() == false.
   2. Ładuje moduły jądra dostawcy z adresu /lib/modules.
   3. wywołuje DoFirstStageMount(), ale pomija montowanie, ponieważ IsRecoveryMode() == true. (Urządzenie nie zwalnia pamięci ramdisk (ponieważ / jest nadal taki sam), ale wywołuje funkcję SetInitAvbVersionInRecovery()).
   4. Rozpoczyna się drugi etap inicjalizacji z poziomu /system/bin/init na dysku RAM recovery.

Sygnatury czasowe obrazu rozruchowego

Poniżej znajduje się 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

• Podczas kompilacji do ogólnego pliku pamięci RAM jest dodawany plik system/etc/ramdisk/build.prop. Ten plik zawiera informacje o sygnaturze czasowej kompilacji.

• W czasie działania pierwszego etapu init kopiuje pliki z pamięci RAM do tmpfs, a następnie zwalnia pamięć RAM, aby drugi etap init mógł odczytać ten plik w celu ustawienia właściwości sygnatury czasowej obrazu boot.