Ogólna partycja rozruchowa

W Androidzie 12 ogólny obraz boot (określany jako Ogólny obraz jądra) zawiera ogólnikowy plik ramdisk i jądro GKI.

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

W przypadku uaktualnień urządzeń, na których nadal używane są Androida 12 lub starsze wersje jądra, ogólny plik Ramdisk pozostaje w dotychczasowym miejscu i nie wymaga tworzenia nowego obrazu init_boot.

Aby utworzyć ogólny dysk RAM, przenieś z niego zasoby konkretnego dostawcy 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 partycji recovery, ponieważ wszystkie bity odzyskiwania zostaną przeniesione z ramdysk ogólnego do ramdysk vendor_boot.

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

Architektura

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

Uruchomienie z Androidem 13 bez specjalnego odzyskiwania

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

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 oprogramowaniem i mechanizmem odzyskiwania A/B (dedykowany dysk RAM)

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

Rysunek 2. Urządzenia z Androidem 13, które są uruchamiane lub aktualizowane do tej wersji, z interfejsem GKI, dedykowanym i A/B.

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

Uruchomienie z Androidem 13, specjalny tryb odzyskiwania (specjalny dysk RAM).

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

Rysunek 3. Urządzenia z Androidem 13, które wprowadzają na rynek lub aktualizują się do wersji 13, z interfejsem GKI, dedykowanym i odtwarzaniem innym niż A/B.

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

Uruchomienie lub uaktualnienie do Androida 12 bez specjalnego odzyskiwania

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

Rysunek 4. Urządzenia uruchamiające lub aktualizujące Androida 12 z Google Knox Integration (GKI) bez dedykowanego odzyskiwania.

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

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

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

Jeśli na urządzeniu są partycje recovery_a i recovery_b, patrz ten rysunek.

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

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

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

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

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

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

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

