Ogólna partycja rozruchowa

Na Androidzie 12 ogólny obraz boot, nazywany Ogólny obraz jądra (GKI), zawiera ogólny ramdysk i jądro GKI.

W przypadku urządzeń z Androidem 13 ogólny szablon plik ramdisk jest usuwany z obrazu boot i umieszczany w osobnym elemencie init_boot . Ta zmiana pozostawia na obrazie boot tylko jądro GKI.

Uaktualnianie urządzeń, które nadal korzystają z Androida 12 lub starszych wersji jądra, ogólny dysk RAM nie jest wymagane dla nowego obrazu w formacie init_boot.

Aby utworzyć ogólny dysk RAM, przenieś z niego zasoby konkretnego dostawcy tak, aby ogólny dysk RAM zawierał tylko pierwszy etap init oraz właściwość plik zawierający informacje o sygnaturze czasowej.

Na urządzeniach, które:

  • Nie używaj dedykowanej partycji recovery, wszystkie informacje odzyskiwania są przenoszone z ogólny ramdysk do vendor_boot.

  • Użyj dedykowanej partycji recovery, bez zmian w dysku RAM recovery jest wymagany, ponieważ dysk RAM recovery jest samodzielny.

Architektura

Poniższe schematy pokazują architekturę urządzeń z Androidem 12 lub więcej. Urządzenia z Androidem 13 mają nowe init_boot obraz zawierający ogólny ramdysk. Urządzenia, które przechodzą z Androida 12 na Androida w wersji 12 13 osób używa tej samej architektury co Android 12.

Wprowadzenie na rynek z Androidem 13, bez dedykowanego przywracania

Uruchamianie/uaktualnianie urządzenia, GKI, bez dedykowanego przywracania

Rysunek 1. na urządzeniach z Androidem 13 lub aktualizacji do wersji 13 z interfejsem GKI, bez dedykowanego przywracania.

Wprowadzenie na rynek z Androidem 13, dedykowanym plikiem ramdisk i odzyskiwaniem A/B

Uruchamianie/uaktualnianie urządzenia, GKI, dedykowanego oprogramowania i odzyskiwania plików A/B

Rysunek 2. Urządzenia z Androidem 13 lub wprowadzane na rynek z nowym interfejsem GKI, dedykowanym i odtwarzaniem A/B.

Skorzystaj z tego rysunku, jeśli urządzenie ma partycje recovery_a i recovery_b.

Wprowadzenie na rynek z Androidem 13, dedykowanym dyskiem RAM i odzyskaniem innego typu niż A/B

Uruchamianie/uaktualnianie urządzenia, GKI, dedykowane i odtwarzanie spoza A/B

Rysunek 3. Urządzenia z Androidem 13, które wprowadzamy na rynek lub aktualizują się do wersji 13 z GKI, dedykowanym przywracaniem opartym na A/B.

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

Wprowadzenie na rynek lub uaktualnienie Androida do wersji 12 bez dedykowanego przywracania

Uruchamianie/uaktualnianie urządzenia, GKI, bez dedykowanego przywracania

Rysunek 4. Urządzenia z Androidem 12, które wprowadzamy na rynek lub aktualizują się do wersji 12 z interfejsem GKI, bez dedykowanego przywracania.

Uruchomienie lub uaktualnienie Androida do wersji 12, dedykowanego dysku ramdisk i odzyskiwania A/B.

Uruchamianie/uaktualnianie urządzenia, GKI, dedykowanego oprogramowania i odzyskiwania plików A/B

Rysunek 5. Urządzenia z Androidem 12, które wprowadzamy na rynek lub aktualizują się do wersji 12 z interfejsem GKI, dedykowanym i trybem odzyskiwania A/B.

Skorzystaj z tego rysunku, jeśli urządzenie ma partycje recovery_a i recovery_b.

Uruchomienie lub uaktualnienie Androida do wersji 12, dedykowanego dysku ramdisk i odzyskiwania innego typu niż A/B.

Uruchamianie/uaktualnianie urządzenia, GKI, dedykowane i odtwarzanie spoza A/B

Rysunek 6. Urządzenia z Androidem 12, które wprowadzamy na rynek lub aktualizują się do wersji 12 z interfejsem GKI, dedykowanym przywracaniem opartym na A/B.

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

