Ogólna partycja rozruchu

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

W przypadku urządzeń z Androidem 13 ogólny dysk RAM jest usuwany z obrazu boot i umieszczany w osobnym obrazie init_boot. Po tej zmianie obraz boot będzie zawierać tylko jądro GKI.

W przypadku urządzeń, które nadal korzystają z Androida 12 lub starszych wersji jądra, ogólny dysk RAM pozostaje w tym samym miejscu i nie wymaga nowego obrazu init_boot.

Aby utworzyć ogólny dysk RAM, przenieś zasoby specyficzne dla dostawcy z dysku RAM, tak aby zawierał on tylko pierwszy etap init i plik właściwości zawierający informacje o sygnaturze czasowej.

Na urządzeniach, które:

• Nie używaj dedykowanej partycji recovery. Wszystkie bity odzyskiwania są przenoszone z ogólnego dysku RAM do dysku RAM vendor_boot.

• Użyj dedykowanej partycji recovery. Nie musisz wprowadzać zmian w recovery ramdisk, ponieważ recovery ramdisk jest samodzielny.

Architektura

Poniższe diagramy ilustrują 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 przypadku Androida 12.

Wprowadzenie na rynek z Androidem 13, bez dedykowanego odzyskiwania

Rysunek 1. Urządzenia wprowadzane na rynek lub aktualizowane do Androida 13 z GKI bez dedykowanego trybu odzyskiwania.

Wprowadzenie na rynek z Androidem 13, dedykowane i A/B odzyskiwanie (dedykowany dysk RAM)

Rysunek 2. Urządzenia, na których wprowadzono Androida 13 lub na których zaktualizowano system do tej wersji, z GKI, dedykowanym i A/B recovery.

Jeśli urządzenie ma partycje recovery_a i recovery_b, skorzystaj z tego rysunku.

Wprowadzenie na rynek z Androidem 13, dedykowane i niededykowane odzyskiwanie A/B (dedykowany dysk RAM)

Rysunek 3. Urządzenia, które są wprowadzane na rynek lub aktualizowane do Androida 13, z GKI, dedykowanym i nie-A/B trybem odzyskiwania.

Skorzystaj z tego rysunku, jeśli urządzenie ma partycję o nazwie recovery bez sufiksu gniazda.

Wprowadzenie na rynek lub aktualizacja do Androida 12 bez dedykowanego trybu odzyskiwania

Rysunek 4. Urządzenia wprowadzane na rynek lub aktualizowane do Androida 12 z GKI bez dedykowanego trybu odzyskiwania.

Uruchamianie Androida 12 lub uaktualnianie do niego, dedykowane i A/B odzyskiwanie (dedykowany ramdysk)

Rysunek 5. Urządzenia, które są wprowadzane na rynek lub aktualizowane do Androida 12, z GKI, dedykowanym i A/B recovery.

Jeśli urządzenie ma partycje recovery_a i recovery_b, skorzystaj z tego rysunku.

Uruchamianie Androida 12 lub przechodzenie na niego, dedykowane i niededykowane przywracanie systemu A/B (dedykowany dysk RAM)

Rysunek 6. Urządzenia, które są wprowadzane na rynek lub aktualizowane do Androida 12, z GKI, dedykowanym i nie-A/B trybem odzyskiwania.

Skorzystaj z tego rysunku, jeśli urządzenie ma partycję o nazwie recovery bez sufiksu gniazda.

Uaktualnianie do Androida 12, recovery-as-boot (recovery-as-ramdisk)

Rysunek 7. Urządzenia, które przechodzą na Androida 12, bez GKI, z trybem recovery jako rozruchem.

Uaktualnienie do Androida 12, dedykowane odzyskiwanie (dedykowany ramdysk)

Rysunek 8. Urządzenia, które przechodzą na Androida 12, bez GKI, z dedykowanym trybem odzyskiwania.

Zawartość obrazów rozruchowych

Obrazy rozruchowe Androida zawierają:

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

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