Zaktualizuj Androida do wersji 12, dedykowane odzyskiwanie (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 rozruchu Androida zawierają:

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

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

  • Standardowy obraz boot

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

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

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

  • Obraz recovery

    • Wersja nagłówka V2
      • Informacje o urządzeniu cmdline (w razie potrzeby)
      • W przypadku partycji przywracania innej niż A/B zawartość nagłówka musi być samodzielna; patrz Obrazy przywracania. Na przykład:
      • cmdline nie jest złączany z boot i vendor_boot cmdline.
      • W nagłówku w razie potrzeby określono DTBO odzyskiwania.
      • W przypadku partycji przywracania A/B zawartość można połączyć lub wywnioskować z zasad boot i vendor_boot. Na przykład:
      • cmdline jest złączone z boot i vendor_boot cmdline.
      • DTBO można określić na podstawie nagłówka vendor_boot.
    • Obraz pamięci RAM recovery
      • Zasoby dotyczące odzyskiwania
      • W przypadku partycji odzyskiwania innej niż A/B zawartość dysku RAM musi być samodzielna (patrz obrazy odzyskiwania). Na przykład:
      • lib/modules musi zawierać wszystkie moduły jądra wymagane do uruchomienia trybu odzyskiwania.
      • Pamięć RAM dysku odzyskiwania musi zawierać init.
      • W przypadku partycji odzyskiwania A/B dysk RAM odzyskiwania jest dodawany na początku ogólnego dysku RAM i dysku RAM vendor_boot, dlatego nie musi być samodzielny. Na przykład:
      • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do uruchamiania trybu odzyskiwania systemu operacyjnego oprócz modułów jądra w pliku ramdysk vendor_boot.
      • Dowiązanie symboliczne w miejscu /init może istnieć, ale jest przesłonięte przez plik binarny /init pierwszego etapu w obrazie rozruchowym.

Treści ogólnego obrazu dysku RAM

Ogólny dysk RAM zawiera te komponenty:

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

Integracja obrazu rozruchowego

Flagi kompilacji kontrolują sposób tworzenia obrazów init_boot, boot, recovery i vendor_boot. Wartością zmiennej tablicy logicznej musi być ciąg znaków true lub być pusta (ustawienie domyślne).

  • TARGET_NO_KERNEL. Ta zmienna wskazuje, czy kompilacja używa wstępnie utworzonego obrazu rozruchu. Jeśli ta zmienna jest ustawiona na 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. Gdy używasz GKI, ta zmienna jest pusta, a zasoby do odzyskiwania należy przenieść do vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. Ta zmienna wskazuje, że płyta główna używa GKI. Ta zmienna nie ma wpływu na zmienne sysprops ani PRODUCT_PACKAGES.

    To jest przełącznik GKI na poziomie tablicy. Ta zmienna ogranicza wszystkie poniższe zmienne.

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

    • Gdy to ustawienie jest ustawione na true, zasoby odzyskiwania są tworzone tylko w wersji vendor-ramdisk/ i nie są tworzone w wersji recovery/root/.

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

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

    • Jeśli ustawienie to true, a BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

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

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

    • Jeśli pusty, jeśli BOARD_RECOVERY_AS_ROOT:

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

      • Nie ustawiono, klucze GSI AVB są tworzone 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 urządzeń z partycją A/B recovery muszą ustawić tę zmienną na true. Urządzenia uruchamiane z Androidem 12 i korzystające z niestandardowych wersji A/B muszą mieć tę zmienną ustawioną na false, aby obraz odzyskiwania był samodzielny.

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

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

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

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Ta zmienna określa, czy ma być generowany element init_boot.img, oraz ustawia jego rozmiar. Gdy jest ustawiony, do init_boot.img zamiast boot.img dodawany jest ogólny ramdysk. Wymaga to ustawienia zmiennych BOARD_AVB_INIT_BOOT* dla łańcucha vbmeta.

Dozwolone kombinacje

Komponent lub zmienna Modernizacja urządzenia bez partycji odzyskiwania Uaktualnianie urządzenia z partycją odzyskiwania Uruchom urządzenie bez partycji przywracania Uruchomienie urządzenia z partycją odzyskiwania A/B Uruchamianie urządzenia z partycją odzyskiwania inną niż A/B aosp_arm64
Zawiera: boot tak tak tak tak tak tak
zawiera init_boot (Android 13) no no tak tak tak tak
Zawiera: vendor_boot opcjonalne opcjonalne tak tak tak no
Zawiera: recovery no tak no tak tak no
BOARD_USES_RECOVERY_AS_BOOT true pusty pusty pusty pusty pusty
BOARD_USES_GENERIC_KERNEL_IMAGE pusty pusty true true true true
PRODUCT_BUILD_RECOVERY_IMAGE pusty true lub puste pusty true lub puste true lub puste 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

W przypadku urządzeń z dedykowaną partycją recovery ustawienie pola PRODUCT_BUILD_RECOVERY_IMAGE może mieć wartość true lub być puste. W przypadku tych urządzeń ustawienie BOARD_RECOVERYIMAGE_PARTITION_SIZE powoduje utworzenie obrazu recovery.

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

W przypadku obrazów boot i init_boot musi być włączona połączona wartość vbmeta. Podaj te informacje:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

Przykładem takiej zmiany jest ta.

System jako root

Tryb systemu jako root nie jest obsługiwany w przypadku urządzeń korzystających z GKI. Na takich urządzeniach wartość BOARD_BUILD_SYSTEM_ROOT_IMAGE musi być pusta. Ustawienia systemowe jako główny również nie są obsługiwane w przypadku urządzeń z dynamicznymi partycjami.

Konfiguracje usług

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

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

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

Konfigurowanie urządzeń

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

  • Urządzenia zaktualizowane do Androida 12:

    • Może zachować wartość BOARD_USES_RECOVERY_AS_BOOT. Jeśli tak, 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 wyglądać tak jak na rysunku 3.

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

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

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

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

  • Na urządzeniach uruchamianych z Androidem 12 ustawienie BOARD_USES_RECOVERY_AS_BOOT musi być puste i używać nowych konfiguracji. Jeśli takie urządzenia:

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

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

Funkcja aosp_arm64 tworzy tylko GKI (a nie vendor_boot ani odzyskiwania), więc nie jest pełnym celem. Informacje o aosp_arm64konfiguracjach kompilacji znajdziesz w dokumencie generic_arm64.

Opcja 1. Brak dedykowanej partycji odzyskiwania

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

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 /init do /system/bin/init i init_second_stage.recovery w miejscu /system/bin/init. Ponieważ jednak ogólny dysk RAM jest łączony po dysku RAM vendor_boot, /initsymlink zostanie zastąpiony. Gdy urządzenie uruchomi się w trybie odzyskiwania, potrzebny jest plik binarny /system/bin/init, aby umożliwić inicjalizację drugiego etapu. Zawartość vendor_boot + generic ramdisks:

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

Przenoszenie plików fstab

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

Instalowanie modułów

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

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

  • Gdy moduł zostanie zainstalowany na platformie /, użyj wariantu recovery. Ten moduł powinien być dostępny, zanim init przełączy się na /first_stage_ramdisk. Szczegółowe informacje o instalowaniu modułów w konsoli First Stage znajdziesz w artykule Konsola First Stage./

Konsola pierwszego etapu

Ponieważ konsola pierwszego etapu uruchamia się, zanim init przełączy się na /first_stage_ramdisk, musisz zainstalować wariant modułów recovery. Domyślnie oba warianty modułów są instalowane w programie build/make/target/product/base_vendor.mk, więc jeśli plik marka urządzenia dziedziczy z tego pliku, nie musisz jawnie 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 linker, sh i toybox zostaną zainstalowane w aplikacji $ANDROID_PRODUCT_OUT/recovery/root/system/bin, a następnie w /system/bin w ramach vendor_ramdisk.

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

PRODUCT_PACKAGES += adbd.recovery

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

Suma kontrolna metadanych

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

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

Odpowiedni przykład znajdziesz na tej liście zmian.

Wirtualna kompresja A/B

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

Zmiany w procesie uruchamiania

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

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

Zasoby są przenoszone z ogólnego dysku RAM do dysku ramdy vendor_boot, więc wynik połączenia ogólnego z ramdykiem vendor_boot nie ulegnie zmianie.

Udostępnianie e2fsck

Pliki make urządzenia mogą dziedziczyć z:

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

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

Instalacja plików make produktu:$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck W czasie wykonywania pierwszego etapu init root przechodzi w /first_stage_ramdisk, a następnie wykonuje /system/bin/e2fsck.

Opcja 2a: partycja dedykowana i partycja odzyskiwania A/B

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

AB_OTA_PARTITIONS += recovery

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

  • Pliki fstab na urządzeniu

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

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

Ustawianie wartości BOARD

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

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

Dysk RAM recovery może zawierać dowiązanie symboliczne /init -> /system/bin/init i init_second_stage.recovery w /system/bin/init. Ponieważ jednak dysk RAM dysku rozruchowego jest połączony po elemencie recovery, dowiązanie symboliczne /init zostanie zastąpione. Gdy urządzenie uruchamia się w trybie przywracania, do obsługi inicjowania drugiego etapu potrzebny jest plik binarny /system/bin/init.

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

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

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

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

Przenoszenie plików fstab

Przenieś wszystkie zainstalowane pliki fstab do ogólnego dysku RAM do folderu vendor_ramdisk. Przykładem takiej zmiany jest ta.

Instalowanie modułów

Opcjonalnie możesz zainstalować na vendor_ramdisk moduły przeznaczone dla konkretnego urządzenia (pomiń ten krok, jeśli nie masz żadnych modułów do zainstalowania). Init nie przełącza użytkownika na poziomie roota. Wersja vendor_ramdisk modułów jest instalowana w root vendor_ramdisk. Przykłady instalowania modułów w vendor_ramdisk znajdziesz w sekcjach Konsola pierwszego etapu, sumy kontrolne metadanych i wirtualna kompresja A/B.

Konsola pierwszego etapu

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu linker, sh i toybox zostaną zainstalowane w aplikacji $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, a następnie w /system/bin w ramach vendor_ramdisk.

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Suma kontrolna metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu podłączania, urządzenia, które nie obsługują GKI, zainstaluj wersję ramdysków poniższych modułów. Aby dodać obsługę GKI, przenieś moduły do folderu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

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

Przykładem takiej listy jest ta lista zmian.

Wirtualna kompresja A/B

Aby obsługiwać wirtualną kompresję A/B, w vendor_ramdisk musisz zainstalować snapuserd. Urządzenie powinno dziedziczyć ustawienia z 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. vendor_boot + genericzna pamięć RAM jest podobna do obecnego procesu uruchamiania, z tym że fstab ładuje się z vendor_boot. Ponieważ system/bin/recovery nie istnieje, first_stage_init obsługuje to jako normalny rozruch.

Podczas uruchamiania w trybie odzyskiwania proces uruchamiania się zmienia. Tryb odzyskiwania + vendor_boot + ogólny dysk RAM jest podobny do dotychczasowego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot, a nie recovery. Proces uruchamiania trybu odzyskiwania wygląda następująco.

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

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

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

  3. Rozpoczyna się pierwszy etap, a potem:

    1. Ustawia wartości 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 pamięci ramdisk (ponieważ / jest nadal taki sam), ale wywołuje funkcję SetInitAvbVersionInRecovery()).
    4. Rozpoczyna się drugi etap inicjalizacji z poziomu /system/bin/init na dysku RAM recovery.

