Ogólna partycja rozruchowa

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

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

W przypadku aktualizacji urządzeń, które nadal korzystają z Androida 12 lub starszych wersji jądra, ogólny ramdysk pozostaje na swoim miejscu, bez konieczności tworzenia nowego obrazu init_boot .

Aby zbudować ogólny ramdysk, przenieś zasoby specyficzne dla dostawcy z ramdysku w taki sposób, aby ogólny ramdysk zawierał tylko init pierwszego etapu 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 zostaną przeniesione z ogólnego RAMdysku do RAMdysku vendor_boot .

  • Należy używać dedykowanej partycji recovery . Nie są potrzebne żadne zmiany w ramdysku recovery , ponieważ ramdysk recovery jest samodzielny.

Architektura

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

Uruchom z Androidem 13, bez dedykowanego odzyskiwania

Uruchom/zaktualizuj urządzenie, GKI, bez dedykowanego odzyskiwania

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

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

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

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

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

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

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

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

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

Uruchom lub zaktualizuj system do Androida 12, bez dedykowanego odzyskiwania

Uruchom/zaktualizuj urządzenie, GKI, bez dedykowanego odzyskiwania

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

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

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

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

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

Uruchomienie lub uaktualnienie do systemu Android 12, dedykowane odzyskiwanie i przywracanie inne niż A/B (dedykowany dysk RAM)

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

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

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

Uaktualnij do Androida 12, odzyskiwanie podczas rozruchu (odzyskiwanie jako ramdysk)

Uruchom/zaktualizuj urządzenie, bez GKI, odzyskiwanie podczas rozruchu

Rysunek 7. Aktualizacja urządzeń do Androida 12, bez GKI, odzyskiwanie podczas rozruchu

Aktualizacja do Androida 12, dedykowane odzyskiwanie (dedykowany ramdysk)

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

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

Zawartość obrazów rozruchowych

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

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

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

  • Ogólny obraz boot

    • Wersja nagłówka V3 lub V4
      • boot_signature dla certyfikatu GKI boot.img (tylko wersja 4). Certyfikowany plik GKI boot.img nie jest podpisany w celu zweryfikowania rozruchu. Producenci OEM nadal muszą podpisać wstępnie skompilowany boot.img kluczem AVB specyficznym dla urządzenia.
      • Ogólna cmdline ( GENERIC_KERNEL_CMDLINE )
      • Jądro GKI
    • Ogólny obraz ramdysku
      • Uwzględniane tylko w obrazach boot z Androida 12 i wcześniejszych wersji

  • obraz vendor_boot (szczegółowe informacje można znaleźć w sekcji Partycje rozruchowe dostawcy )

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

  • obraz recovery

    • Wersja nagłówka V2
      • W razie potrzeby cmdline specyficznych dla urządzenia do odzyskiwania
      • W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielna; zobacz Obrazy odzyskiwania . Na przykład:
      • cmdline nie jest połączone z poleceniem boot i vendor_boot cmdline .
      • Nagłówek określa DTBO odzyskiwania, jeśli to konieczne.
      • W przypadku partycji odzyskiwania A/B zawartość może być łączona lub wywnioskowana z boot i vendor_boot . Na przykład:
      • cmdline jest połączone z poleceniami boot i vendor_boot cmdline .
      • Wartość DTBO można wywnioskować z nagłówka vendor_boot .
    • obraz ramdysku recovery
      • Zasoby odzyskiwania
      • W przypadku partycji odzyskiwania innej niż A/B zawartość ramdysku musi być samodzielna; zobacz Obrazy odzyskiwania . Na przykład:
      • lib/modules musi zawierać wszystkie moduły jądra wymagane do uruchomienia trybu odzyskiwania
      • Ramdysk odzyskiwania musi zawierać plik init .
      • W przypadku partycji odzyskiwania A/B ramdysk odzyskiwania jest dołączany do dysku ramdisku ogólnego i dysku vendor_boot , dlatego nie musi być samodzielny. Na przykład:
      • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do trybu przywracania rozruchu, oprócz modułów jądra w ramdysku vendor_boot .
      • Dowiązanie symboliczne w /init może istnieć, ale jest przyćmione przez plik binarny pierwszego stopnia /init w obrazie startowym.

Ogólna zawartość obrazu ramdysku

