Ogólna partycja rozruchowa

W systemie Android 12 ogólny obraz boot , określany jako Generic Kernel Image (GKI) , zawiera ogólny ramdysk i jądro GKI.

W przypadku urządzeń uruchamianych z systemem Android 13 ogólny ramdysk jest usuwany z obrazu boot i umieszczany w osobnym obrazie init_boot . Ta zmiana pozostawia obraz boot tylko z jądrem GKI.

W przypadku uaktualniania urządzeń, które nadal korzystają z systemu Android 12 lub starszych wersji jądra, ogólny ramdysk pozostaje tam, gdzie był, bez konieczności tworzenia nowego obrazu init_boot .

Aby zbudować ogólny ramdysk, przenieś zasoby specyficzne dla dostawcy poza ramdysk, tak aby ogólny ramdysk zawierał tylko init pierwszego etapu i plik właściwości, który zawiera informacje o znaczniku czasu.

Na urządzeniach, które:

  • Nie używaj dedykowanej partycji recovery , wszystkie bity odzyskiwania są przenoszone z ogólnego ramdysku do ramdysku vendor_boot .

  • Należy używać dedykowanej partycji recovery , nie ma potrzeby wprowadzania zmian w ramdysku recovery , ponieważ ramdysk recovery jest samowystarczalny.

Architektura

Poniższe diagramy ilustrują architekturę urządzeń z systemem Android 12 lub nowszym. Urządzenie uruchamiane z systemem Android 13 ma nowy obraz init_boot zawierający ogólny ramdysk. Urządzenia aktualizowane z Androida 12 na Androida 13 korzystają z tej samej architektury, co w przypadku Androida 12.

Uruchom z Androidem 13, bez dedykowanego odzyskiwania

Uruchom/uaktualnij urządzenie, GKI, brak dedykowanego odzyskiwania

Rysunek 1. Urządzenia uruchamiające się lub aktualizujące do Androida 13, z GKI, bez dedykowanego odzyskiwania

Uruchom z Androidem 13, dedykowanym odzyskiwaniem i A/B (dedykowany ramdysk)

Uruchom/uaktualnij urządzenie, GKI, dedykowane i odzyskiwanie A/B

Rysunek 2. Urządzenia uruchamiające się lub aktualizujące do Androida 13, z GKI, dedykowanym i odzyskiwaniem A/B

Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycje recovery_a i recovery_b .

Uruchom z systemem Android 13, odzyskiwaniem dedykowanym i innym niż A/B (dedykowany ramdysk)

Uruchom/uaktualnij urządzenie, GKI, dedykowane i inne niż A/B odzyskiwanie

Rysunek 3. Urządzenia uruchamiające się lub aktualizujące do Androida 13, z GKI, dedykowanym i innym niż A/B odzyskiwaniem

Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycję o nazwie recovery bez przyrostka gniazda.

Uruchom lub zaktualizuj do Androida 12, bez dedykowanego odzyskiwania

Uruchom/uaktualnij urządzenie, GKI, brak dedykowanego odzyskiwania

Rysunek 4. Urządzenia uruchamiające się lub aktualizujące do Androida 12, z GKI, bez dedykowanego odzyskiwania

Uruchom lub zaktualizuj do Androida 12, dedykowane odzyskiwanie i A/B (dedykowany ramdysk)

Uruchom/uaktualnij urządzenie, GKI, dedykowane i odzyskiwanie A/B

Rysunek 5. Urządzenia uruchamiające się lub aktualizujące do Androida 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, dedykowane i inne niż A/B odzyskiwanie (dedykowany ramdysk)

Uruchom/uaktualnij urządzenie, GKI, dedykowane i inne niż A/B odzyskiwanie

Rysunek 6. Urządzenia uruchamiające się lub aktualizujące do Androida 12, z GKI, dedykowanym i innym niż A/B odzyskiwaniem

Zapoznaj się z tym rysunkiem, jeśli urządzenie ma partycję o nazwie recovery bez przyrostka gniazda.