Udostępnij e2fsck

Pliki make urządzenia mogą dziedziczyć z:

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

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

Plik Makerfiles instaluje się $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. W czasie wykonywania pierwszy etap init wykonuje /system/bin/e2fsck.

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

Użyj tej opcji w przypadku urządzeń z partycją recovery bez partycji A/B, czyli z partycją o nazwie recovery bez sufiksu slotu. Do takich urządzeń należą:

  • urządzenia inne niż A/B;
  • Wirtualne urządzenia A/B i urządzenia wirtualne A/B, których partycja odzyskiwania nie może być aktualizowana. (To nietypowa sytuacja).

Dysk ramdisk vendor_boot zawiera bity systemu dostawcy pamięci RAM i modułu jądra dostawcy, w tym:

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

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

  • Obraz jądra
  • Obraz DTBO
  • Moduły jądra w lib/modules
  • Inicjalizacja pierwszego etapu jako skrót /init -> /system/bin/init
  • Drugoetapowa kompilacja binarna inicjalizacji /system/bin/init
  • Pliki fstab dotyczące konkretnego urządzenia
  • wszystkie inne zasoby do odzyskiwania danych, w tym plik recovery w formie binarnej.

Na takich urządzeniach konfiguracja produktu przejmuje 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

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

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

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

