Ogólna partycja rozruchowa

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 osobnego 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 pierwszy etap init i plik usługi z informacjami 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 specjalnego odzyskiwania

Uruchomienie/modernizacja urządzenia, GKI, brak dedykowanego odzyskiwania

Rysunek 1. Urządzenia uruchamiające lub aktualizujące Androida 13 z Google Play jako interfejsem graficznym, bez dedykowanego narzędzia do przywracania.

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

Uruchomienie/uaktualnienie urządzenia, GKI, odzyskiwanie w trybie dedykowanym i A/B

Rysunek 2. Urządzenia z Androidem 13, które są uruchamiane lub aktualizowane z użyciem GKI, przywracania dedykowanego i A/B.

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

Wprowadzenie Androida 13, specjalnego trybu odzyskiwania (specjalny dysk RAM) i odzyskiwania A/B.

Uruchomienie/uaktualnienie urządzenia, GKI, odzyskiwanie w trybie dedykowanym i niestandardowym (nie A/B)

Rysunek 3. Urządzenia z Androidem 13, które korzystają z interfejsu GKI i specjalnego odzyskiwania, z lub bez odzyskiwania 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

Uruchomienie/modernizacja urządzenia, GKI, brak dedykowanego odzyskiwania

Rysunek 4. Urządzenia uruchamiające Androida 12 lub przechodzące na niego z użyciem GKI, bez dedykowanego odzyskiwania.

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

Uruchomienie/uaktualnienie urządzenia, GKI, odzyskiwanie w trybie dedykowanym i A/B

Rysunek 5. Urządzenia z Androidem 12, które są uruchamiane lub aktualizowane do tej wersji z użyciem GKI, przywracania dedykowanego lub A/B.

Jeśli urządzenie ma partycje recovery_a i recovery_b, zapoznaj się z tą ilustracją.

uruchomić lub uaktualnić Androida 12, dedykowane i niestandardowe środowisko odzyskiwania (dedykowany dysk RAM);

Uruchomienie/uaktualnienie urządzenia, GKI, odzyskiwanie w trybie dedykowanym i niestandardowym (nie 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)

Uruchomienie/uaktualnienie urządzenia bez GKI, tryb odzyskiwania jako tryb uruchamiania

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

Uaktualnienie do Androida 12, dedykowany tryb odzyskiwania (dedykowany ramdisk)

Uruchomienie/uaktualnienie urządzenia, bez GKI, specjalne odzyskiwanie

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

Zawartość obrazów rozruchowych

Obrazy rozruchowe Androida zawierają:

  • init_boot obraz dodany 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 do 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
      • Dostępne tylko w przypadku 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
      • Dane dotyczące urządzenia cmdline (w razie potrzeby)
      • 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 razie potrzeby nagłówek określa DTBO odzyskiwania.
      • W przypadku partycji odzyskiwania A/B treści mogą być łączone lub wywnioskowane z poziomów boot i vendor_boot. Przykład:
      • Wartość cmdline jest złączana z wartościami boot i vendor_boot cmdline.
      • DTBO można określić na podstawie nagłówka vendor_boot.
    • recovery obraz dysku RAM
      • Zasoby dotyczące 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 uruchomienia 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 rozruchowego. 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 wymienione niżej 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 komponencie vendor_boot.

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

    • Jeśli jest pusty, 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.

    • Jeśli ustawienie to true, a 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 jądro. 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

Komponent lub zmienna Modernizacja urządzenia bez partycji odzyskiwania Uaktualnianie urządzenia z partycją odzyskiwania Uruchamianie urządzenia bez partycji odzyskiwania Uruchomienie urządzenia z partycją odzyskiwania A/B Uruchamianie urządzenia z partycją odzyskiwania inną niż A/B aosp_arm64
Zawiera: boot tak tak tak tak tak tak
zawiera init_boot (Android 13) no no tak tak tak tak
Zawiera: vendor_boot opcjonalne opcjonalne tak tak tak no
Zawiera: recovery no tak no tak tak no
BOARD_USES_RECOVERY_AS_BOOT true pusta pusta pusta pusta pusta
BOARD_USES_GENERIC_KERNEL_IMAGE pusta pusta true true true true
PRODUCT_BUILD_RECOVERY_IMAGE pusta true lub puste pusta true lub puste true lub puste pusta
BOARD_RECOVERYIMAGE_PARTITION_SIZE pusta > 0 pusta > 0 > 0 pusta
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT pusta pusta true pusta pusta pusta
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT pusta pusta true true true pusta
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE pusta pusta pusta true pusta pusta
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES pusta pusta pusta pusta pusta true

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

Tryb 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 korzystające 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ą skonfigurowane podobnie jak w Androidzie 12.

  • Urządzenia zaktualizowane 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 się stanie, oznacza to, że używają one 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 odzyskiwania), 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

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 generic ramdisk jest łączony po vendor_boot ramdisk, /initsymlink jest zastępowany. 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

Na urządzeniu vendor_ramdisk możesz zainstalować moduły specyficzne dla urządzenia (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 /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 recovery, recovery_a i 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 (zawiera 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

Dysk recovery może zawierać symboliczny link /init -> /system/bin/init i init_second_stage.recovery w /system/bin/init. Ponieważ jednak dysk rozruchowy w pamięci RAM jest łączony po dysku ramowym recovery, łącznik symboliczny /init zostaje nadpisany. 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 + genericzne dyski RAM wygląda tak:

  • /init (z dysku RAM, 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 związane z danym urządzeniem (pomiń ten krok, jeśli nie masz żadnych takich modułów). Initnie przełącza roota. Wersja vendor_ramdisk modułów jest instalowana w pliku 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 + genericzna pamięć RAM jest podobna do obecnego procesu uruchamiania, z tym ż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 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 pliku 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 bez partycji A/B, czyli z partycją o nazwie recovery bez sufiksu slotu. Takie urządzenia to:

  • 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 (zawiera moduły jądra dostawcy)

Obraz recovery musi być kompletny. 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 /init -> /system/bin/init
  • Drugoetapowa kompilacja binarna inicjalizacji /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

Dysk recovery musi zawierać symboliczny link /init -> /system/bin/init i 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 dysku RAM, 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 dyskach RAM vendor_ramdisk i recovery możesz instalować moduły przeznaczone dla konkretnych urządzeń (pomiń ten krok, jeśli nie musisz instalować żadnych modułów). initnie przełącza roota. Wersja vendor_ramdisk modułów jest instalowana w pliku głównym vendor_ramdisk. Wersja recovery modułów jest instalowana 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 + genericzna pamięć RAM jest podobna do dotychczasowego procesu uruchamiania, z tym ż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 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.