Uaktualnij do Androida 12, odzyskiwanie jako rozruch (odzyskiwanie jako ramdisk)

Uruchom/uaktualnij urządzenie, bez GKI, odzyskiwanie jako rozruch

Rysunek 7. Aktualizacja urządzeń do Androida 12, bez GKI, odzyskiwanie jako rozruch

Uaktualnij do Androida 12, dedykowane odzyskiwanie (dedykowany ramdysk)

Uruchom/uaktualnij urządzenie, bez GKI, dedykowane odzyskiwanie

Rysunek 8. Aktualizacja urządzeń do Androida 12, bez GKI, dedykowane odzyskiwanie

Zawartość obrazów rozruchowych

Obrazy rozruchowe systemu Android zawierają następujące elementy.

  • Dodany obraz init_boot dla urządzeń uruchamianych z systemem Android 13

    • Wersja nagłówka V4
    • Ogólny obraz ramdysku

  • Ogólny obraz boot

    • Wersja nagłówka V3 lub V4
      • boot_signature dla certyfikacji GKI boot.img (tylko v4). Certyfikowany plik boot.img nie jest podpisany w celu zweryfikowania rozruchu. Producenci OEM muszą nadal podpisywać wstępnie utworzony boot.img kluczem AVB specyficznym dla urządzenia.
      • Ogólna cmdline poleceń ( GENERIC_KERNEL_CMDLINE )
      • Jądro GKI
    • Ogólny obraz ramdysku
      • Zawarte tylko w obrazach boot Android 12 i wcześniejszych

  • obraz vendor_boot (aby uzyskać szczegółowe informacje, zobacz Partycje rozruchowe dostawcy )

    • nagłówek vendor_boot
      • BOARD_KERNEL_CMDLINE cmdline
    • obraz ramdysku vendor_boot
      • lib/modules
      • Zasoby odzyskiwania (jeśli nie ma dedykowanego odzyskiwania)
    • obraz dtb

  • 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:
      • Polecenie cmdline nie jest połączone z poleceniem boot i vendor_boot cmdline .
      • Nagłówek określa odzyskiwanie DTBO, jeśli to konieczne.
      • W przypadku partycji odzyskiwania A/B zawartość może być łączona lub wywnioskowana na podstawie boot i vendor_boot . Na przykład:
      • Polecenie cmdline jest połączone z poleceniem boot i vendor_boot cmdline .
      • DTBO można wywnioskować z nagłówka vendor_boot .
    • recovery obrazu ramdysku
      • 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 poprzedzony ramdyskiem generic i vendor_boot , dlatego nie musi być samodzielny. Na przykład:
      • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do trybu odzyskiwania systemu, poza modułami jądra w ramdysku vendor_boot .
      • Dowiązanie symboliczne w /init może istnieć, ale jest przyćmione przez plik binarny /init pierwszego etapu w obrazie rozruchowym.

Ogólna zawartość obrazu ramdysku

Ogólny ramdysk zawiera następujące składniki.

  • init
  • Dodano system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build rekwizytów
  • 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/

Integracja obrazu rozruchowego