Po uruchomieniu urządzenia z Androidem zawartość pliku vendor_boot + ogólne pliki pamięci RAM jest taka:

  • /init (z dysku RAM, utworzone z init_first_stage)

Przenoszenie plików fstab

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

Zainstaluj moduły

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

Konsola pierwszego etapu

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Dzięki temu linker, sh i toybox zostaną zainstalowane w aplikacji $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, a następnie w /system/bin w ramach vendor_ramdisk.

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Dzięki temu określone moduły zostaną zainstalowane w $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin.

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

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

Suma kontrolna metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu podłączania, urządzenia, które nie obsługują GKI, zainstaluj wersję ramdysków 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 wariant przywracania tych modułów i również je zainstaluj.

Zmiany w procesie rozruchu

Podczas uruchamiania Androida proces uruchamiania się nie zmienia. vendor_boot + genericzna pamięć RAM jest podobna do obecnego procesu uruchamiania, z tym że fstab ładuje się z vendor_boot. Ponieważ system/bin/recovery nie istnieje, first_stage_init obsługuje to jako normalny rozruch.

W przypadku uruchomienia w trybie przywracania proces uruchamiania się nie zmienia. Dysk pamięci RAM jest wczytywany w taki sam sposób jak istniejący proces przywracania. Kernel jest ładowany 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. Przesyłanie dysku odzyskiwania do /.
    2. Uruchamia jądro z partycji recovery.

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

  3. Rozpoczyna się pierwszy etap, a potem:

    1. Ustawia wartości 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 pamięci ramdisk (ponieważ / jest nadal taki sam), ale wywołuje funkcję SetInitAvbVersionInRecovery()).
    4. Rozpoczyna się drugi etap inicjalizacji z poziomu /system/bin/init na dysku RAM recovery.

Sygnatury czasowe obrazu rozruchowego

Poniżej znajduje się przykładowy plik sygnatury czasowej obrazu boot:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

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

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