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ącPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Z powłoki, używając
adb shell svc power reboot userspace
lubadb 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:
Otrzymuje
sys.powerctl=reboot,userspace
.Tworzy osobny proces
UserspaceRebootWatchdogThread()
w celu monitorowania miękkiego restartu.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
wrootdir/init.rc
.-
Uruchamia funkcję
DoUserspaceReboot
, która wykonuje następujące działania:- Wysyła
SIGTERM
do procesów uruchomionych po zamontowaniuuserdata
i czeka na ich zatrzymanie. - Po osiągnięciu limitu czasu wysyła sygnał
SIGKILL
, aby zabić wszystkie uruchomione procesy. - Wywołuje
/system/bin/vdc volume reset
. - Odmontowuje urządzenie bazowe zRAM.
- Odmontowuje aktywne pakiety APEX.
- Przełącza z powrotem do przestrzeni nazw montowania bootstrap.
- Wyzwala akcję
userspace-reboot-resume
.
- Wysyła
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ą opcjicheckpoint=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ępnieuserdata
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 tofalse
,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 odmontowaniauserdata
. Jeśli urządzenie nie odmontujeuserdata
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
.