• Ogólny boot obraz

  • Wersja nagłówka V3 lub V4.
    • boot_signature – certyfikat pliku boot.img GKI (tylko w wersji 4). Certyfikowany GKI boot.img nie jest podpisany na potrzeby weryfikacji podczas uruchamiania. Producenci OEM muszą nadal podpisywać wstępnie skompilowany plik boot.img za pomocą klucza AVB dostosowanego do urządzenia.
    • Ogólne cmdline (GENERIC_KERNEL_CMDLINE)
    • Jądro GKI
  • Ogólny obraz dysku RAM
    • Dotyczy tylko boot zdjęć z Androida 12 i starszych wersji

• vendor_boot image (szczegółowe informacje znajdziesz w sekcji Partycje rozruchowe dostawcy)

  • vendor_boot header
    • cmdline na urządzeniu (BOARD_KERNEL_CMDLINE)
  • vendor_boot obraz dysku RAM
    • lib/modules
    • Zasoby odzyskiwania (jeśli nie ma dedykowanego odzyskiwania)
  • dtb obraz

• recovery obraz

  • Wersja nagłówka V2
    • W razie potrzeby cmdline specyficzne dla urządzenia
    • W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielna. Więcej informacji znajdziesz w sekcji Obrazy odzyskiwania. Na przykład:
    • Adres cmdline nie jest połączony z adresami boot i vendor_boot cmdline.
    • Nagłówek określa w razie potrzeby DTBO odzyskiwania.
    • W przypadku partycji odzyskiwania A/B zawartość można łączyć lub wywnioskować z boot i vendor_boot. Na przykład:
    • cmdline jest połączony z boot i vendor_boot cmdline.
    • DTBO można wywnioskować z 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. Więcej informacji znajdziesz w sekcji Obrazy odzyskiwania. Na przykład:
    • lib/modules musi zawierać wszystkie moduły jądra wymagane do uruchomienia trybu odzyskiwania.
    • Dysk RAM do przywracania musi zawierać init.
    • W przypadku partycji odzyskiwania A/B dysk RAM odzyskiwania jest dodawany na początku dysku RAM ogólnego i vendor_boot, więc nie musi być samodzielny. Na przykład:
    • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do uruchomienia trybu odzyskiwania, oprócz modułów jądra w vendor_boot ramdisk.
    • Symlink w /init może istnieć, ale jest przyćmiony przez binarny plik /init pierwszego etapu w obrazie rozruchowym.

Zawartość ogólnego obrazu dysku RAM

Ogólny dysk RAM zawiera te komponenty:

• init
• system/etc/ramdisk/build.prop
• ro.PRODUCT.bootimg.* build rekwizyty
• 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 określają sposób tworzenia obrazów init_boot, boot, recovery i vendor_boot. Wartością zmiennej logicznej tablicy musi być ciąg znaków true lub wartość pusta (domyślna).

• 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ę 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. W przypadku GKI ta zmienna jest pusta, a zasoby przywracania należy przenieść do vendor_boot.

• BOARD_USES_GENERIC_KERNEL_IMAGE. Ta zmienna wskazuje, że płyta korzysta z GKI. Ta zmienna nie ma wpływu na właściwości systemowe ani na PRODUCT_PACKAGES.

  Jest to przełącznik GKI na poziomie płyty. Wszystkie poniższe zmienne są ograniczone przez tę zmienną.

• BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Ta zmienna określa, czy zasoby odzyskiwania ramdysku są tworzone w vendor_boot.

  • Jeśli ta opcja jest ustawiona na true, zasoby odzyskiwania są tworzone tylko w przypadku vendor-ramdisk/, a nie w przypadku recovery/root/.

  • Jeśli to pole jest puste, zasoby odzyskiwania są tworzone tylko dla recovery/root/, a nie dla 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 ustawisz true, a BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

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

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

  • Gdy jest pusta, jeśli BOARD_RECOVERY_AS_ROOT:

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

    • Jeśli nie jest ustawiony, klucze GSI AVB są tworzone w celu $ANDROID_PRODUCT_OUT/ramdisk/avb.

• BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Ta zmienna określa, czy obraz recovery zawiera jądro. Urządzenia z Androidem 12 i partycją A/B recovery muszą ustawić tę zmienną na true. Urządzenia z Androidem 12, które nie korzystają z aktualizacji A/B, muszą ustawić tę zmienną na false, aby obraz odzyskiwania był samodzielny.

• BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Ta zmienna określa, czy $OUT/boot*.img jest kopiowany do IMAGES/ w plikach docelowych.

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

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

• BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Ta zmienna określa, czy ma być generowany element init_boot.img, i ustawia jego rozmiar. Po ustawieniu ogólny dysk RAM jest dodawany do init_boot.img zamiast do boot.img i wymaga ustawienia zmiennych BOARD_AVB_INIT_BOOT* na potrzeby połączonego pliku vbmeta.

Dozwolone kombinacje

Urządzenia z wydzieloną partycją recovery mogą ustawić wartość PRODUCT_BUILD_RECOVERY_IMAGE na true lub pozostawić ją pustą. W przypadku tych urządzeń, jeśli ustawiona jest wartość BOARD_RECOVERYIMAGE_PARTITION_SIZE, tworzony jest obraz recovery.

Włączanie połączonych plików vbmeta na potrzeby rozruchu

W przypadku obrazów boot i init_boot musi być włączony łańcuchowy plik 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ład znajdziesz w tej zmianie.

System jako katalog główny

System-as-root nie jest obsługiwany na urządzeniach, które korzystają z GKI. Na takich urządzeniach pole BOARD_BUILD_SYSTEM_ROOT_IMAGE musi być puste. System-as-root nie jest też obsługiwany na urządzeniach, które korzystają z partycji dynamicznych.

Konfiguracje usług

Urządzenia korzystające z ogólnego dysku RAM muszą zainstalować listę plików, które mogą być instalowane na dysku RAM. Aby to zrobić, podaj te informacje w sekcjidevice.mk:

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

Plik generic_ramdisk.mk zapobiega też przypadkowemu instalowaniu innych plików na dysku RAM przez inne pliki makefile (przenieś takie pliki do vendor_ramdisk).

Konfigurowanie urządzeń

Instrukcje konfiguracji różnią się w zależności od tego, czy urządzenie jest dostarczane z Androidem 13, czy jest aktualizowane do Androida 12, czy jest dostarczane z Androidem 12. Androida 13, są konfigurowane podobnie jak w przypadku Androida 12.

• Urządzenia, które można zaktualizować do Androida 12:

  • Może zachować wartość BOARD_USES_RECOVERY_AS_BOOT. Jeśli tak 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, a architektura będzie taka jak na rysunku 3.

    • Ustaw wartość BOARD_USES_RECOVERY_AS_BOOT na pustą. Architektura będzie wyglądać jak na rysunku 4.

  • Można ustawić pustą wartość BOARD_USES_RECOVERY_AS_BOOT. W takim przypadku używają nowych konfiguracji. Jeśli takie urządzenia:

    • Nie używaj dedykowanej partycji recovery. Architektura jest taka jak 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 z Androidem 12 muszą mieć ustawioną pustą wartość parametru BOARD_USES_RECOVERY_AS_BOOT i korzystać z nowych konfiguracji. Jeśli takie urządzenia:

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

  • Użyj dedykowanej partycji recovery. Architektura jest pokazana na rysunku 2a lub rysunku 2b, a opcja konfiguracji urządzenia to opcja 2a lub opcja 2b.

Ponieważ aosp_arm64 tworzy tylko GKI (a nie vendor_boot ani odzyskiwanie), nie jest to pełny cel. Informacje o aosp_arm64konfiguracjach kompilacji znajdziesz w artykule generic_arm64.

Opcja 1. Brak dedykowanej partycji odzyskiwania

Urządzenia bez partycji recovery zawierają ogólny obraz boot na partycji boot. vendor_boot ramdysk zawiera wszystkie zasoby odzyskiwania, w tym lib/modules (z modułami jądra dostawcy). Na takich urządzeniach konfiguracja produktu dziedziczy 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

Inicjowanie plików binarnych i linków symbolicznych

Dysk RAM vendor_boot może zawierać dowiązanie symboliczne /init do /system/bin/init i init_second_stage.recovery w /system/bin/init. Jednak ponieważ ogólny dysk RAM jest łączony po dysku RAM vendor_boot, symlink /init jest zastępowany. Gdy urządzenie uruchamia się w trybie odzyskiwania, do obsługi inicjowania drugiego etapu potrzebny jest plik binarny /system/bin/init. Zawartość vendor_boot + ogólne dyski RAM jest następująca:

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

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab, które zostały zainstalowane na ogólnym dysku RAM, do folderu vendor_ramdisk. Przykład znajdziesz w tej zmianie.