Uaktualnianie do Androida 12, przywracanie systemu po rozruchu (recovery-as-ramdisk)

Uruchamianie/uaktualnianie urządzenia, bez GKI, przywracanie po rozruchu

Rysunek 7. Urządzenia aktualizujące się do Androida 12, bez GKI i przywracanie po rozruchu.

Zaktualizuj Androida do wersji 12 z specjalnym odzyskiwaniem (specjalny dysk RAM)

Uruchamianie/uaktualnianie urządzenia, bez GKI, dedykowane przywracanie

Rysunek 8. Urządzenia aktualizujące się do Androida 12, bez GKI, dedykowane przywracanie.

Zawartość obrazów rozruchowych

Obrazy rozruchowe Androida zawierają następujące elementy.

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

    • Wersja nagłówka V4
    • Standardowy obraz pamięci RAM

  • Standardowy obraz boot

    • wersji nagłówka V3 lub Wersja 4
      • boot_signature na potrzeby certyfikatu Boot.img GKI (tylko w wersji 4). Aplikacja z certyfikatem GKI boot.img nie jest podpisana do weryfikacji podczas uruchamiania. OEM musi podpisz gotowy dokument boot.img za pomocą konkretnego urządzenia AVB, .
      • Ogólna cmdline (GENERIC_KERNEL_CMDLINE)
      • Jądro GKI
    • Ogólny obraz dysku ramdisk
      • Uwzględnione tylko na obrazach w aplikacji boot z Androida 12 i wcześniej

  • Obraz vendor_boot (szczegóły znajdziesz w artykule Rozruch dostawcy Partycje)

    • vendor_boot nagłówek
      • cmdline (BOARD_KERNEL_CMDLINE) dla konkretnego urządzenia
    • Obraz pamięci RAM vendor_boot
      • lib/modules
      • Zasoby do przywracania (jeśli nie masz dedykowanego odzyskiwania)
    • Obraz dtb

  • Obraz recovery

    • Wersja nagłówka V2
      • cmdline na konkretnym urządzeniu na potrzeby przywracania (w razie potrzeby)
      • W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielny; zobacz Obrazy odzyskiwania. Na przykład:
      • Pole cmdline nie jest połączone z elementami boot i vendor_boot cmdline.
      • Nagłówek określa w razie potrzeby dane logowania DTBO.
      • W przypadku partycji przywracania A/B zawartość można połączyć lub wywnioskować od boot i vendor_boot. Na przykład:
      • cmdline jest połączony z boot i vendor_boot cmdline.
      • DTBO można wywnioskować na podstawie nagłówka vendor_boot.
    • Obraz pamięci RAM recovery
      • Zasoby do przywracania
      • W przypadku partycji przywracania innej niż A/B zawartość dysku RAM musi być samodzielny; zobacz Obrazy przywracania. Na przykład:
      • lib/modules musi zawierać wszystkie moduły jądra wymagane do uruchomienia tryb przywracania
      • Dysk Ramdisk przywracania musi zawierać element init.
      • W przypadku partycji odtwarzania A/B dysk RAMdysk przywracania jest dołączony do ogólny i vendor_boot, dlatego nie musi to być niezależnego rozwiązania. Na przykład:
      • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do trybu przywracania rozruchowego oprócz modułów jądra w ramach dysku ramdisk vendor_boot.
      • Dowiązanie symboliczne w domenie /init może istnieć, ale jest przesłonięte przez pliku binarnego /init pierwszego etapu w obrazie rozruchowym.

Ogólna zawartość obrazu ramdisk

Ogólny ramdisk zawiera te komponenty.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build rekwizytów
  • Puste katalogi punktów podłączania: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
  • first_stage_ramdisk/
    • Zduplikowane puste katalogi punktów podłączania: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Integracja obrazu rozruchowego

