Ogólna partycja rozruchowa

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

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

W przypadku aktualizacji urządzeń, które nadal korzystają z systemu Android 12 lub starszych wersji jądra, ogólny ramdysk pozostaje tam, gdzie był, bez wymogu 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 znacznikach czasu.

Na urządzeniach, które:

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

  • Użyj dedykowanej partycji recovery , nie jest wymagana żadna zmiana w ramdysku recovery , ponieważ ramdysk recovery jest samowystarczalny.

Architektura

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

Uruchom z systemem Android 13, bez dedykowanego odzyskiwania

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

Rysunek 1. Urządzenia uruchamiane lub aktualizowane do systemu Android 13 z GKI, bez dedykowanego odzyskiwania

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

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

Rysunek 2. Urządzenia uruchamiane lub aktualizowane do systemu Android 13 z GKI, odzyskiwaniem dedykowanym i A/B

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

Uruchom z systemem Android 13, odzyskiwanie dedykowane i inne niż A/B (dedykowany ramdysk)

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

Rysunek 3. Urządzenia uruchamiane lub aktualizowane do systemu Android 13, z GKI, dedykowanym i odzyskiwaniem innym niż A/B

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

Uruchom lub zaktualizuj do Androida 12, bez dedykowanego odzyskiwania

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

Rysunek 4. Urządzenia uruchamiane lub aktualizowane do systemu Android 12 z GKI, bez dedykowanego odzyskiwania

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

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

Rysunek 5. Urządzenia uruchamiane lub aktualizowane do systemu Android 12 z GKI, dedykowanym i odzyskiwaniem A/B

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

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

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

Rysunek 6. Urządzenia uruchamiane lub aktualizowane do systemu Android 12, z GKI, dedykowanym i odzyskiwaniem innym niż A/B

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

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

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

Rysunek 7. Urządzenia aktualizujące się do Androida 12, bez GKI, odzyskiwanie po uruchomieniu

Aktualizacja do Androida 12, dedykowane odzyskiwanie (dedykowany ramdysk)

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

Rysunek 8. Urządzenia aktualizujące się 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 do certyfikacji GKI boot.img (tylko wersja 4). Certyfikowany plik GKI boot.img nie jest podpisany dla zweryfikowanego rozruchu. Producenci OEM nadal muszą podpisywać gotowy plik boot.img kluczem AVB specyficznym dla urządzenia.
      • Ogólna cmdline ( GENERIC_KERNEL_CMDLINE )
      • Jądro GKI
    • Ogólny obraz ramdysku
      • Zawarte tylko w obrazach boot z Androida 12 i wcześniejszych

  • vendor_boot image (szczegółowe informacje można znaleźć w części Vendor Boot Partitions )

    • nagłówek vendor_boot
      • cmdline specyficzny 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
      • cmdline specyficzne dla urządzenia do odzyskiwania, jeśli to konieczne
      • W przypadku partycji odzyskiwania innej niż A/B zawartość nagłówka musi być samodzielna; zobacz Obrazy odzyskiwania . Na przykład:
      • cmdline nie jest połączona z boot i vendor_boot cmdline .
      • Nagłówek określa DTBO odzyskiwania, jeśli to konieczne.
      • W przypadku partycji odzyskiwania A/B zawartość można połączyć lub wywnioskować z boot i vendor_boot . Na przykład:
      • cmdline jest połączone z boot i vendor_boot cmdline .
      • 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ć init .
      • W przypadku partycji odzyskiwania A/B, ramdysk odzyskiwania jest dołączany do ogólnego dysku ram i vendor_boot , dlatego nie musi być autonomiczny. Na przykład:
      • lib/modules może zawierać tylko dodatkowe moduły jądra wymagane do uruchomienia trybu odzyskiwania oprócz modułów jądra w ramdysku vendor_boot .
      • Dowiązanie symboliczne w /init może istnieć, ale jest przyćmione przez plik binarny pierwszego etapu /init w obrazie rozruchowym.

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 montowania: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/
  • first_stage_ramdisk/
    • Zduplikowane puste katalogi dla punktów montowania: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

Integracja obrazu rozruchowego

Flagi kompilacji kontrolują sposób tworzenia obrazów init_boot , boot , recovery i vendor_boot . Wartość boolowskiej zmiennej planszowej musi być łańcuchem znaków true lub być pusta (co jest wartością domyślną).

  • 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 skompilowanego 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, a zasoby odzyskiwania należy przenieść do vendor_boot .

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

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

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

    • W przypadku ustawienia wartości true zasoby odzyskiwania są budowane tylko na vendor-ramdisk/ i nie są budowane na recovery/root/ .

    • Gdy jest pusta, 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ą budowane na vendor_boot .

    • Po ustawieniu na true , jeśli BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

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

      • Jest nieskonfigurowany, klucze GSI AVB są zbudowane na $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb .

    • Gdy jest pusty, jeśli BOARD_RECOVERY_AS_ROOT :

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

      • Jest nieskonfigurowany, 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 używające funkcji innej niż A/B muszą ustawić tę zmienną na false , aby obraz odzyskiwania był samowystarczalny.

  • 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 init_boot.img jest generowany i określa 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 powiązanej vbmeta

