Android 11 unterstützt Neustarts im Hintergrund. Dabei werden Prozesse im Userspace zur Laufzeit neu gestartet, um Updates anzuwenden, für die ein Neustart erforderlich ist (z. B. Updates für APEX-Pakete). Derzeit ist der Neustart im Hintergrund auf Prozesse beschränkt, die nach dem Mounten von userdata gestartet wurden.
Ein Neustart im Hintergrund kann auf folgende Arten angefordert werden:
Über
PowerManagerdurch AufrufenPowerManager.reboot(PowerManager.REBOOT_USERSPACE)Über die Shell mit
adb shell svc power reboot userspaceoderadb reboot userspace
Nach einem Neustart im Hintergrund bleibt der mit Anmeldedaten verschlüsselte Speicher entsperrt.
Wenn ein Gerät Neustarts im Hintergrund unterstützt, gibt die API-Methode PowerManager.isRebootingUserspace() den Wert true zurück und der Wert der Systemeigenschaft init.userspace_reboot.is_supported ist gleich 1.
Wenn das Gerät keine Neustarts im Hintergrund unterstützt, schlagen Aufrufe von
PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot
userspace, und adb shell svc power reboot userspace fehl.
Ausführung des Neustarts im Hintergrund
Nachdem ein Neustart im Hintergrund angefordert wurde (über PowerManager oder über eine Shell), führt init die folgenden Schritte aus:
sys.powerctl=reboot,userspacewird empfangen.Ein separater
UserspaceRebootWatchdogThread()Prozess wird verzweigt, um den Neustart im Hintergrund zu überwachen.Eine
userspace-reboot-requested-Aktion wird ausgelöst, wodurch alle Systemeigenschaften zurückgesetzt werden, die sich auf den Neustart im Hintergrund auswirken könnten. Betroffene Eigenschaften:sys.usb.configsys.usb.statesys.boot_completeddev.bootcompletesys.init.updatable_crashingsys.init.updatable_crashing_process_nameapexd.statussys.user.0.ce_availablesys.shutdown.requestedservice.bootanim.exit
Die oben genannten Eigenschaften sollten während der Bootsequenz wieder festgelegt werden. Bei Bedarf können Sie zusätzliche Eigenschaften zurücksetzen. Beispiele finden Sie in der
on userspace-reboot-requestedAktion inrootdir/init.rc.Die Funktion
DoUserspaceRebootwird ausgeführt, die die folgenden Aktionen ausführt:SIGTERMwird an Prozesse gesendet, die nach dem Mounten vonuserdatagestartet wurden, und es wird gewartet, bis sie beendet werden.- Nach Ablauf des Zeitlimits wird
SIGKILLgesendet, um alle laufenden Prozesse zu beenden. /system/bin/vdc volume resetwird aufgerufen.- Das zRAM-Sicherungsgerät wird unmountet.
- Aktive APEX-Pakete werden unmountet.
- Es wird wieder zum Bootstrap-Mount-Namespace gewechselt.
- Die
userspace-reboot-resumeAktion wird ausgelöst.
Wenn vor dem Neustart im Hintergrund ein Dateisystem-Checkpointing angefordert wurde, wird userdata während der Aktion userspace-reboot-fs-remount im Checkpointing-Modus neu gemountet (weitere Informationen finden Sie im folgenden Abschnitt). Ein
Neustart im Hintergrund gilt als abgeschlossen, nachdem die sys.boot_completed property auf 1 gesetzt wurde. Am Ende des Neustarts im Hintergrund bleibt das Display ausgeschaltet und es ist eine explizite Nutzerinteraktion erforderlich, um es zu aktivieren.
Dateisystem-Checkpointing
Wenn vor dem Neustart im Hintergrund ein Dateisystem-Checkpoint angefordert wurde, wird userdata während des Neustarts im Hintergrund im Checkpointing-Modus neu gemountet.
Die Remounting-Logik ist in der
fs_mgr_remount_userdata_into_checkpointing
Funktion implementiert und unterscheidet sich je nach Checkpointing-Methode. Wenn userdata Folgendes unterstützt:
Checkpointing auf Dateisystemebene (z. B.
f2fs), wirduserdatamit der Optioncheckpoint=disableneu gemountet.Checkpointing auf Blockebene (z. B.
ext4), wird/dataunmountet und alle übergeordneten Device Mapper-Geräte, auf denen es gemountet wurde, werden zerstört. Anschließend wirduserdatamit demselben Codepfad gemountet, der auch beim normalen Checkpointing-Boot verwendet wird.
Wenn ein Dateisystem-Keyring zum Verwalten von mit Anmeldedaten verschlüsselten (CE) und geräteverschlüsselten (DE) Schlüsseln verwendet wird, gehen die Schlüssel verloren, nachdem userdata unmountet wurde. Damit Schlüssel wiederhergestellt werden können, installiert vold beim Installieren eines Schlüssels in einem Dateisystem-Keyring auch denselben Schlüssel vom Typ fscrypt-provisioning im Keyring auf Sitzungsebene. Wenn init_user0 aufgerufen wird, installiert vold die Schlüssel im Dateisystem-Keyring neu.
Fallback auf einen Neustart
Damit ein Neustart im Hintergrund ein Gerät nicht in einem unbrauchbaren Zustand zurücklässt, enthält Android 11 einen Fallback auf einen Neustart, der ausgelöst wird, wenn eine der folgenden Bedingungen erfüllt ist:
- Ein Gerät kann den Neustart im Hintergrund nicht innerhalb eines bestimmten Zeitlimits starten (d. h.
sys.init.userspace_reboot.in_progress=1). - Ein Prozess kann nicht innerhalb eines bestimmten Zeitlimits beendet werden.
- Der Vorgang
/system/bin/vdc volume resetschlägt fehl. - Das Unmounten des zRAM-Geräts schlägt fehl.
- Ein aktives APEX-Paket wird falsch unmountet.
- Ein Versuch,
userdataim Checkpointing-Modus neu zu mounten, schlägt fehl. - Ein Gerät kann nicht innerhalb eines bestimmten Zeitlimits erfolgreich gebootet werden (d. h.
sys.boot_completed=1).
Gerätespezifische Konfiguration
Einige Aspekte des Neustarts im Hintergrund können durch Ändern der Werte der folgenden Eigenschaften angepasst werden:
init.userspace_reboot.is_supportedsteuert, wann ein Gerät einen Neustart im Hintergrund ausführen kann. Wenn der Wert dieser Eigenschaftfalse,0oder nicht angegeben ist, werden Versuche, das Gerät neu zu starten, abgelehnt.init.userspace_reboot.sigkill.timeoutmillissteuert das Zeitlimit in Millisekunden für Prozesse, die einSIGKILL-Signal erhalten haben, um beendet zu werden. Wenn einer der Prozesse nicht innerhalb des angegebenen Zeitlimits beendet wird, wird ein Fallback auf einen Neustart ausgelöst.init.userspace_reboot.sigterm.timeoutmillissteuert das Zeitlimit in Millisekunden für Prozesse, die einSIGTERM-Signal erhalten haben, um beendet zu werden. Alle Prozesse, die nicht innerhalb des angegebenen Zeitlimits beendet wurden, erhalten einSIGKILL-Signal.init.userspace_reboot.started.timeoutmillissteuert das Zeitlimit in Millisekunden für den Start des Neustarts im Hintergrund (d. h.sys.init.userspace_reboot.in_progress=1). Wenn ein Gerät den Neustart im Hintergrund nicht innerhalb des angegebenen Zeitlimits starten kann, wird ein Fallback auf einen Neustart ausgelöst.init.userspace_reboot.userdata_remount.timeoutmillissteuert das Zeitlimit in Millisekunden für das Unmounten vonuserdata. Wenn ein Gerätuserdatanicht innerhalb des angegebenen Zeitlimits unmounten kann, wird ein Fallback auf einen Neustart ausgelöst.init.userspace_reboot.watchdog.timeoutmillissteuert das Zeitlimit für das erfolgreiche Booten eines Geräts (d. h.sys.boot_completed=1). Wenn ein Gerät nicht innerhalb des angegebenen Zeitlimits gebootet werden kann, wird ein Fallback auf einen Neustart ausgelöst.
Animation während des Neustarts im Hintergrund anpassen
Die Referenzimplementierung eines Neustarts im Hintergrund bietet die Möglichkeit, die Animation anzupassen, die während des Neustarts im Hintergrund angezeigt wird.
Am Ende der Aktion userspace-reboot-fs-remount startet init den Dienst bootanim. Dieser Dienst sucht in der angegebenen Reihenfolge nach den folgenden Animationsdateien und spielt die erste gefundene Datei ab:
/product/media/userspace-reboot.zip/oem/media/userspace-reboot.zip/system/media/userspace-reboot.zip
Wenn keine spezifischen Animationsdateien für den Neustart im Hintergrund angegeben sind, zeigt bootanim eine Standardanimation android an.
Testen
Android 11 enthält eine Referenzimplementierung eines Neustarts im Hintergrund. Außerdem können Sie einen Neustart im Hintergrund mit CTS
Tests in
UserspaceRebootHostTest überprüfen.