Łagodne ponowne uruchomienie (

Android 11 obsługuje miękkie ponowne uruchomienia, czyli uruchomienia w czasie działania procesów w przestrzeni użytkownika używanych do stosowania aktualizacji, które wymagają ponownego uruchomienia (np. aktualizacji pakietów APEX). Obecnie miękki restart jest ograniczony do procesów, które zostały uruchomione po zamontowaniu userdata.

Żądanie ponownego uruchomienia jest wymagane w następujący sposób:

  • Z PowerManager przez wywołanie funkcji PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • W powłoce za pomocą poleceń adb shell svc power reboot userspace lub adb reboot userspace

Po miękkim ponownym uruchomieniu szyfrowane miejsce na dane logowania pozostaje odblokowane.

Jeśli urządzenie obsługuje miękki restart, metoda interfejsu API PowerManager.isRebootingUserspace() zwraca true, a wartość właściwości systemowej init.userspace_reboot.is_supported jest równa 1.

Jeśli urządzenie nie obsługuje łagodnego restartu, wywołania PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace i adb shell svc power reboot userspace kończą się niepowodzeniem.

Miękki restart wykonania

Po zażądaniu ponownego uruchomienia (za pomocą PowerManager lub powłoki) init wykonuje te czynności:

  1. Otrzymuje sys.powerctl=reboot,userspace.

  2. Tworzy osobny proces UserspaceRebootWatchdogThread() do monitorowania miękkiego restartu.

  3. Wywołuje działanie userspace-reboot-requested, które resetuje wszystkie właściwości systemu, które mogą mieć wpływ na miękki restart. Usługi, których dotyczy problem:

    • sys.usb.config
    • sys.usb.state
    • sys.boot_completed
    • dev.bootcomplete
    • sys.init.updatable_crashing
    • sys.init.updatable_crashing_process_name
    • apexd.status
    • sys.user.0.ce_available
    • sys.shutdown.requested
    • service.bootanim.exit

    Właściwości te powinny zostać ponownie ustawione podczas sekwencji uruchamiania. W razie potrzeby możesz zresetować dodatkowe właściwości. Przykłady znajdziesz w sekcji dotyczącej działania on userspace-reboot-requested w rootdir/init.rc.

  4. Uruchamia funkcję DoUserspaceReboot, która wykonuje te czynności:

    1. Wysyła SIGTERM do procesów rozpoczętych po podłączeniu elementu userdata i czeka na ich zatrzymanie.
    2. Po upływie limitu czasu wysyła SIGKILL, aby zakończyć wszystkie procesy.
    3. Dzwoni /system/bin/vdc volume reset.
    4. Odłącza urządzenie obsługujące zRAM.
    5. Odmontuje aktywne pakiety APEX.
    6. Przełącza z powrotem na przestrzeń nazw wczytywania.
    7. Wywołuje działanie userspace-reboot-resume.

Jeśli przed miękkim restartem systemu została przesłana prośba o zaznaczenie punktu kontrolnego w systemie plików, userdata zostanie ponownie zamontowany w trybie punktu kontrolnego podczas działania userspace-reboot-fs-remount (szczegóły znajdziesz w następującej sekcji). Ponowne uruchomienie oprogramowania jest rozpatrywane po ustawieniu parametru sys.boot_completed property na 1. Po zakończeniu miękkiego restartu wyświetlacz pozostaje wyłączony i do jego włączenia wymagana jest interakcja użytkownika.

Punkty kontrolne systemu plików

Jeśli przed rozpoczęciem nietrwałego ponownego uruchomienia zażądano punktu kontrolnego systemu plików, interfejs userdata zostanie ponownie podłączony w trybie punktu kontrolnego podczas przenoszenia do kosza. Logika ponownego montażu jest implementowana w funkcji fs_mgr_remount_userdata_into_checkpointing i różni się w zależności od metody punktowania. W szczególności, gdy userdata obsługuje:

  • Punkt kontrolny na poziomie systemu plików (na przykład f2fs), userdata jest ponownie montowany z opcją checkpoint=disable.

  • Punkty kontrolne na poziomie bloku (na przykład ext4), a następnie /data jest odmontowywany i wszystkie nadrzędne urządzenia mapujące, na których był zamontowany, są niszczone. Następnie userdata jest montowany przy użyciu tej samej ścieżki kodu, która jest używana podczas normalnego uruchamiania z punktem kontrolnym.

Jeśli do zarządzania kluczami szyfrowanymi za pomocą poświadczeń (CE) i kluczami szyfrowanymi na urządzeniu (DE) używany jest kluczyk na poziomie systemu plików, klucze te zostaną utracone po odmontowaniu userdata. Aby umożliwić przywracanie klucza, podczas instalowania klucza w kluczniku systemu plików voldinstaluje również ten sam klucz typu fscrypt-provisioning w kluczniku na poziomie sesji. Po wywołaniu funkcji init_user0 vold ponownie instaluje klucze w pęku kluczy systemu plików.

Uruchom ponownie z wykorzystaniem twardego resetu

Aby upewnić się, że miękki restart nie spowoduje, że urządzenie będzie nieużyteczne, Android 11 zawiera opcję twardego restartu, która jest uruchamiana, gdy spełnione jest jedno z tych warunków:

  • urządzenie nie może rozpocząć miękkiego restartu (czyli sys.init.userspace_reboot.in_progress=1) w określonym czasie;
  • Proces nie zatrzymuje się w określonym czasie.
  • Operacja /system/bin/vdc volume reset zakończyła się niepowodzeniem.
  • Nie udało się odmontować urządzenia zRAM.
  • Aktywny pakiet APEX jest nieprawidłowo odłączany.
  • Nie udaje się ponownie zamontować userdata w trybie punktowania.
  • urządzenie nie uruchamia się (czyli sys.boot_completed=1) w określonym czasie;

Konfiguracja dla poszczególnych urządzeń

Niektóre aspekty miękkiego restartu można dostosować, zmieniając wartości tych właściwości:

  • init.userspace_reboot.is_supported określa, kiedy urządzenie może uruchomić urządzenie ponownie. Jeśli wartość tej właściwości to false, 0 lub nieokreślona, próby ponownego uruchomienia są odrzucane.
  • init.userspace_reboot.sigkill.timeoutmillis określa czas oczekiwania w milisekundach dla procesów, które otrzymały sygnał SIGKILL, aby się zatrzymać. Jeśli jeden z procesów nie zostanie zatrzymany w określonym czasie, zostanie uruchomione twarde ponowne uruchomienie.
  • init.userspace_reboot.sigterm.timeoutmillis określa czas oczekiwania w milisekundach na zakończenie procesów, które otrzymały sygnał SIGTERM. Wszystkie procesy, które nie zostały zakończone w danym czasie oczekiwania, otrzymują sygnał SIGKILL.
  • Funkcja init.userspace_reboot.started.timeoutmillis określa w milisekundach czas oczekiwania na uruchomienie łagodnego ponownego uruchamiania (sys.init.userspace_reboot.in_progress=1). Jeśli urządzenie nie uruchomi się ponownie w określonym czasie, zostanie uruchomione twardy restart.
  • init.userspace_reboot.userdata_remount.timeoutmillis określa czas oczekiwania (w milisekundach) na odmontowanie userdata. Jeśli urządzenie nie może odmontować userdataw określonym czasie, uruchamia się twardy restart.
  • init.userspace_reboot.watchdog.timeoutmillis określa czas oczekiwania na uruchomienie urządzenia (czyli sys.boot_completed=1). Jeśli urządzenie nie uruchomi się w określonym czasie, nastąpi twarde ponowne uruchomienie.

Dostosowywanie animacji podczas miękkiego restartu

Referencyjna implementacja łagodnego restartu obejmuje możliwość dostosowania animacji wyświetlanej podczas tego procesu.

Pod koniec działania userspace-reboot-fs-remount usługa init uruchamia usługę bootanim. Ta usługa sprawdza, czy istnieją te pliki animacji w podanej kolejności, i odtwarza pierwszy znaleziony plik:

  • /product/media/userspace-reboot.zip
  • /oem/media/userspace-reboot.zip
  • /system/media/userspace-reboot.zip

Jeśli nie określono plików animacji do łagodnego restartu, bootanim wyświetla domyślną animację android.

Testowanie

Android 11 zawiera referencyjną implementację miękkiego restartu. Możesz też zweryfikować miękki restart za pomocą testów CTS w UserspaceRebootHostTest.