Miękkie restarty

Android 11 obsługuje miękkie restarty, czyli restarty procesów w przestrzeni użytkownika używane do stosowania aktualizacji wymagających ponownego uruchomienia (na przykład aktualizacji pakietów APEX). Obecnie miękki restart ogranicza się do procesów, które rozpoczęły się po zamontowaniu userdata .

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

  • Z PowerManager , wywołując PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Z powłoki, używając adb shell svc power reboot userspace lub adb reboot userspace

Po miękkim ponownym uruchomieniu pamięć zaszyfrowana poświadczeniami pozostaje odblokowana.

Jeśli urządzenie obsługuje miękkie restarty, metoda 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 miękkich restartów, wywołania PowerManager.reboot(PowerManager.REBOOT_USERSPACE) , adb reboot userspace i adb shell svc power reboot userspace nie powiodą się.

Wykonanie miękkiego restartu

Po zażądaniu miękkiego restartu (przez PowerManager lub z powłoki), init wykonuje następujące kroki:

  1. Otrzymuje sys.powerctl=reboot,userspace .

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

  3. Wyzwala akcję userspace-reboot-requested , która resetuje wszystkie właściwości systemu, które mogą mieć wpływ na miękki restart. Dotknięte właściwości:

    • 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

    Powyższe właściwości należy ustawić ponownie podczas sekwencji rozruchowej. W razie potrzeby możesz zresetować dodatkowe właściwości. Przykłady można znaleźć w akcji on userspace-reboot-requested w rootdir/init.rc .

  4. Uruchamia funkcję DoUserspaceReboot , która wykonuje następujące działania:

    1. Wysyła SIGTERM do procesów uruchomionych po zamontowaniu userdata i czeka na ich zatrzymanie.
    2. Po osiągnięciu limitu czasu wysyła sygnał SIGKILL , aby zabić wszystkie uruchomione procesy.
    3. Wywołuje /system/bin/vdc volume reset .
    4. Odmontowuje urządzenie bazowe zRAM.
    5. Odmontowuje aktywne pakiety APEX.
    6. Przełącza z powrotem do przestrzeni nazw montowania bootstrap.
    7. Wyzwala akcję userspace-reboot-resume .

Jeśli przed miękkim restartem zażądano punktu kontrolnego systemu plików, userdata są ponownie montowane w trybie punktów kontrolnych podczas akcji userspace-reboot-fs-remount (szczegółowe informacje znajdują się w poniższej sekcji). Miękki restart jest brany pod uwagę po ustawieniu sys.boot_completed property na 1 . Po zakończeniu miękkiego restartu wyświetlacz pozostaje wyłączony i do jego wybudzenia wymagana jest wyraźna interakcja użytkownika.

Punkt kontrolny systemu plików

Jeśli przed miękkim restartem zażądano punktu kontrolnego systemu plików, podczas miękkiego restartu userdata są ponownie montowane w trybie punktów kontrolnych. Logika ponownego montowania jest zaimplementowana w funkcji fs_mgr_remount_userdata_into_checkpointing i różni się w zależności od metody punktu kontrolnego. W szczególności, gdy userdata obsługują:

  • Punkty kontrolne na poziomie systemu plików (na przykład f2fs ), userdata są ponownie montowane za pomocą opcji checkpoint=disable .

  • Punkt kontrolny na poziomie bloku (na przykład ext4 ), następnie /data jest odłączany i wszystkie urządzenia mapujące urządzenia nadrzędne, na których był zamontowany, zostają zniszczone. Następnie userdata są montowane przy użyciu tej samej ścieżki kodu, która jest używana podczas normalnego rozruchu z punktu kontrolnego.

Jeśli do zarządzania kluczami zaszyfrowanymi poświadczeniami (CE) i kluczami zaszyfrowanymi na urządzeniu (DE) używany jest zbiór kluczy na poziomie systemu plików, klucze zostaną utracone po odmontowaniu userdata . Aby umożliwić przywrócenie klucza, podczas instalowania klucza w zbiorze kluczy systemu plików, vold instaluje również ten sam klucz typu fscrypt-provisioning w zbiorze kluczy na poziomie sesji. Po wywołaniu init_user0 vold ponownie instaluje klucze w zbiorze kluczy systemu plików.

Powrót do twardego restartu

Aby mieć pewność, że miękki restart nie pozostawi urządzenia w stanie bezużytecznym, Android 11 umożliwia powrót do twardego restartu, który jest uruchamiany, gdy spełniony jest jeden z następujących warunków:

  • Urządzenie nie uruchamia miękkiego restartu (tzn. sys.init.userspace_reboot.in_progress=1 ) w określonym czasie.
  • Proces nie zostaje zatrzymany w określonym czasie.
  • Operacja /system/bin/vdc volume reset nie powiodła się.
  • Odmontowanie urządzenia zRAM nie powiodło się.
  • Aktywny pakiet APEX odmontowuje się nieprawidłowo.
  • Próba ponownego zamontowania userdata w trybie punktu kontrolnego nie powiodła się.
  • Urządzenie nie uruchamia się pomyślnie (tzn. sys.boot_completed=1 ) w określonym czasie.

Konfiguracja dla poszczególnych urządzeń

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

  • init.userspace_reboot.is_supported kontroluje, kiedy urządzenie może wykonać miękki restart. Jeśli wartość tej właściwości to false , 0 lub nie została określona, ​​wówczas próby ponownego uruchomienia zostaną odrzucone.
  • init.userspace_reboot.sigkill.timeoutmillis kontroluje limit czasu w milisekundach dla procesów, które otrzymały sygnał SIGKILL do zatrzymania. Jeśli jeden z procesów nie zatrzyma się w określonym czasie, zostanie uruchomiony powrót do twardego restartu.
  • init.userspace_reboot.sigterm.timeoutmillis kontroluje limit czasu w milisekundach dla procesów, które otrzymały sygnał SIGTERM , aby zakończyć. Wszystkie procesy, które nie zakończyły się w określonym czasie, otrzymują sygnał SIGKILL .
  • init.userspace_reboot.started.timeoutmillis kontroluje limit czasu w milisekundach dla rozpoczęcia miękkiego restartu (tzn. sys.init.userspace_reboot.in_progress=1 ). Jeśli urządzenie nie uruchomi miękkiego restartu w określonym czasie, zostanie uruchomiony powrót do twardego restartu.
  • init.userspace_reboot.userdata_remount.timeoutmillis kontroluje limit czasu w milisekundach do odmontowania userdata . Jeśli urządzenie nie odmontuje userdata w określonym czasie, zostanie uruchomiony powrót do twardego restartu.
  • init.userspace_reboot.watchdog.timeoutmillis kontroluje limit czasu potrzebny do pomyślnego uruchomienia urządzenia (tzn. sys.boot_completed=1 ). Jeśli urządzenie nie uruchomi się w określonym czasie, zostanie uruchomiony twardy restart.

Dostosuj animację podczas miękkiego restartu

Referencyjna implementacja miękkiego restartu obejmuje możliwość dostosowania animacji wyświetlanej podczas miękkiego restartu.

Po zakończeniu akcji userspace-reboot-fs-remount init uruchamia usługę bootanim . Ta usługa sprawdza obecność następujących plików 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 dotyczących miękkiego restartu, bootanim wyświetli domyślną animację android .

Testowanie

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