Dozwolone kombinacje

Składnik lub zmienna Aktualizowanie urządzenia bez partycji recovery Aktualizowanie 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ą. Dla tych urządzeń, jeśli ustawiono BOARD_RECOVERYIMAGE_PARTITION_SIZE , tworzony jest obraz recovery .

Włącz połączoną vbmeta do rozruchu

Łańcuch vbmeta musi być włączony dla obrazów boot i init_boot . 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

Przykład można znaleźć w tej zmianie .

System jako root

System-as-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. System-as-root również nie jest obsługiwany w przypadku urządzeń korzystających z partycji dynamicznych.

Konfiguracje produktów

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

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

Plik generic_ramdisk.mk zapobiega również przypadkowemu instalowaniu innych plików na ramdysku przez inne pliki makefile (zamiast tego przenieś takie pliki do vendor_ramdisk ).

Konfigurowanie urządzeń

Instrukcje konfiguracji różnią się między urządzeniami uruchamianymi z systemem Android 13, aktualizacją do systemu Android 12 i uruchamianiem z systemem Android 12. Konfiguracja systemu Android 13 jest podobna do konfiguracji systemu Android 12

  • Urządzenia uaktualniające do Androida 12:

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

      • Ustaw BOARD_USES_RECOVERY_AS_BOOT na true , architektura jest 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 puste. Jeśli to robią, używają nowych konfiguracji. Jeśli takie urządzenia:

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

      • Użyj dedykowanej partycji recovery , architektura jest taka, jak pokazano 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 pustą i korzystać z nowych konfiguracji. Jeśli takie urządzenia:

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

    • Użyj dedykowanej partycji recovery , architektura jest taka, jak pokazano 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 lub odzyskiwanie), nie jest to kompletny cel. Aby zapoznać się z konfiguracjami kompilacji aosp_arm64 , zapoznaj się z generic_arm64 .

Opcja 1: Brak dedykowanej partycji odzyskiwania

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

Ustawianie wartości BOARD

Ustaw następujące wartości:

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

Ramdysk vendor_boot może zawierać dowiązanie symboliczne /init do /system/bin/init oraz init_second_stage.recovery w /system/bin/init . Ponieważ jednak ogólny ramdysk jest łączony po ramdysku vendor_boot , dowiązanie symboliczne /init jest zastępowane. Gdy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init jest potrzebny do obsługi drugiego etapu init. Zawartość vendor_boot + ogólne ramdyski 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ólny ramdysk do vendor_ramdisk . Przykład można znaleźć w tej zmianie .

Instalowanie modułów

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

  • Użyj wariantu vendor_ramdisk modułu, gdy moduł jest instalowany na /first_stage_ramdisk . Ten moduł powinien być dostępny po tym, jak init przełączy roota na /first_stage_ramdisk , ale zanim init przełączy roota na /system . Aby zapoznać się z przykładami, zobacz Sumy kontrolne metadanych i Wirtualna kompresja A/B .

  • Użyj wariantu recovery modułu, gdy moduł jest instalowany w katalogu / . Ten moduł powinien być dostępny, zanim init przełączy root na /first_stage_ramdisk . Aby uzyskać szczegółowe informacje na temat instalowania modułów w / , zobacz Konsola pierwszego etapu .

Konsola pierwszego stopnia

Ponieważ konsola pierwszego etapu uruchamia się przed przełączeniem programu init na katalog główny /first_stage_ramdisk , należy 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 makefile urządzenia dziedziczy z tego pliku, nie trzeba jawnie instalować wariantu recovery .

Aby jawnie zainstalować moduły odzyskiwania, wykonaj następujące czynności.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

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

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

PRODUCT_PACKAGES += adbd.recovery

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

Sumy kontrolne metadanych

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

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

Przykład można znaleźć w tej liście 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 vendor_ramdisk snapuserd .

Zmiany w procesie rozruchu

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

  • Ramdysk build.prop przenosi się do /second_stage_resources , aby init drugiego etapu mógł odczytać znacznik czasu kompilacji rozruchu.

Ponieważ zasoby są przenoszone z ramdysku ogólnego do ramdysku vendor_boot , wynik łączenia ogólnego dysku ram z dyskiem ramdysku vendor_boot nie zmienia się.

Udostępnianie e2fsck

Makefile urządzeń 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 root na /first_stage_ramdisk a następnie wykonuje /system/bin/e2fsck .

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

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

AB_OTA_PARTITIONS += recovery