Flagi kompilacji określają, jak init_boot, boot, recovery i vendor_boot do tworzenia obrazów. Wartością zmiennej tablicy logicznej musi być ciąg znaków true lub pozostaw puste (domyślnie).

  • TARGET_NO_KERNEL Ta zmienna wskazuje, czy kompilacja używa gotowego rozruchu . Jeśli zmienna jest ustawiona na true, ustaw BOARD_PREBUILT_BOOTIMAGE z 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 obraz recovery jako obraz boot. W przypadku korzystania z GKI ta zmienna to puste, a zasoby przywracania należy przenieść do folderu vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE Ta zmienna wskazuje, że tablica używa funkcji GKI. Ta zmienna nie ma wpływu na funkcje sysprop ani PRODUCT_PACKAGES

    Jest to przełącznik GKI na poziomie płyty. wszystkie te zmienne są ograniczonych przez tę zmienną.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT Ta zmienna określa, czy Zasoby przywracania pamięci RAM są tworzone w vendor_boot.

    • Gdy zasada ma wartość true, zasoby przywracania są tworzone tylko na potrzeby środowiska vendor-ramdisk/ a nie dla recovery/root/.

    • Jeśli zasoby przywracania są puste, są przeznaczone tylko dla recovery/root/ i nie są przeznaczone stworzona na potrzeby modelu vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT Ta zmienna określa, czy GSI Klucze AVB są tworzone pod kątem vendor_boot.

    • Po ustawieniu wartości true, jeżeli BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • Jest ustawione, a klucze GSI AVB są tworzone $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb

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

    • Jeśli pole BOARD_RECOVERY_AS_ROOT jest puste, to:

      • Jest ustawione, a klucze GSI AVB są tworzone $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb

      • Nie jest skonfigurowana, klucze GSI AVB są tworzone $ANDROID_PRODUCT_OUT/ramdisk/avb

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE Ta zmienna określa, czy Obraz recovery zawiera jądro lub nie. Urządzenia z Androidem wprowadzone na rynek 12 i za pomocą partycji A/B recovery muszą być ustawione to na true. Urządzenia wprowadzone na rynek z Androidem 12 i w przypadku użycia innych niż A/B należy ustawić tę zmienną na false, aby zachować obraz przywracania niezależne od siebie.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES Ta zmienna określa, czy Element $OUT/boot*.img jest kopiowany do folderu IMAGES/ w sekcji plików 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 Zostanie wygenerowana wartość init_boot.img i określi rozmiar. Po ustawieniu tego ogólnego folderu Ramdisk została dodana do init_boot.img zamiast boot.img i wymaga BOARD_AVB_INIT_BOOT* zmiennych do ustawienia łańcuch vbmeta.

Dozwolone kombinacje

Komponent lub zmienna Uaktualnij urządzenie bez partycji przywracania Uaktualnij urządzenie z partycją przywracania Uruchom urządzenie bez partycji przywracania Uruchom urządzenie z partycją odtwarzania A/B Uruchom urządzenie z partycją odzyskiwania inną niż A/B Aosp_arm64
Zawiera: boot tak tak tak tak tak tak
Zawiera init_boot (Android 13) nie nie tak tak tak tak
Zawiera: vendor_boot opcjonalne opcjonalne tak tak tak nie
Zawiera: recovery nie tak nie tak tak nie
BOARD_USES_RECOVERY_AS_BOOT true pusty pusty pusty pusty pusty
BOARD_USES_GENERIC_KERNEL_IMAGE pusty pusty true true true true
PRODUCT_BUILD_RECOVERY_IMAGE pusty true lub pusta pusty true lub pusta true lub 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ą ustawiać Od PRODUCT_BUILD_RECOVERY_IMAGE do true lub puste. W przypadku tych urządzeń, jeśli Ustawiono BOARD_RECOVERYIMAGE_PARTITION_SIZE, utworzono obraz recovery.

Włącz łańcuchową instancję Vbmeta na potrzeby rozruchu

Łańcuchowa konfiguracja vbmeta musi być włączona w przypadku obrazów boot i init_boot. Określ następujące:

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

Zobacz na przykład ten artykuł .

Systemowy jako root

Tryb systemu jako root nie jest obsługiwany w przypadku urządzeń korzystających z GKI. Wł. takich urządzeń, pole BOARD_BUILD_SYSTEM_ROOT_IMAGE musi być puste. Systemowy jako root nie jest obsługiwane na urządzeniach z dynamicznymi partycjami.

Konfiguracje produktów