Ogólny ramdysk zawiera następujące komponenty.

  • init
  • Dodano system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build
  • Puste katalogi dla punktów podłączenia: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/
  • first_stage_ramdisk/
    • Zduplikowane puste katalogi dla punktów podłączenia: 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ść zmiennej tablicy logicznej musi być ciągiem znaków true lub być pusta (co jest ustawieniem domyślnym).

  • TARGET_NO_KERNEL . Ta zmienna wskazuje, czy kompilacja używa wstępnie skompilowanego obrazu rozruchowego. Jeśli ta zmienna jest ustawiona na true , ustaw BOARD_PREBUILT_BOOTIMAGE na lokalizację wstępnie zbudowanego obrazu rozruchowego ( BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img )

  • BOARD_USES_RECOVERY_AS_BOOT . Ta zmienna wskazuje, czy urządzenie używa obrazu recovery jako obrazu boot . Podczas korzystania z GKI ta zmienna jest pusta i zasoby odzyskiwania powinny zostać przeniesione do vendor_boot .

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

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

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . Ta zmienna kontroluje, czy zasoby odzyskiwania ramdysku są budowane w vendor_boot .

    • Po ustawieniu na true zasoby odzyskiwania są budowane tylko w vendor-ramdisk/ i nie są budowane w trybie recovery/root/ .

    • Gdy są puste, zasoby odzyskiwania są budowane tylko w trybie recovery/root/ i nie są budowane w vendor-ramdisk/ .

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . Ta zmienna kontroluje, czy klucze GSI AVB są zbudowane w vendor_boot .

    • Gdy ustawione na true , jeśli BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

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

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

    • Gdy pusty, jeśli BOARD_RECOVERY_AS_ROOT :

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

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

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . Ta zmienna kontroluje, czy obraz recovery zawiera jądro, czy nie. Urządzenia uruchamiane z systemem Android 12 i korzystające z partycji recovery A/B muszą ustawić tę zmienną na true . Urządzenia uruchamiane z systemem Android 12 i korzystające z systemu innego niż A/B muszą ustawić tę zmienną na false , aby obraz odzyskiwania był niezależny.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . Ta zmienna kontroluje, 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 kontroluje, czy generowany jest init_boot.img i ustawia jego rozmiar. Po ustawieniu ogólny ramdysk jest dodawany do init_boot.img zamiast boot.img i wymaga ustawienia zmiennych BOARD_AVB_INIT_BOOT* dla połączonego vbmeta

Dozwolone kombinacje

Składnik lub zmienna Aktualizacja urządzenia bez partycji recovery Aktualizacja urządzenia za pomocą partycji recovery Uruchom urządzenie bez partycji recovery Uruchom urządzenie z partycją recovery A/B Uruchom urządzenie z partycją recovery 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 opcjonalny opcjonalny Tak Tak Tak NIE
Zawiera recovery NIE Tak NIE Tak Tak NIE
BOARD_USES_RECOVERY_AS_BOOT true pusty pusty pusty pusty pusty
BOARD_USES_GENERIC_KERNEL_IMAGE pusty pusty true true true true
PRODUCT_BUILD_RECOVERY_IMAGE pusty true 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

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

Włącz łańcuchową vbmeta dla rozruchu

Dla obrazów boot i init_boot musi być włączona łańcuchowa vbmeta. Określ następujące 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

Na przykład odwołaj się do tej zmiany .

System jako root

System jako root nie jest obsługiwany w przypadku urządzeń korzystających z GKI. Na takich urządzeniach BOARD_BUILD_SYSTEM_ROOT_IMAGE musi być pusty. Opcja System-as-root również nie jest obsługiwana w przypadku urządzeń korzystających z partycji dynamicznych.

Konfiguracje produktu

Urządzenia korzystające z ogólnego ramdysku muszą zainstalować listę plików, które mogą być instalowane na ramdysku. Aby to zrobić, określ następujące elementy w device.mk :

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

generic_ramdisk.mk zapobiega także przypadkowemu zainstalowaniu innych plików na ramdysku przez inne pliki makefile (zamiast tego przenieś takie pliki do vendor_ramdisk ).

Konfigurowanie urządzeń

Instrukcje konfiguracji różnią się w przypadku urządzeń uruchamianych z Androidem 13, aktualizujących do Androida 12 i uruchamiających się z Androidem 12. Android 13 jest skonfigurowany podobnie jak w przypadku Androida 12

  • Urządzenia aktualizujące do Androida 12:

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

      • Ustaw BOARD_USES_RECOVERY_AS_BOOT na true , architektura jest pokazana na rysunku 3 .

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

    • Można ustawić BOARD_USES_RECOVERY_AS_BOOT na pusty. Jeśli to zrobią, użyją nowych konfiguracji. Jeżeli takie urządzenia:

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

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

  • Urządzenia uruchamiane z systemem Android 12 muszą ustawić BOARD_USES_RECOVERY_AS_BOOT na puste i korzystać z nowych konfiguracji. Jeżeli takie urządzenia:

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

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

Ponieważ aosp_arm64 buduje tylko GKI (a nie vendor_boot czy recovery), nie jest to kompletny cel. Informacje na temat konfiguracji kompilacji aosp_arm64 można znaleźć w generic_arm64 .