Ramdysk 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 dysk rozruchowy jest łączony po dysku recovery , dowiązanie symboliczne /init jest zastępowane. Gdy urządzenie uruchamia się w trybie odzyskiwania, plik binarny /system/bin/init jest potrzebny do obsługi drugiego etapu init.

Gdy urządzenie uruchamia się w trybie recovery , zawartość recovery + vendor_boot + ogólne ramdyski 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 system Android, zawartość vendor_boot + ogólne ramdyski są następujące:

  • /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ólny ramdysk do vendor_ramdisk . Przykład można znaleźć w tej zmianie .

Instalowanie modułów

Jeśli chcesz, możesz zainstalować moduły specyficzne dla urządzenia na vendor_ramdisk (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). Init nie zmienia roota. Wariant vendor_ramdisk modułów instaluje się w katalogu głównym vendor_ramdisk . Aby zapoznać się z przykładami instalowania modułów na vendor_ramdisk , zobacz Konsola pierwszego etapu , Sumy kontrolne metadanych i Wirtualna kompresja A/B .

Konsola pierwszego stopnia

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie łatki do AOSP, a następnie użyj następujących:

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

Sumy kontrolne metadanych

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

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

Przykład można znaleźć w tej liście 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 vendor_ramdisk snapuserd .

Zmiany w procesie rozruchu

Podczas uruchamiania systemu Android proces uruchamiania się nie zmienia. vendor_boot + ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z wyjątkiem tego, że fstab ładuje się z vendor_boot . Ponieważ system/bin/recovery nie istnieje, first_stage_init obsługuje to jako normalny rozruch.

Podczas uruchamiania w trybie odzyskiwania proces uruchamiania zmienia się. Recovery + vendor_boot + ogólny ramdysk jest podobny do istniejącego procesu odzyskiwania, ale jądro jest ładowane z obrazu boot zamiast z obrazu recovery . Proces uruchamiania w trybie odzyskiwania jest następujący.

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

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

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

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

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

Udostępnianie e2fsck

Makefile urządzeń 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 i nie-A/B partycja odzyskiwania

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

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

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

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

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

  • Obraz jądra
  • Obraz DTBO
  • Moduły jądra w lib/modules
  • Init pierwszego etapu jako dowiązanie symboliczne /init -> /system/bin/init
  • Init binarny drugiego etapu /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.

Gdy urządzenie uruchamia się 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 system Android, zawartość vendor_boot + ogólne ramdyski są następujące:

  • /init (z ramdysku, zbudowany z init_first_stage )

Przenoszenie plików fstab

Przenieś wszystkie pliki fstab , które zostały zainstalowane na ogólny ramdysk do vendor_ramdisk i recovery ramdysk. Przykład można znaleźć w tej zmianie .

Instalowanie modułów

Jeśli chcesz, możesz zainstalować moduły specyficzne dla urządzenia na vendor_ramdisk i recovery ramdisk (pomiń ten krok, jeśli nie masz żadnych modułów specyficznych dla urządzenia do zainstalowania). init nie zmienia roota. Wariant vendor_ramdisk modułów instaluje się w katalogu głównym vendor_ramdisk . Wariant recovery modułów jest instalowany w katalogu głównym ramdysku recovery . Aby zapoznać się z przykładami instalowania modułów na dysku vendor_ramdisk i dysku recovery , zobacz Konsola pierwszego etapu i sumy kontrolne metadanych .

Konsola pierwszego stopnia

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

Aby dodać moduły potrzebne do konsoli pierwszego etapu (na przykład adbd), włącz wariant vendor_ramdisk tych modułów, przesyłając odpowiednie łatki do AOSP, a następnie użyj następujących:

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 montowania na pierwszym etapie, urządzenia, które nie obsługują GKI, instalują wariant ramdysku następujących modułów. Aby dodać obsługę GKI, przenieś moduły do $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

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

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

Zmiany w procesie rozruchu

Podczas uruchamiania systemu Android proces uruchamiania się nie zmienia. vendor_boot + ogólny ramdysk jest podobny do istniejącego procesu rozruchu, z wyjątkiem tego, że fstab ładuje się z vendor_boot . Ponieważ system/bin/recovery nie istnieje, first_stage_init obsługuje to jako normalny rozruch.

Podczas uruchamiania w trybie odzyskiwania proces uruchamiania nie zmienia się. 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. Bootloader uruchamia się, a następnie wykonuje następujące czynności:

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

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

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

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

Sygnatury czasowe obrazu rozruchowego

Poniższy kod to przykładowy plik sygnatury czasowej obrazu boot .

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

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

  • W czasie wykonywania pierwszy etap init kopiuje pliki z ramdysku do tmpfs przed zwolnieniem ramdysku, aby drugi etap init mógł odczytać ten plik i ustawić właściwości znacznika czasu obrazu boot .