Flagi kompilacji kontrolują sposób init_boot , boot , recovery i vendor_boot . Wartość zmiennej tablicy logicznej musi być ciągiem true lub być pusta (co jest wartością domyślną).

  • TARGET_NO_KERNEL . Ta zmienna wskazuje, czy kompilacja korzysta z gotowego obrazu rozruchowego. Jeśli ta zmienna ma wartość true , ustaw BOARD_PREBUILT_BOOTIMAGE na lokalizację gotowego 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 . Podczas korzystania z GKI ta zmienna jest pusta i zasoby odzyskiwania należy przenieść do vendor_boot .

  • BOARD_USES_GENERIC_KERNEL_IMAGE . Ta zmienna wskazuje, że płyta używa GKI. Ta zmienna nie wpływa na sysprops ani na PRODUCT_PACKAGES .

    To jest przełącznik GKI na poziomie płyty; wszystkie wymienione poniżej zmienne są ograniczone przez tę zmienną.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . Ta zmienna kontroluje, czy zasoby odzyskiwania ramdysku są zbudowane na vendor_boot .

    • Gdy ustawione na true , zasoby odzyskiwania są budowane tylko na vendor-ramdisk/ , a nie na recovery/root/ .

    • Gdy jest pusty, zasoby odzyskiwania są zbudowane tylko do recovery/root/ , a nie do vendor-ramdisk/ .

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . Ta zmienna kontroluje, czy klucze GSI AVB są tworzone dla vendor_boot .

    • Po ustawieniu na true , jeśli BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • Jest ustawione, klucze GSI AVB są budowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb .

      • Nie jest ustawiona, klucze GSI AVB są tworzone na $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb .

    • Gdy jest pusty, jeśli BOARD_RECOVERY_AS_ROOT :

      • Jest ustawione, klucze GSI AVB są zbudowane na $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb .

      • Nie jest ustawiona, klucze GSI AVB są zbudowane w $ANDROID_PRODUCT_OUT/ramdisk/avb .

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . Ta zmienna kontroluje, czy obraz recovery zawiera jądro, czy nie. Urządzenia uruchamiane z systemem Android 12 i korzystające z partycji recovery A/B muszą ustawić tę zmienną na true . Urządzenia uruchamiane z systemem Android 12 i korzystające z systemów innych niż A/B muszą ustawić tę zmienną na wartość false , aby zachować samodzielność obrazu odzyskiwania.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . Ta zmienna kontroluje, czy $OUT/boot*.img jest kopiowany do IMAGES/ pod plikami docelowymi.

    • aosp_arm64 musi ustawić tę zmienną na true .

    • Inne urządzenia muszą pozostawić tę zmienną pustą.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE . Ta zmienna kontroluje, czy init_boot.img jest generowany i ustawia rozmiar. Po ustawieniu ogólny ramdysk jest dodawany do init_boot.img zamiast boot.img i wymaga ustawienia zmiennych BOARD_AVB_INIT_BOOT* dla połączonego vbmeta

Dozwolone kombinacje

Składnik lub zmienna Aktualizacja urządzenia bez partycji recovery Aktualizacja urządzenia z partycją recovery Uruchom urządzenie bez partycji recovery Uruchom urządzenie z partycją recovery A/B Uruchom urządzenie z partycją recovery innej niż A/B aosp_arm64
Zawiera boot tak tak tak tak tak tak
Zawiera init_boot (Android 13) nie nie nie 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 czy pusta pusty true czy pusta true czy pusta 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ć dla PRODUCT_BUILD_RECOVERY_IMAGE wartość true lub pustą. W przypadku tych urządzeń, jeśli ustawiono BOARD_RECOVERYIMAGE_PARTITION_SIZE , tworzony jest obraz recovery .

Włącz połączoną vbmetę do rozruchu

Połączona vbmeta musi być włączona dla obrazów boot i init_boot . Określ następujące elementy:

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

Aby zapoznać się z przykładem, zapoznaj się z tą zmianą .

System jako root

System jako root nie jest obsługiwany w przypadku urządzeń korzystających z GKI. Na takich urządzeniach BOARD_BUILD_SYSTEM_ROOT_IMAGE musi być puste. System jako główny 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ć zainstalowane na ramdysku. Aby to zrobić, określ następujące dane 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 (przenieś takie pliki do vendor_ramdisk ).

Konfigurowanie urządzeń