Na urządzeniach korzystających z ogólnego dysku ramdisk musi być zainstalowana lista plików, które na dysku RAM. W tym celu wpisz w device.mk:

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

Plik generic_ramdisk.mk zapobiega też przypadkowemu dostępowi do innych plików Marka. instalując inne pliki w folderze ramdisk (przenieś je do folderu vendor_ramdisk). ).

Skonfiguruj urządzenia

Instrukcje konfiguracji różnią się w przypadku urządzeń z Androidem wprowadzonych na rynek 13, przejście na Androida 12 i wprowadzenie na rynek z Androidem 12. Konfiguracja Androida 13 jest podobna do konfiguracji Androida 12

  • Urządzenia z aktualizacją do Androida 12:

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

      • Architektura ustawiona na BOARD_USES_RECOVERY_AS_BOOT jako true: na Rys. 3.

      • Pole BOARD_USES_RECOVERY_AS_BOOT jest puste, architektura jest przedstawiona. Rysunek 4.

    • Można ustawić pole BOARD_USES_RECOVERY_AS_BOOT na puste. Jeśli to robią, korzystają z funkcji nowe konfiguracje. Jeśli takie urządzenia:

      • Nie używaj dedykowanej partycji recovery, architektura jest przedstawiona. na Rys. 1. Opcja konfiguracji urządzenia to Opcja 1.

      • Użyj dedykowanej partycji recovery. Architektura jest przedstawiona w Rysunek 2a lub Rysunek 2b i konfiguracja urządzenia to Opcja 2a lub Opcja 2b.

  • Na urządzeniach z Androidem 12 należy skonfigurować BOARD_USES_RECOVERY_AS_BOOT, aby opróżnić i użyć nowych konfiguracji. Jeśli urządzenia:

    • Nie używaj dedykowanej partycji recovery, architektura jest pokazana w Rysunek 1 przedstawia opcję 1 konfiguracji urządzenia.

    • Użyj dedykowanej partycji recovery. Architektura jest przedstawiona w Rysunek 2a lub Rysunek 2b i konfiguracja urządzenia to Opcja 2a lub Opcja 2b.

Ponieważ aosp_arm64 tworzy tylko GKI (a nie vendor_boot ani przywracanie działania), To nie jest pełna wartość docelowa. Informacje o aosp_arm64konfiguracjach kompilacji: generic_arm64

Opcja 1. Brak dedykowanej partycji odzyskiwania

Urządzenia bez partycji recovery zawierają ogólny obraz boot w boot partycja. Dysk RAM vendor_boot zawiera wszystkie zasoby przywracania, w tym lib/modules (z modułami jądra dostawcy). Na takich urządzeniach konfiguracja usługi dziedziczy z generic_ramdisk.mk

Ustaw wartości tablicy 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ć dowiązanie symboliczne od /init do /system/bin/init, i init_second_stage.recovery o /system/bin/init. Ponieważ jednak ogólny dysk RAM jest połączony za dyskiem vendor_boot, /init dowiązanie symboliczne zostanie zastąpione. Po uruchomieniu urządzenia podczas przywracania Do obsługi inicjowania drugiego etapu wymagany jest plik binarny /system/bin/init. Zawartość z vendor_boot + ogólne dyski RAM:

  • /init (z ogólnego folderu ramdisk, utworzona na podstawie init_first_stage)
  • /system/bin/init (z vendor_ramdisk, wyprodukowano z init_second_stage.recovery).

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab, które zostały zainstalowane, do standardowego dysku RAM do vendor_ramdisk Zobacz na przykład ten artykuł .

Zainstaluj moduły

W vendor_ramdisk możesz zainstalować moduły przeznaczone na konkretne urządzenia (pomiń ten krok, jeśli nie masz do zainstalowania żadnych modułów przeznaczonych na konkretne urządzenia).

  • Używaj wariantu vendor_ramdisk modułu, gdy jest on instalowany w /first_stage_ramdisk. Ten moduł powinien być dostępny po init przenosi roota w /first_stage_ramdisk, ale przed init przełącza się na roota w /system Przykłady znajdziesz w sekcjach Sumy kontrolne metadanych oraz Wirtualna kompresja A/B.

  • Gdy moduł zostanie zainstalowany na platformie /, użyj wariantu recovery. Ten moduł powinien być dostępny, zanim init przejdzie na poziom główny /first_stage_ramdisk Szczegółowe informacje na temat instalowania modułów w / znajdziesz w sekcji Pierwsze kroki w konsoli scenicznej.