Opcja 1: Brak dedykowanej partycji odzyskiwania

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

Ustawianie wartości BOARD

Ustaw następujące wartości:

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

Ramdysk vendor_boot może zawierać dowiązanie symboliczne /init do /system/bin/init i init_second_stage.recovery w /system/bin/init . Jednakże, ponieważ ogólny ramdysk jest łączony po ramdysku vendor_boot , dowiązanie symboliczne /init zostaje nadpisane. Kiedy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init jest potrzebny do obsługi drugiego etapu init. Zawartość vendor_boot + ogólnych ramdysków jest następująca:

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

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab , które zostały zainstalowane na ogólnym ramdysku do vendor_ramdisk . Na przykład odwołaj się do tej zmiany .

Instalowanie modułów

W razie potrzeby 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 do zainstalowania).

  • Użyj wariantu modułu vendor_ramdisk , gdy moduł instaluje się na dysku /first_stage_ramdisk . Moduł ten powinien być dostępny po tym, jak init przełączy root na /first_stage_ramdisk , ale zanim init przełączy root na /system . Przykłady można znaleźć w artykule Sumy kontrolne metadanych i wirtualna kompresja A/B .

  • Użyj wariantu recovery modułu, gdy moduł instaluje się w / . Moduł ten powinien być dostępny zanim init przełączy root na /first_stage_ramdisk . Aby uzyskać szczegółowe informacje na temat instalowania modułów w / , zobacz Konsola pierwszego stopnia .

Konsola pierwszego stopnia

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

Aby jawnie zainstalować moduły odzyskiwania, użyj poniższych opcji.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Zapewnia to, że linker , sh i toybox zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/recovery/root/system/bin , który następnie zostanie zainstalowany w /system/bin na dysku vendor_ramdisk .

Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), użyj poniższego polecenia.

PRODUCT_PACKAGES += adbd.recovery

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

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia nie obsługujące GKI instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin :

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

Na przykład zapoznaj się z tą listą zmian .

Wirtualna kompresja A/B

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

Zmiany w procesie uruchamiania

Proces uruchamiania w trybie odzyskiwania lub w systemie Android nie ulega zmianie, z następującym wyjątkiem:

  • Ramdysk build.prop przenosi się do /second_stage_resources , dzięki czemu init drugiego etapu może odczytać znacznik czasu kompilacji rozruchu.

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

Udostępnienie e2fsck

Pliki makefile urządzenia mogą dziedziczyć z:

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

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

Pliki Makefile produktu instalują $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck . W czasie wykonywania pierwszy etap init przełącza katalog główny na /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 recovery A/B; oznacza to, że urządzenie ma partycję recovery_a i recovery_b partition . Do takich urządzeń zaliczają się urządzenia A/B i wirtualne A/B, których partycję odzyskiwania można aktualizować, w następującej konfiguracji:

AB_OTA_PARTITIONS += recovery

Ramdysk_rozruchowy vendor_boot zawiera bity dostawcy ramdysku i modułów jądra dostawcy, w tym:

  • Pliki fstab specyficzne dla urządzenia

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

Ramdysk recovery zawiera wszystkie zasoby odzyskiwania. Na takich urządzeniach konfiguracja produktu dziedziczy z generic_ramdisk.mk .

Ustawianie wartości BOARD

Ustaw następujące wartości dla urządzeń z partycją recovery A/B:

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

Ramdysk recovery może zawierać dowiązanie symboliczne /init -> /system/bin/init i init_second_stage.recovery w /system/bin/init . Ponieważ jednak ramdysk rozruchowy jest łączony po ramdysku recovery , dowiązanie symboliczne /init zostaje nadpisane. Gdy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init jest potrzebny do obsługi drugiego etapu init.

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

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

Gdy urządzenie uruchamia się w systemie Android, zawartość ramdysku vendor_boot + ogólne jest następująca:

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

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab , które zostały zainstalowane na ogólnym ramdysku do vendor_ramdisk . Na przykład odwołaj się do tej zmiany .

Instalowanie modułów

W razie potrzeby 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 do zainstalowania). Init nie przełącza roota. Wariant modułów vendor_ramdisk instaluje się w katalogu głównym vendor_ramdisk . Przykłady instalowania modułów na vendor_ramdisk można znaleźć w artykułach Konsola pierwszego stopnia , Sumy kontrolne metadanych i Wirtualna kompresja A/B .

Konsola pierwszego stopnia

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Zapewnia to, że linker , sh i toybox zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , który następnie zostanie zainstalowany w /system/bin w obszarze vendor_ramdisk .