Instrukcje konfiguracji różnią się w zależności od urządzeń uruchamianych z systemem Android 13, aktualizowanych do systemu Android 12 i uruchamianych z systemem Android 12. System Android 13 jest skonfigurowany podobnie jak w przypadku systemu Android 12

  • Aktualizacja urządzeń do Androida 12:

    • Może zachować wartość BOARD_USES_RECOVERY_AS_BOOT . Jeśli to zrobią, używają starszych konfiguracji, a nowe zmienne kompilacji muszą być puste. Jeśli takie urządzenia:

      • Ustaw BOARD_USES_RECOVERY_AS_BOOT na true , architektura jest taka jak na rysunku 3 .

      • Ustaw BOARD_USES_RECOVERY_AS_BOOT na pustą, architektura jest taka, jak pokazano na rysunku 4 .

    • Można ustawić BOARD_USES_RECOVERY_AS_BOOT na pustą. Jeśli to zrobią, 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 pokazana na Rysunku 2a lub Rysunku 2b , a opcja konfiguracji urządzenia to Opcja 2a lub Opcja 2b .

  • Urządzenia uruchamiane z Androidem 12 muszą ustawić BOARD_USES_RECOVERY_AS_BOOT na puste i używać 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 pokazana na Rysunku 2a lub Rysunku 2b , a opcja konfiguracji urządzenia to Opcja 2a lub Opcja 2b .

Ponieważ aosp_arm64 buduje tylko GKI (a nie vendor_boot ani recovery), nie jest kompletnym celem. W przypadku konfiguracji 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 . 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

vendor_boot może zawierać dowiązanie symboliczne /init do /system/bin/init oraz init_second_stage.recovery w /system/bin/init . Jednakże, ponieważ 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 inicjowania drugiego etapu. Zawartość vendor_boot + ramdysk generycznych jest następująca:

  • /init (z ogólnego ramdysku, zbudowany z init_first_stage )
  • /system/bin/init (z vendor_ramdisk , zbudowany z init_second_stage.recovery )

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab na ogólny ramdysk do vendor_ramdisk . Aby zapoznać się z przykładem, zapoznaj się z tą zmianą .

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 modułu vendor_ramdisk , gdy moduł jest instalowany na /first_stage_ramdisk . Ten moduł powinien być dostępny po tym, jak init przełączy roota na /first_stage_ramdisk ale zanim init 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 / . Ten moduł powinien być dostępny, zanim init 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ę, zanim init przełączy root na /first_stage_ramdisk , musisz zainstalować moduły w wariancie recovery . Domyślnie oba warianty modułów są instalowane w build/make/target/product/base_vendor.mk , więc jeśli urządzenie makefile dziedziczy z tego pliku, nie musisz 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 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 dla konsoli pierwszego stopnia (na przykład adbd), użyj następującego.

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 pod vendor_ramdisk .

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, 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 \

Aby zapoznać się z przykładem, zapoznaj się z tą listą zmian .

Wirtualna kompresja A/B

Aby obsługiwać wirtualną kompresję A/B, snapuserd musi być zainstalowany na vendor_ramdisk . Urządzenie powinno dziedziczyć po virtual_ab_ota/compression.mk , który instaluje wariant vendor_ramdisk snapuserd .

Zmiany w procesie rozruchu

Proces uruchamiania do odzyskiwania lub do Androida nie zmienia się, z następującym wyjątkiem:

  • build.prop przenosi się do /second_stage_resources , aby init drugiego etapu mógł odczytać sygnaturę czasową kompilacji rozruchu.

Ponieważ zasoby są przenoszone z ogólnego ramdysku do ramdysku vendor_boot , wynik połączenia ogólnego ramdysku z vendor_boot nie ulega zmianie.

Udostępnianie e2fsck

Pliki makefile urządzenia mogą dziedziczyć z:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk , jeśli urządzenie obsługuje wirtualny 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 init pierwszego etapu przełącza root na /first_stage_ramdisk a następnie wykonuje /system/bin/e2fsck .

Opcja 2a: Dedykowana i partycja odzyskiwania A/B

Użyj tej opcji w przypadku urządzeń z partycjami recovery A/B; oznacza to, że urządzenie ma recovery_b partition recovery_a i recovery_b . Do takich urządzeń należą urządzenia A/B i Virtual A/B, których partycję odzyskiwania można aktualizować, o następującej konfiguracji:

AB_OTA_PARTITIONS += recovery

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)

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

Ramdysk recovery może zawierać dowiązanie symboliczne /init -> /system/bin/init oraz init_second_stage.recovery w /system/bin/init . Jednak ponieważ ramdysk rozruchowy jest łączony po ramdysku 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 inicjowania drugiego etapu.

Gdy urządzenie uruchamia się w trybie recovery , zawartość recovery + vendor_boot + ogólnych ramdysków jest następująca:

  • /init (z ramdysku, zbudowany z init_first_stage )
  • /system/bin/init (z ramdysku recovery , zbudowany z init_second_stage.recovery i wykonany z /init )

Gdy urządzenie uruchamia się w systemie Android, zawartość vendor_boot + generycznych ramdysków wygląda następująco:

  • /init (z ogólnego ramdysku, zbudowany z init_first_stage )

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab na ogólny ramdysk do vendor_ramdisk . Aby zapoznać się z przykładem, zapoznaj się z tą zmianą .

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 przełącza roota. Wariant modułów vendor_ramdisk jest instalowany w katalogu głównym vendor_ramdisk . Aby zapoznać się z przykładami instalowania modułów na vendor_ramdisk , zobacz Konsola pierwszego stopnia , Sumy kontrolne metadanych i Wirtualna kompresja A/B .

Konsola pierwszego stopnia

