Płynne ponowne uruchomienie

Android 11 obsługuje automatyczne ponowne uruchamianie, ponowne uruchomienia w czasie działania procesów w przestrzeni użytkownika używanej do stosowania aktualizacji, wymagają ponownego uruchomienia (np. aktualizacji pakietów APEX). Obecnie łagodny ponowne uruchamianie jest ograniczone do procesów, które rozpoczęły się po podłączeniu interfejsu userdata.

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

  • Połączenie od: PowerManager PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Z powłoki za pomocą polecenia adb shell svc power reboot userspace lub adb reboot userspace

Po łagodnym ponownym uruchomieniu magazyn zaszyfrowany z danymi uwierzytelniającymi pozostaje odblokowany.

Jeśli urządzenie obsługuje automatyczne ponowne uruchomienie, 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 ponownego uruchomienia, połączenia z numerem Nie udało się wykonać zadań PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace i adb shell svc power reboot userspace.

Wykonanie łagodnego restartu

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

  1. Otrzymuje sys.powerctl=reboot,userspace.

  2. Rozdziela osobny UserspaceRebootWatchdogThread() w celu monitorowania funkcji ponownego uruchamiania.

  3. Aktywuje działanie userspace-reboot-requested, które resetuje cały system właściwości, które mogą wpływać na ponowne uruchomienie. 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

    Powyższe właściwości powinny zostać ustawione ponownie podczas sekwencji uruchamiania. W razie potrzeby mogą zresetować dodatkowe właściwości. Przykłady znajdziesz tutaj: Działanie on userspace-reboot-requested w rootdir/init.rc

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

    1. Wysyła SIGTERM do procesów rozpoczętych po podłączeniu środowiska userdata i i czeka, aż przestaną działać.
    2. Po upływie czasu oczekiwania wysyła żądanie SIGKILL, aby zakończyć działanie wszystkich biegów
    3. Dzwoni /system/bin/vdc volume reset.
    4. Odinstalowuje urządzenie do tworzenia kopii zapasowej zRAM.
    5. Odłączanie aktywnych pakietów APEX.
    6. Przełącza się z powrotem na przestrzeń nazw podłączenia przy wczytywaniu wczytywania.
    7. Wyzwala userspace-reboot-resume działania.

Jeśli przed rozpoczęciem łagodnego ponownego uruchomienia wymagane jest sprawdzenie punktu kontrolnego systemu plików, Usługa userdata jest ponownie podłączona do trybu punktu kontrolnego podczas userspace-reboot-fs-remount (szczegóły znajdziesz w sekcji poniżej). O subtelne ponowne uruchomienie jest brane pod uwagę po ustawieniu funkcji sys.boot_completed property do: 1. Po zakończeniu łagodnego ponownego uruchamiania ekran pozostaje wyłączony, a Do wybudzenia wymagana jest wyraźna interakcja użytkownika.

Wskaźniki kontroli systemu plików

Jeśli przed rozpoczęciem przenoszenia do kosza zażądano punktu kontrolnego systemu plików, Platforma userdata została ponownie podłączona w trybie punktu kontrolnego podczas ponownego uruchamiania w trybie subtelnym. Logika ponownego podłączenia jest implementowana w fs_mgr_remount_userdata_into_checkpointing i różni się między metodami punktów kontrolnych. Konkretnie: userdata obsługuje:

  • Punktowanie kontrolne na poziomie systemu plików (np. f2fs), userdata to ponownie zamontowane za pomocą opcji checkpoint=disable.

  • Zablokuj punkt kontrolny na poziomie (np. ext4), a następnie /data jest odłączony a wszystkie urządzenia nadrzędne, na których była ona zainstalowana, są zniszczenia. Następnie usługa userdata jest podłączana przy użyciu tej samej ścieżki kodu, co w polu przy normalnym uruchamianiu z użyciem punktów kontrolnych.