Konsola pierwszego etapu

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

Aby bezpośrednio zainstalować moduły przywracania, użyj poniższego rozwiązania.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Dzięki temu instalacje linker, sh i toybox w aplikacji $ANDROID_PRODUCT_OUT/recovery/root/system/bin, a następnie instaluje się na /system/bin poniżej vendor_ramdisk.

Aby dodać moduły wymagane przez konsolę pierwszego etapu (na przykład adbd), użyj metody następujących po sobie.

PRODUCT_PACKAGES += adbd.recovery

Dzięki temu określone moduły są instalowane $ANDROID_PRODUCT_OUT/recovery/root/system/bin, a następnie instaluje się na /system/bin poniżej: vendor_ramdisk.

Sumy kontrolne metadanych

Do obsługi metadanych sumy kontrolne podczas montażu w pierwszym etapie na urządzeniach, które nie obsługują GKI, zainstaluj dysk RAM. poniższych 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 \

Zobacz na przykład ten artykuł do listy zmian.

Wirtualna kompresja A/B

Aby obsługiwać wirtualną kompresję A/B, wsnapuserd vendor_ramdisk Urządzenie powinno dziedziczyć z elementu virtual_ab_ota/compression.mk, która instaluje wariant vendor_ramdisk aplikacji snapuserd.

Zmiany w procesie uruchamiania

Proces uruchamiania systemu w trybie przywracania czy na urządzeniu z Androidem nie zmienia się, ponieważ następujący wyjątek:

  • Ramdysk build.prop przechodzi do drugiego etapu (/second_stage_resources) init może odczytywać sygnaturę czasową kompilacji podczas uruchamiania.

Zasoby są przenoszone z ogólnego dysku RAM do dysku vendor_boot, konkatenacji ogólnego pliku RAM na dysku vendor_boot nie zmienia się.

Udostępnij e2fsck

Plik Makerfiles może dziedziczyć z tych elementów:

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

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

Instalacja pliku Makerfiles $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck Na w środowisku wykonawczym, pierwszy etap (init) przełącza się na poziom /first_stage_ramdisk, a następnie wykonuje polecenie /system/bin/e2fsck.

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

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

AB_OTA_PARTITIONS += recovery

Dysk ramdisk vendor_boot zawiera elementy komponentu ramdisk oraz dostawca jądra systemu. Są to między innymi:

  • Pliki fstab dotyczące konkretnego urządzenia

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

Dysk RAM recovery zawiera wszystkie zasoby przywracania. Na takich urządzeniach konfiguracja usługi dziedziczy z generic_ramdisk.mk

Ustaw wartości tablicy BOARD

Ustaw te wartości dla urządzeń 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

Dysk RAM recovery może zawierać dowiązanie symboliczne /init -> /system/bin/init oraz init_second_stage.recovery o /system/bin/init. Ponieważ jednak proces uruchamiania dysk Ramdisk jest konkatenowany za elementem recovery, dowiązanie symboliczne /init ma postać nadpisana. Gdy urządzenie uruchomi się w trybie przywracania, /system/bin/init do obsługi inicjowania drugiego etapu wymagany jest plik binarny.

Po uruchomieniu urządzenia recovery treści recovery + vendor_boot i ogólne dyski RAM:

  • /init (z Ramdisk, utworzona na podstawie init_first_stage)
  • /system/bin/init (z recovery dysku ramdy, wybudowano z init_second_stage.recovery i wykonano z poziomu /init)

Po uruchomieniu urządzenia z Androidem treści vendor_boot + ogólne są takie:

  • /init (z ogólnego folderu ramdisk, utworzona na podstawie init_first_stage)

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab do ogólnego dysku RAM do vendor_ramdisk Zobacz na przykład ten artykuł .

Zainstaluj moduły

