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)

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

Miękkie ponowne uruchomienie można wywołać na te sposoby:

Od PowerManager, dzwoniąc pod numer 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 zaszyfrowany magazyn danych logowania pozostaje odblokowany.

Jeśli urządzenie obsługuje miękkie ponowne uruchamianie, metoda interfejsu API PowerManager.isRebootingUserspace() zwraca wartość 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ękkiego restartu, wywołania funkcji PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace i adb shell svc power reboot userspace zakończą się niepowodzeniem.

Wykonanie ponownego uruchomienia w tle

Po wysłaniu żądania miękkiego ponownego uruchomienia (za pomocą ikony PowerManager lub z poziomu powłoki) init wykonuje te czynności:

Otrzymuje sys.powerctl=reboot,userspace.
Tworzy osobny proces UserspaceRebootWatchdogThread() do monitorowania łagodnego ponownego uruchomienia.
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. Dotyczy to tych usług:
- 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
Podczas sekwencji uruchamiania należy ponownie ustawić powyższe właściwości. W razie potrzeby możesz zresetować dodatkowe właściwości. Przykłady znajdziesz w sekcji działania on userspace-reboot-requested w rootdir/init.rc.
Uruchamia funkcję DoUserspaceReboot, która wykonuje te działania:
1. Wysyła sygnał SIGTERM do procesów uruchomionych po zamontowaniu userdata i czeka na ich zatrzymanie.
2. Po upłynięciu limitu czasu wysyła sygnał SIGKILL, aby zakończyć wszystkie uruchomione procesy.
3. Połączenia /system/bin/vdc volume reset.
4. Odłącza urządzenie z pamięcią zRAM.
5. Odmontowuje 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 ponownym uruchomieniem zażądano punktu kontrolnego systemu plików,userdata jest ponownie montowany w trybie punktu kontrolnego podczas działaniauserdata (szczegółowe informacje znajdziesz w następnej sekcji).userspace-reboot-fs-remount Miękkie ponowne uruchomienie jest brane pod uwagę po ustawieniu wartości 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.

Tworzenie punktów kontrolnych systemu plików

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

Punkt kontrolny na poziomie systemu plików (np. f2fs), userdata jest ponownie montowany z opcją checkpoint=disable.
Punkt kontrolny na poziomie bloku (np. ext4), a następnie /data jest odmontowywany, a wszystkie urządzenia mapowania urządzeń nadrzędnych, 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 punktu kontrolnego.

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

Powrót do twardego resetu

Aby mieć pewność, że po miękkim ponownym uruchomieniu urządzenie nie będzie bezużyteczne, Android 11 zawiera funkcję powrotu do twardego ponownego uruchomienia, która jest wywoływana, gdy zostanie spełniony jeden z tych warunków:

Urządzenie nie uruchamia się ponownie (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 nie powiodła się.
Nie udało się odmontować urządzenia zRAM.
Aktywny pakiet APEX jest nieprawidłowo odmontowywany.
Próba ponownego zamontowania userdata w trybie tworzenia punktów kontrolnych nie powiodła się.
Urządzenie nie uruchamia się (czyli sys.boot_completed=1) w określonym czasie.

Konfiguracja na urządzenie

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 wykonać miękki restart. Jeśli wartość tej właściwości to false, 0 lub nie jest określona, próby ponownego uruchomienia są odrzucane.
init.userspace_reboot.sigkill.timeoutmillis określa limit czasu 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, nastąpi powrót do twardego ponownego uruchomienia.
init.userspace_reboot.sigterm.timeoutmillis określa limit czasu w milisekundach dla procesów, które otrzymały sygnał SIGTERM, aby się zakończyć. Wszystkie procesy, których nie udało się zakończyć w określonym czasie, otrzymują sygnał SIGKILL.
init.userspace_reboot.started.timeoutmillis określa czas oczekiwania w milisekundach na rozpoczęcie ponownego uruchomienia w tle (czyli sys.init.userspace_reboot.in_progress=1). Jeśli urządzenie nie uruchomi ponownego uruchomienia w tle w określonym czasie, nastąpi powrót do ponownego uruchomienia na stałe.
init.userspace_reboot.userdata_remount.timeoutmillis określa czas oczekiwania (w milisekundach) na odmontowanie userdata. Jeśli nie uda się odmontować urządzeniauserdataw określonym czasie, zostanie uruchomiony awaryjny twardy reset.
init.userspace_reboot.watchdog.timeoutmillis określa limit czasu na pomyślne uruchomienie urządzenia (czyli sys.boot_completed=1). Jeśli urządzenie nie uruchomi się w określonym czasie, nastąpi powrót do twardego ponownego uruchomienia.

Dostosowywanie animacji podczas miękkiego ponownego uruchamiania

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

Po zakończeniu działania userspace-reboot-fs-remount usługa bootanim rozpoczyna działanie init. Usługa wyszukuje 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 dotyczących miękkiego ponownego uruchomienia, bootanim wyświetla domyślną animację android.

Testowanie

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