Instalowanie modułów

Możesz zainstalować moduły specyficzne dla urządzenia vendor_ramdisk (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia).

• Użyj wariantu modułu vendor_ramdisk, gdy moduł jest instalowany w /first_stage_ramdisk. Ten moduł powinien być dostępny po tym, jak initprzełączy się na /first_stage_ramdisk, ale zanim initprzełączy się na /system. Przykłady znajdziesz w sekcjach Sumy kontrolne metadanych i Wirtualna kompresja testów A/B.

• Użyj wariantu modułu recovery, gdy moduł jest instalowany w lokalizacji /. Ten moduł powinien być dostępny, zanim init przełączy się na /first_stage_ramdisk. Szczegółowe informacje o instalowaniu modułów w / znajdziesz w artykule Konsola pierwszego etapu.

Konsola pierwszego etapu

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

Aby jawnie zainstalować moduły odzyskiwania, użyj tego polecenia.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Dzięki temu pakiety linker, sh i toybox zostaną zainstalowane w $ANDROID_PRODUCT_OUT/recovery/root/system/bin, a następnie w /system/bin w folderze vendor_ramdisk.

Aby dodać moduły potrzebne w konsoli pierwszego etapu (np. adbd), użyj tych poleceń:

PRODUCT_PACKAGES += adbd.recovery

Dzięki temu określone moduły zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/recovery/root/system/bin, który następnie zostanie zainstalowany w katalogu /system/bin w katalogu vendor_ramdisk.

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas podłączania w pierwszym etapie, urządzenia, które nie obsługują GKI, instalują wariant ramdysku tych modułów: Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

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

Przykład znajdziesz na tej liście zmian.

Wirtualna kompresja A/B

Aby obsługiwać wirtualną kompresję A/B, należy zainstalować snapuserd, aby vendor_ramdisk. Urządzenie powinno dziedziczyć z virtual_ab_ota/compression.mk, co spowoduje zainstalowanie wariantu vendor_ramdisk aplikacji snapuserd.

Zmiany w procesie rozruchu

Proces uruchamiania w trybie odzyskiwania lub w Androidzie nie ulega zmianie, z wyjątkiem:

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

Ponieważ zasoby są przenoszone z ogólnego dysku RAM na dysk RAM vendor_boot, wynik połączenia ogólnego dysku RAM z dyskiem RAM vendor_boot nie ulega zmianie.

Udostępnianie narzędzia e2fsck

Pliki makefile urządzenia mogą dziedziczyć z:

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

• 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 działania programu pierwszy etap init zmienia katalog główny na /first_stage_ramdisk, a następnie wykonuje /system/bin/e2fsck.

Opcja 2a. Dedykowana partycja odzyskiwania i partycja odzyskiwania A/B

Użyj tej opcji w przypadku urządzeń z partycjami A/B recovery, czyli urządzeń z partycjami recovery_a i recovery_b partition. Takie urządzenia to urządzenia A/B i wirtualne A/B, w których partycja odzyskiwania może być aktualizowana, o tej konfiguracji:

AB_OTA_PARTITIONS += recovery

vendor_boot ramdysk zawiera bity ramdysku dostawcy i moduły jądra dostawcy, w tym:

• Pliki fstab na urządzeniu

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

Dysk RAM recovery zawiera wszystkie zasoby przywracania. Na takich urządzeniach konfiguracja produktu dziedziczy ustawienia z generic_ramdisk.mk.

Ustawianie wartości BOARD

Ustaw te wartości na urządzeniach z partycją A/B recovery:

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

Inicjowanie plików binarnych i linków symbolicznych

Dysk RAM recovery może zawierać /init -> /system/bin/init symlink i init_second_stage.recovery w /system/bin/init. Jednak ponieważ boot ramdisk jest łączony po recovery ramdisk, /init symlink jest nadpisywany. Gdy urządzenie uruchomi się w trybie odzyskiwania, do obsługi inicjowania drugiego etapu potrzebny jest plik binarny /system/bin/init.