Aby dodać moduły potrzebne do konsoli pierwszego stopnia (na przykład adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie użyj poniższych poleceń:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia nie obsługujące GKI instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

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

Na przykład zapoznaj się z tą listą zmian .

Wirtualna kompresja A/B

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

Zmiany w procesie uruchamiania

Podczas uruchamiania systemu Android proces uruchamiania nie ulega zmianie. vendor_boot + ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z tą różnicą, ż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 ulega zmianie. Odzyskiwanie + vendor_boot + ogólny ramdysk jest podobny do istniejącego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot , a nie z obrazu recovery . Proces uruchamiania w trybie odzyskiwania jest następujący.

  1. Program ładujący zostanie uruchomiony, a następnie wykona następujące czynności:

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

  2. Jądro montuje ramdysk do / a następnie wykonuje polecenie /init z ogólnego ramdysku.

  3. Rozpoczyna się pierwszy etap inicjowania, po którym wykonywane są następujące czynności:

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

Udostępnienie e2fsck

Pliki makefile urządzenia mogą dziedziczyć z:

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

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

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

Opcja 2b: Dedykowana partycja odzyskiwania inna niż A/B

Użyj tej opcji w przypadku urządzeń z partycją recovery inną niż A/B; oznacza to, że urządzenie ma partycję o nazwie recovery bez przyrostka gniazda. Do takich urządzeń należą:

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

Ramdysk_rozruchowy vendor_boot zawiera bity dostawcy ramdysku i modułów jądra dostawcy, w tym:

  • Pliki fstab specyficzne dla urządzenia
  • lib/modules (zawiera moduły jądra dostawcy)

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

  • Obraz jądra
  • Obraz DTBO
  • Moduły jądra w lib/modules
  • Init pierwszego etapu jako dowiązanie symboliczne /init -> /system/bin/init
  • Binarny plik inicjujący drugiego stopnia /system/bin/init
  • Pliki fstab specyficzne dla urządzenia
  • Wszystkie inne zasoby odzyskiwania, w tym plik binarny recovery itp.
  • itp.

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

Ustawianie wartości BOARD

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

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

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

Po uruchomieniu urządzenia w trybie recovery zawartość ramdysków recovery jest następująca:

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

Gdy urządzenie uruchamia się w systemie Android, zawartość ramdysku vendor_boot + ogólne jest następująca:

  • /init (z ramdysku, zbudowany z init_first_stage )

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab , które zostały zainstalowane na ogólnym ramdysku do RAMdysku vendor_ramdisk i dysku recovery . Na przykład odwołaj się do tej zmiany .

Instalowanie modułów

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

Konsola pierwszego stopnia

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Zapewnia to, że linker , sh i toybox zostaną zainstalowane w katalogu $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , który następnie zostanie zainstalowany w /system/bin w obszarze vendor_ramdisk .

Aby dodać moduły potrzebne do konsoli pierwszego stopnia (na przykład adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie poprawki do AOSP, a następnie użyj poniższych poleceń:

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, zamień vendor_ramdisk na recovery :

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

Sumy kontrolne metadanych

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania, urządzenia nie obsługujące GKI instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

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

Aby obsługiwać sumy kontrolne metadanych podczas pierwszego etapu montowania w procesie odzyskiwania, włącz wariant odzyskiwania tych modułów i również je zainstaluj.

Zmiany w procesie uruchamiania

Podczas uruchamiania systemu Android proces uruchamiania nie ulega zmianie. vendor_boot + ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z tą różnicą, ż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 nie ulega zmianie. Ramdysk odzyskiwania jest ładowany w taki sam sposób, jak istniejący proces odzyskiwania. Jądro jest ładowane z obrazu recovery . Proces uruchamiania w trybie odzyskiwania jest następujący.

  1. Program ładujący zostanie uruchomiony, a następnie wykona następujące czynności:

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

  2. Jądro montuje ramdysk do / następnie wykonuje polecenie /init , które jest dowiązaniem symbolicznym do /system/bin/init z dysku RAM recovery .

  3. Rozpoczyna się pierwszy etap inicjowania, po którym wykonywane są następujące czynności:

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

Sygnatury czasowe obrazu rozruchowego

Poniższy kod jest przykładowym plikiem sygnatury czasowej obrazu boot .

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

  • W czasie kompilacji do ogólnego ramdysku dodawany jest plik system/etc/ramdisk/build.prop . Ten plik zawiera informacje o sygnaturze czasowej kompilacji.

  • W czasie wykonywania init pierwszego etapu kopiuje pliki z ramdysku do tmpfs przed zwolnieniem ramdysku, dzięki czemu init drugiego etapu może odczytać ten plik w celu ustawienia właściwości znacznika czasu obrazu boot .