Opcjonalnie w vendor_ramdisk możesz zainstalować moduły przeznaczone na konkretne urządzenia (pomiń ten krok, jeśli nie masz do zainstalowania żadnych modułów przeznaczonych na konkretne urządzenia). Init nie zmienia poziomu dostępu. Wariant vendor_ramdisk modułów do zainstalowania pierwiastek z kolumny vendor_ramdisk. Przykłady instalowania modułów vendor_ramdisk, zobacz Konsola pierwszego etapu, Metadane sumy kontrolne i wirtualne A/B .

Konsola pierwszego etapu

Aby zainstalować wersję vendor_ramdisk modułów, użyj tych poleceń:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu instalacje linker, sh i toybox w aplikacji $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, a następnie instaluje się na /system/bin poniżej vendor_ramdisk.

Aby dodać moduły wymagane przez konsolę pierwszego etapu (na przykład adbd), włącz vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a potem użyj tego

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Dzięki temu określone moduły są instalowane $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin Jeśli dysk RAM vendor_boot jest załadowany w trybie przywracania, moduł jest też dostępny w programie recovery. Jeśli Dysk RAM vendor_boot nie jest załadowany w trybie przywracania. Urządzenie może opcjonalnie zainstaluj też adbd.recovery.

Sumy kontrolne metadanych

Do obsługi metadanych sumy kontrolne podczas montażu w pierwszym etapie na urządzeniach, które nie obsługują GKI, zainstaluj dysk RAM. poniższych 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 \

Zobacz na przykład ten artykuł do listy zmian.

Wirtualna kompresja A/B

Aby obsługiwać wirtualną kompresję A/B, wsnapuserd vendor_ramdisk Urządzenie powinno dziedziczyć z elementu virtual_ab_ota/compression.mk, która instaluje wariant vendor_ramdisk aplikacji snapuserd.

Zmiany w procesie uruchamiania

Podczas uruchamiania urządzenia z Androidem proces uruchamiania się nie zmienia. Przycisk vendor_boot + ogólny dysk ramdisk jest podobny do istniejącego procesu rozruchowego, z tą różnicą, że fstab wczytuje się z vendor_boot. system/bin/recovery nie istnieje, first_stage_init obsługuje to w zwykły sposób.

Podczas uruchamiania w trybie przywracania zmienia się proces uruchamiania. Przycisk odzyskiwania + vendor_boot i ogólny dysk RAM są podobne do obecnego procesu przywracania, ale jądro jest wczytywane z obrazu boot, a nie z obrazu recovery. Proces uruchamiania w trybie przywracania jest następujący.

  1. Program rozruchowy uruchomi się i wykona te czynności:

    1. Przekazuje wartość przywracania + vendor_boot + ogólny dysk RAM do elementu /. (Jeśli producent OEM duplikuje moduły jądra w ramach dysku RAM przywracania, dodając je do BOARD_RECOVERY_KERNEL_MODULES), vendor_boot jest opcjonalny).
    2. Uruchamia jądro z partycji boot.

  2. Jądro podłącza ramdisk do /, a potem wykonuje /init z ogólnego dysku ramdisk.

  3. Rozpoczyna się pierwszy etap, a potem:

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

Udostępnij e2fsck

Plik Makerfiles może dziedziczyć z tych elementów:

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

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

Instalacja pliku Makerfiles $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck Na w środowisku wykonawczym, pierwszy etap (init) wykonuje /system/bin/e2fsck.

Opcja 2b. Specjalna partycja odzyskiwania konta inna niż A/B

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

  • urządzenia inne niż A/B;
  • urządzenia A/B i wirtualne urządzenia A/B, których partycja nie jest które można zaktualizować. (Jest to nietypowe).

Dysk ramdisk vendor_boot zawiera elementy komponentu ramdisk oraz dostawca jądra systemu. Są to między innymi:

  • Pliki fstab dotyczące konkretnego urządzenia
  • lib/modules (zawiera moduły jądra dostawcy)

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

  • Obraz jądra
  • Obraz DTBO
  • Moduły jądra w lib/modules
  • Rozpoczęcie pierwszego etapu jako dowiązanie symboliczne /init -> /system/bin/init
  • Plik binarny rozpoczęcia drugiego etapu /system/bin/init
  • Pliki fstab dotyczące konkretnego urządzenia
  • Wszystkie inne zasoby do przywracania, w tym plik binarny recovery