Gdy urządzenie uruchomi się w recovery, zawartość recovery + vendor_boot + ogólne dyski RAM będzie następująca:

• /init (z dysku RAM, utworzonego na podstawie init_first_stage)
• /system/bin/init (z dysku RAM recovery, utworzonego na podstawie init_second_stage.recovery i uruchomionego z /init)

Gdy urządzenie uruchomi się w Androidzie, zawartość vendor_boot + generic ramdisks będzie wyglądać tak:

• /init (z ogólnego dysku RAM, utworzonego na podstawie init_first_stage)

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab z ogólnego dysku RAM na vendor_ramdisk. Przykład znajdziesz w tej zmianie.

Instalowanie modułów

Opcjonalnie możesz zainstalować moduły specyficzne dla urządzenia, aby vendor_ramdisk (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). Init nie przełącza roota. Wariant vendor_ramdisk modułów jest instalowany w katalogu głównym vendor_ramdisk. Przykłady instalowania modułów znajdziesz w sekcjach Konsola pierwszego etapu, Sumy kontrolne metadanych i Kompresja wirtualnego testu A/B.vendor_ramdisk

Konsola pierwszego etapu

Aby zainstalować wariant modułów vendor_ramdisk, użyj tego polecenia:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu pakiety linker, sh i toybox zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, a następnie w /system/bin w folderze 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 użyj tego polecenia:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas podłączania w pierwszym etapie, urządzenia, które nie obsługują GKI, instalują wariant ramdysku tych modułów: Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

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

Przykład znajdziesz na tej liście zmian.

Wirtualna kompresja A/B

Aby obsługiwać kompresję wirtualnego testu A/B, musisz zainstalować snapuserd na urządzeniu vendor_ramdisk. Urządzenie powinno dziedziczyć z virtual_ab_ota/compression.mk, co spowoduje zainstalowanie wariantu vendor_ramdisk aplikacji snapuserd.

Zmiany w procesie rozruchu

Podczas uruchamiania Androida proces rozruchu nie ulega zmianie. vendor_boot + ogólny dysk RAM jest podobny do obecnego procesu uruchamiania, z tym że fstab jest ładowany z vendor_boot. Ponieważ system/bin/recovery nie istnieje, first_stage_init traktuje to jako normalne uruchomienie.

Podczas uruchamiania w trybie przywracania proces uruchamiania ulega zmianie. Proces odzyskiwania + vendor_boot + ogólny dysk RAM jest podobny do dotychczasowego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot, a nie z obrazu recovery. Proces uruchamiania w trybie odzyskiwania wygląda tak:

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

   1. Wysyła obraz odzyskiwania + vendor_boot + ogólny dysk RAM do /. (Jeśli producent OEM duplikuje moduły jądra w dysku RAM odzyskiwania, dodając je do BOARD_RECOVERY_KERNEL_MODULES), vendor_boot jest opcjonalne).
   2. Uruchamia jądro z partycji boot.

2. Jądro montuje dysk RAM w /, a następnie wykonuje /init z ogólnego dysku RAM.

3. Rozpoczyna się inicjowanie pierwszego etapu, a następnie wykonywane są te czynności:

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

Udostępnianie narzędzia e2fsck

Pliki makefile urządzenia mogą dziedziczyć z:

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

• virtual_ab_ota/compression.mk jeśli urządzenie obsługuje wirtualną kompresję A/B.

Pliki makefile produktu instalują $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. W czasie wykonywania pierwszy etap init jest wykonywany /system/bin/e2fsck.

Opcja 2b. Dedykowana partycja odzyskiwania bez funkcji A/B

Użyj tej opcji w przypadku urządzeń z partycją recovery inną niż A/B, czyli urządzeń z partycją o nazwie recovery bez sufiksu gniazda. Takie urządzenia to:

• urządzenia inne niż A/B;
• Urządzenia A/B i wirtualne A/B, w których partycja odzyskiwania nie jest aktualizowana. (To nietypowe).

vendor_boot ramdysk zawiera bity ramdysku dostawcy i moduły jądra dostawcy, w tym:

• Pliki fstab na urządzeniu
• lib/modules (obejmuje moduły jądra dostawcy)