Jeśli do zarządzania szyfrowanymi danymi uwierzytelniającymi (CE) używany jest pęk kluczy na poziomie systemu plików zaszyfrowanych przez urządzenie (DE) kluczy powoduje utratę kluczy po odłączeniu urządzenia userdata. Do zezwalanie na przywrócenie klucza, podczas instalowania klucza do pęku kluczy systemu plików, vold instaluje też ten sam klucz typu fscrypt-provisioning na poziomie sesji pęku kluczy. Po wywołaniu funkcji init_user0 vold ponownie instaluje klucze w pliku pęku kluczy.

Wróć do twardego restartu

Aby zagwarantować, że ponowne uruchomienie w tle nie pozostawi urządzenia w stanie bezużytecznym: Android 11 ma funkcję twardego restartu wyzwalane, gdy spełniony jest jeden z tych warunków:

  • Urządzenie nie uruchomi się do łagodnego ponownego uruchamiania (tzn. sys.init.userspace_reboot.in_progress=1) w określonym czasie.
  • Proces nie jest zatrzymywany w określonym czasie oczekiwania.
  • Operacja /system/bin/vdc volume reset kończy się niepowodzeniem.
  • Nie można odłączyć urządzenia zRAM.
  • Aktywny pakiet APEX jest nieprawidłowo odłączony.
  • Próba ponownego podłączenia instancji userdata w trybie punktu kontrolnego kończy się niepowodzeniem.
  • Nie można uruchomić urządzenia (tzn. sys.boot_completed=1) w danego czasu oczekiwania.

Konfiguracja dla poszczególnych urządzeń

Niektóre aspekty łagodnego ponownego uruchamiania można dostosować, zmieniając wartości tych wartości: właściwości:

  • init.userspace_reboot.is_supported określa, kiedy urządzenie może wykonywać ponowne uruchomienie w tle. Jeśli wartość tej właściwości to false, 0 lub nie została określona, to próby ponownego uruchomienia są odrzucane.
  • init.userspace_reboot.sigkill.timeoutmillis określa czas oczekiwania w milisekund na zatrzymanie procesów, które otrzymały sygnał SIGKILL. Jeśli jeden z proces nie jest zatrzymywany przez określony czas, po czym następuje przejście z jest uruchamiany ponownie.
  • init.userspace_reboot.sigterm.timeoutmillis określa czas oczekiwania w milisekundy dla procesów, które otrzymały sygnał SIGTERM do zakończenia. Wszystkie procesy, których nie udało się zakończyć w określonym czasie oczekiwania, otrzymują powiadomienie Sygnał SIGKILL.
  • init.userspace_reboot.started.timeoutmillis określa czas oczekiwania w milisekund na uruchomienie łagodnego ponownego uruchomienia (tzn. sys.init.userspace_reboot.in_progress=1). Jeśli urządzenie nie uruchomi się w tle ponownego uruchomienia przed upływem limitu czasu, aktywowany jest twardy restart.
  • init.userspace_reboot.userdata_remount.timeoutmillis określa czas oczekiwania w milisekund na odłączenie userdata. Jeśli nie można odłączyć urządzenia userdata po upływie określonego czasu oczekiwania, zostanie aktywowany twardy restart.
  • init.userspace_reboot.watchdog.timeoutmillis określa czas oczekiwania urządzenie, które zostanie poprawnie uruchomione (czyli sys.boot_completed=1). Jeśli urządzenie nie udało się uruchomić w określonym czasie, a w przypadku zmiany twardego restartu .

Dostosuj animację podczas łagodnego ponownego uruchamiania

Referencyjna implementacja funkcji łagodnego ponownego uruchamiania umożliwia dostosowanie jest wyświetlana podczas łagodnego ponownego uruchamiania.

Na końcu działania userspace-reboot-fs-remount init rozpoczyna się Usługa bootanim. Ta usługa sprawdza istnienie: animacji w podanej kolejności i odtwarza pierwszy znaleziony:

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

Jeśli nie określono plików animacji z ponownym uruchomieniem, bootanim pokazuje domyślna animacja android.

Testowanie

Android 11 zawiera referencyjną implementację tagu ponowne uruchomienie w tle. Dodatkowo możesz sprawdzić ponowne uruchomienie w praktyce za pomocą CTS. testy w: UserspaceRebootHostTest