Na takich urządzeniach konfiguracja usługi dziedziczy od generic_ramdisk.mk.

Ustaw wartości tablicy BOARD

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

Dysk RAM recovery musi zawierać dowiązanie symboliczne /init -> /system/bin/init oraz init_second_stage.recovery o /system/bin/init. Po uruchomieniu urządzenia trybu przywracania systemu, wymagany jest plik binarny /system/bin/init do obsługi obu formatów i etap 2. etapu.

Po uruchomieniu urządzenia w środowisku recovery zawartość recovery dysków RAM jest w następujący sposób:

  • /init -> /system/bin/init (z recovery dysku ramdy)
  • /system/bin/init (z recovery dysku ramdy, wybudowano z init_second_stage.recovery i wykonano z poziomu /init)

Po uruchomieniu urządzenia z Androidem treści vendor_boot + ogólne są takie:

  • /init (z Ramdisk, utworzona na podstawie init_first_stage)

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab do ogólnego dysku RAM do vendor_ramdisk i recovery ramdysk. Zobacz na przykład ten artykuł .

Zainstaluj moduły

Moduły dostosowane do konkretnych urządzeń można instalować w vendor_ramdisk oraz recovery dysk ramdysk (pomiń ten krok, jeśli nie masz do zainstalowania żadnych modułów przeznaczonych na konkretne urządzenia). init nie zmienia poziomu dostępu. Wariant vendor_ramdisk modułów do zainstalowania pierwiastek z kolumny vendor_ramdisk. Wariant recovery modułów do zainstalowania pierwiastek z recovery dysku ramdisk. Przykłady instalowania modułów vendor_ramdisk i recovery ramdisk, se Konsola pierwszego etapu i metadane sumy kontrolne.

Konsola pierwszego etapu

Aby zainstalować wersję vendor_ramdisk modułów, użyj tych poleceń:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu instalacje linker, sh i toybox w aplikacji $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, a następnie instaluje się na /system/bin poniżej vendor_ramdisk.

Aby dodać moduły wymagane przez konsolę pierwszego etapu (na przykład adbd), włącz vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a potem użyj tego

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Dzięki temu określone moduły są instalowane $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin

Aby zainstalować wariant recovery modułów, zastąp element vendor_ramdisk ciągiem recovery:

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

Sumy kontrolne metadanych

Do obsługi metadanych sumy kontrolne podczas montażu w pierwszym etapie na urządzeniach, które nie obsługują GKI, zainstaluj dysk RAM. poniższych 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 podłączania podczas przywracania, włącz wersji tych modułów do odzyskiwania konta i je zainstalować.

Zmiany w procesie uruchamiania

Podczas uruchamiania urządzenia z Androidem proces uruchamiania się nie zmienia. Przycisk vendor_boot + ogólny dysk ramdisk jest podobny do istniejącego procesu rozruchowego, z tą różnicą, że fstab wczytuje się z vendor_boot. system/bin/recovery nie istnieje, first_stage_init obsługuje to w zwykły sposób.

W przypadku uruchomienia w trybie przywracania proces uruchamiania się nie zmienia. Odzyskiwanie Plik ramdisk jest wczytywany w taki sam sposób jak istniejący proces przywracania. Jądro zostało wczytane z obrazu recovery. jest opisany poniżej.

  1. Program rozruchowy uruchomi się i wykona te czynności:

    1. Przekazuje pamięć RAM dysku przywracania do folderu /.
    2. Uruchamia jądro z partycji recovery.

  2. Jądro podłącza dysk ramdisk do serwera /, a następnie wykonuje polecenie /init, które jest dowiązaniem symbolicznym do: /system/bin/init z dysku RAM recovery.

  3. Rozpoczyna się pierwszy etap, a potem:

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

Sygnatury czasowe obrazu rozruchowego

Ten 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

  • Podczas kompilacji do ogólnego folderu dodawany jest plik system/etc/ramdisk/build.prop. i „ramdisk”. Ten plik zawiera informacje o sygnaturze czasowej kompilacji.

  • W czasie działania, pierwszy etap: init kopii z dysku ramdy do tmpfs. Zwolnij go, etap init może odczytać ten plik, aby ustawić boot właściwości sygnatury czasowej obrazu.