Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

Miękkie ponowne uruchamianie (wersja AOSP 14 i starsze)
Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Android 11 obsługuje miękkie restarty, czyli restarty procesów w przestrzeni użytkownika, które są używane do stosowania aktualizacji wymagających ponownego uruchamiania (np. aktualizacji pakietów APEX). Obecnie miękki restart jest ograniczony do procesów, które zostały uruchomione po zamontowaniu userdata.

Miękkie ponowne uruchomienie można zażądać w następujące sposoby:

Z: PowerManager, przez wywołanie PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Z powłoki za pomocą polecenia 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 miękkich restartów, 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 przesłaniu żądania miękkiego restartu (za pomocą PowerManager lub w powłoce) init wykonuje te czynności:

Otrzymuje sys.powerctl=reboot,userspace.
Tworzy osobny proces UserspaceRebootWatchdogThread() do monitorowania miękkiego restartu.
Wyzwala działanie userspace-reboot-requested, które resetuje wszystkie właściwości systemu, które mogą mieć wpływ na miękki restart. Właściwości, 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.
Uruchamia funkcję DoUserspaceReboot, która wykonuje te czynności:
1. Wysyła SIGTERM do procesów rozpoczętych po zamontowaniu userdata i czeka, aż się zakończą.
2. Po upływie limitu czasu wysyła SIGKILL, aby zakończyć wszystkie procesy.
3. Połączenia /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 wartości sys.boot_completed property na 1. Po zakończeniu miękkiego restartu wyświetlacz pozostaje wyłączony i włączenie go wymaga interakcji użytkownika.

Punkty kontrolne systemu plików

Jeśli przed miękkim restartem systemu został przesłany wniosek o punkt kontrolny systemu plików, userdata zostanie ponownie zamontowany w trybie punkt kontrolny podczas miękkiego restartu. Logika ponownego montowania 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, a 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. Gdy wywoływana jest funkcja init_user0, funkcja vold ponownie instaluje klucze w pliku kluczy systemu.

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 odmontowywany.
Nie udaje się ponownie zamontować urządzenia userdata w trybie punktowania.
urządzenie nie uruchamia się (czyli sys.boot_completed=1) w określonym czasie;

Konfiguracja na urządzeniu

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

init.userspace_reboot.is_supportedokreśla, kiedy urządzenie może wykonać miękki restart. 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.
Wartość init.userspace_reboot.started.timeoutmillis określa czas oczekiwania w milisekundach, po którym nastąpi ponowne uruchomienie w tle (czyli sys.init.userspace_reboot.in_progress=1). Jeśli urządzenie nie rozpocznie ponownego uruchamiania w tle w określonym czasie, zostanie uruchomiony tryb twardego restartu.
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

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

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:

/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 implementację referencyjną miękkiego restartu. Możesz też zweryfikować miękki restart za pomocą testów CTS w UserspaceRebootHostTest.