Aby zainstalować wariant vendor_ramdisk , użyj następujących poleceń:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Gwarantuje to, że linker , sh i toybox 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 dla konsoli pierwszego stopnia (na przykład adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie użyj następujących:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Zapewnia to, że 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 trybie recovery . Jeśli ramdysk vendor_boot nie jest załadowany w trybie odzyskiwania, urządzenie może opcjonalnie zainstalować również adbd.recovery .

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, 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 zapoznać się z przykładem, zapoznaj się z tą listą zmian .

Wirtualna kompresja A/B

Aby obsługiwać kompresję Virtual A/B, snapuserd musi być zainstalowany na vendor_ramdisk . Urządzenie powinno dziedziczyć po 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 go jako normalny rozruch.

Podczas uruchamiania w trybie odzyskiwania zmienia się proces uruchamiania. 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 rozruchu w trybie odzyskiwania jest następujący.

  1. Bootloader uruchamia się, a następnie wykonuje następujące czynności:

    1. Wypycha odzyskiwanie + vendor_boot + ogólny ramdysk do / . (Jeśli producent OEM duplikuje moduły jądra w ramdysku odzyskiwania, dodając je do BOARD_RECOVERY_KERNEL_MODULES ), vendor_boot jest opcjonalny.
    2. Uruchamia jądro z partycji boot .

  2. Kernel montuje ramdysk do / , a następnie wykonuje /init z ogólnego ramdysku.

  3. Rozpoczyna się pierwszy etap init, a następnie wykonuje następujące czynności:

    1. Ustawia IsRecoveryMode() == true i ForceNormalBoot() == false .
    2. Ładuje moduły jądra dostawcy z /lib/modules .
    3. Wywołuje DoFirstStageMount() ale pomija montowanie, ponieważ IsRecoveryMode() == true . (Urządzenie nie zwalnia ramdysku (ponieważ / jest nadal takie samo), ale wywołuje SetInitAvbVersionInRecovery() .)
    4. Uruchamia init drugiego etapu z /system/bin/init z dysku recovery .

Udostępnianie e2fsck

Pliki makefile urządzenia mogą dziedziczyć z:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk , jeśli urządzenie obsługuje wirtualny 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 init pierwszego etapu wykonuje /system/bin/e2fsck .

Opcja 2b: Dedykowana i nie-A/B partycja odzyskiwania

Użyj tej opcji w przypadku urządzeń z partycją recovery innej niż A/B; oznacza to, że urządzenie ma partycję o nazwie recovery bez sufiksu gniazda. Takie urządzenia obejmują:

  • urządzenia inne niż A/B;
  • Urządzenia A/B i Virtual A/B, których partycji odzyskiwania nie można aktualizować. (To niezwykłe.)

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
  • Binarny init drugiego stopnia /system/bin/init
  • Pliki fstab specyficzne dla urządzenia
  • Wszystkie inne zasoby odzyskiwania, w tym plik binarny recovery itp.
  • itp.

Na takich urządzeniach konfiguracja produktu dziedziczy z generic_ramdisk.mk .

Ustawianie wartości BOARD

Ustaw następujące wartości dla urządzeń innych niż A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Ramdysk recovery musi zawierać dowiązanie symboliczne /init -> /system/bin/init oraz 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 inicjowania zarówno pierwszego, jak i drugiego etapu.

Gdy urządzenie uruchamia się w trybie recovery , zawartość ramdysków recovery jest następująca:

  • /init -> /system/bin/init (z dysku recovery )
  • /system/bin/init (z ramdysku recovery , zbudowany z init_second_stage.recovery i wykonany z /init )

Gdy urządzenie uruchamia się w systemie Android, zawartość vendor_boot + generycznych ramdysków wygląda następująco:

  • /init (z ramdysku, zbudowany z init_first_stage )

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab na ogólny ramdysk na vendor_ramdisk i ramdysk recovery . Aby zapoznać się z przykładem, zapoznaj się z tą zmianą .

Instalowanie modułów

Jeśli chcesz, możesz zainstalować moduły specyficzne dla urządzenia na vendor_ramdisk i ramdysku recovery (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). init nie przełącza roota. Wariant modułów vendor_ramdisk jest instalowany w katalogu głównym vendor_ramdisk . Wariant recovery modułów jest instalowany w katalogu głównym ramdysku recovery . Przykłady instalacji modułów na vendor_ramdisk i ramdysku recovery znajdują się w sekcji Konsola pierwszego stopnia i Sumy kontrolne metadanych .

Konsola pierwszego stopnia

Aby zainstalować wariant vendor_ramdisk , użyj następujących poleceń:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Gwarantuje to, że linker , sh i toybox 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 dla konsoli pierwszego stopnia (na przykład adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie użyj następujących:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Zapewnia to, że określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin .

Aby zainstalować wariant recovery modułów, zamień vendor_ramdisk na recovery :

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

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia, 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 w odzyskiwaniu, 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 go jako normalny rozruch.

Podczas uruchamiania w trybie odzyskiwania proces uruchamiania się nie zmienia. Ramdysk odzyskiwania jest ładowany w taki sam sposób, jak istniejący proces odzyskiwania. Jądro jest ładowane z obrazu recovery . Proces rozruchu w trybie odzyskiwania jest następujący.

  1. Bootloader uruchamia się, a następnie wykonuje następujące czynności:

    1. Wypycha ramdysk odzyskiwania do / .
    2. Uruchamia jądro z partycji recovery .

  2. Kernel montuje ramdysk do / , a następnie wykonuje /init , który jest dowiązaniem symbolicznym do /system/bin/init z ramdysku recovery .

  3. Rozpoczyna się pierwszy etap init, a następnie wykonuje następujące czynności:

    1. Ustawia IsRecoveryMode() == true i ForceNormalBoot() == false .
    2. Ładuje moduły jądra dostawcy z /lib/modules .
    3. Wywołuje DoFirstStageMount() ale pomija montowanie, ponieważ IsRecoveryMode() == true . (Urządzenie nie zwalnia ramdysku (ponieważ / jest nadal takie samo), ale wywołuje SetInitAvbVersionInRecovery() .)
    4. Uruchamia init drugiego etapu z /system/bin/init z dysku recovery .

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 init pierwszego etapu kopiuje pliki z ramdysku do tmpfs przed zwolnieniem ramdysku, tak aby init drugiego etapu mógł odczytać ten plik i ustawić właściwości znacznika czasu obrazu boot .