recovery Obraz musi być samodzielny. Musi zawierać wszystkie zasoby wymagane do uruchomienia trybu odzyskiwania, w tym:

• Obraz jądra
• Obraz DTBO
• Moduły jądra w lib/modules
• Inicjowanie pierwszego etapu jako linku symbolicznego /init -> /system/bin/init
• Binarny plik inicjujący drugiego etapu /system/bin/init
• Pliki fstab na urządzeniu
• Wszystkie inne zasoby odzyskiwania, w tym plik binarny recovery

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

Ustawianie wartości BOARD

Ustaw te wartości na urządzeniach 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

Inicjowanie plików binarnych i linków symbolicznych

Dysk RAM recovery musi zawierać link symboliczny /init -> /system/bin/init i init_second_stage.recovery w lokalizacji /system/bin/init. Gdy urządzenie uruchamia się w trybie odzyskiwania, do obsługi inicjowania na pierwszym i drugim etapie potrzebny jest plik binarny /system/bin/init.

Gdy urządzenie uruchomi się w recovery, zawartość dysków RAM recovery będzie następująca:

• /init -> /system/bin/init (z dysku RAM recovery)
• /system/bin/init (z dysku RAM recovery, utworzonego na podstawie init_second_stage.recovery i uruchomionego z /init)

Gdy urządzenie uruchomi się w Androidzie, zawartość vendor_boot + generic ramdisks będzie wyglądać tak:

• /init (z dysku RAM, utworzonego na podstawie init_first_stage)

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab zainstalowane w ogólnym dysku RAM do dysków RAM vendor_ramdisk i recovery. Przykład znajdziesz w tej zmianie.

Instalowanie modułów

Możesz zainstalować moduły specyficzne dla urządzenia w vendor_ramdisk i recovery ramdisk (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). init nie przełącza roota. Wariant vendor_ramdisk modułów jest instalowany w katalogu głównym vendor_ramdisk. Wariant recovery modułów jest instalowany w katalogu głównym dysku RAM recovery. Przykłady instalowania modułów na vendor_ramdisk i recovery ramdysku znajdziesz w sekcjach Konsola pierwszego etapu i Sumy kontrolne metadanych.

Konsola pierwszego etapu

Aby zainstalować wariant modułów vendor_ramdisk, użyj tego polecenia:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu pakiety linker, sh i toybox zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, a następnie w /system/bin w folderze 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 użyj tego polecenia:

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 \

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas podłączania w pierwszym etapie, urządzenia, które nie obsługują GKI, instalują wariant ramdysku tych 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 montowania w pierwszym etapie odzyskiwania, włącz wariant odzyskiwania tych modułów i zainstaluj je.

Zmiany w procesie rozruchu

Podczas uruchamiania Androida proces rozruchu nie ulega zmianie. vendor_boot + ogólny dysk RAM jest podobny do obecnego procesu uruchamiania, z tym że fstab jest ładowany z vendor_boot. Ponieważ system/bin/recovery nie istnieje, first_stage_init traktuje to jako normalne uruchomienie.

Podczas uruchamiania w trybie przywracania proces uruchamiania nie zmienia się. Dysk RAM z przywracaniem jest ładowany w taki sam sposób jak w przypadku obecnego procesu przywracania. Jądro jest wczytywane z obrazu recovery. Proces uruchamiania w trybie odzyskiwania wygląda następująco:

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

   1. Wysyła dysk RAM do odzyskiwania do /.
   2. Uruchamia jądro z partycji recovery.

2. Jądro montuje dysk RAM w /, a następnie wykonuje /init, który jest symlinkiem do /system/bin/init z dysku RAM recovery.

3. Rozpoczyna się inicjowanie pierwszego etapu, a następnie wykonywane są te czynności:

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

Sygnatury czasowe obrazu rozruchowego

Poniższy kod to przykład pliku 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 dysku RAM dodawany jest plik system/etc/ramdisk/build.prop. Ten plik zawiera informacje o sygnaturze czasowej kompilacji.

• W czasie działania pierwsza faza init kopiuje pliki z dysku RAM na tmpfs, a następnie zwalnia dysk RAM, aby druga faza init mogła odczytać ten plik i ustawić właściwości sygnatury czasowej obrazu boot.