Android 11 unterstützt Soft-Neustarts, bei denen es sich um Laufzeitneustarts von Prozessen im Benutzerbereich handelt, die zum Anwenden von Updates verwendet werden, die einen Neustart erfordern (z. B. Updates für APEX-Pakete). Derzeit ist der Soft-Neustart auf Prozesse beschränkt, die gestartet wurden, nachdem userdata
bereitgestellt wurden.
Ein Soft-Neustart wird auf folgende Weise angefordert:
Von
PowerManager
aus durch AufrufPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Von der Shell aus mit
adb shell svc power reboot userspace
oderadb reboot userspace
Nach einem Soft-Neustart bleibt der mit Anmeldeinformationen verschlüsselte Speicher entsperrt.
Wenn ein Gerät Soft-Neustarts unterstützt, gibt die API-Methode PowerManager.isRebootingUserspace()
true
zurück und der Wert der Systemeigenschaft init.userspace_reboot.is_supported
ist gleich 1
.
Wenn das Gerät keine Soft-Neustarts unterstützt, schlagen Aufrufe von PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
, adb reboot userspace
und adb shell svc power reboot userspace
fehl.
Soft-Restart-Ausführung
Nachdem ein sanfter Neustart angefordert wurde (über PowerManager
oder von einer Shell), führt init
die folgenden Schritte aus:
Erhält
sys.powerctl=reboot,userspace
.Verzweigt einen separaten
UserspaceRebootWatchdogThread()
-Prozess, um den Soft-Neustart zu überwachen.Löst eine
userspace-reboot-requested
Aktion aus, die alle Systemeigenschaften zurücksetzt, die sich auf den Soft-Neustart auswirken könnten. Betroffene Eigenschaften:-
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
Die oben genannten Eigenschaften sollten während der Startsequenz erneut festgelegt werden. Bei Bedarf können Sie weitere Eigenschaften zurücksetzen. Beispiele finden Sie in der Aktion
on userspace-reboot-requested
inrootdir/init.rc
.-
Führt die Funktion
DoUserspaceReboot
aus, die die folgenden Aktionen ausführt:- Sendet
SIGTERM
an Prozesse, die nach dem Mountenuserdata
gestartet wurden, und wartet darauf, dass sie gestoppt werden. - Nach Erreichen des Timeouts wird
SIGKILL
gesendet, um alle laufenden Prozesse abzubrechen. - Ruft
/system/bin/vdc volume reset
auf. - Hebt die Bereitstellung des zRAM-Backup-Geräts auf.
- Hebt die Bereitstellung aktiver APEX-Pakete auf.
- Wechselt zurück zum Bootstrap-Mount-Namespace.
- Löst die Aktion
userspace-reboot-resume
aus.
- Sendet
Wenn vor dem Soft-Neustart ein Dateisystem-Checkpointing angefordert wurde, werden userdata
während der Aktion userspace-reboot-fs-remount
erneut in den Checkpointing-Modus gemountet (Einzelheiten finden Sie im folgenden Abschnitt). Ein sanfter Neustart wird in Betracht gezogen, nachdem die sys.boot_completed property
auf 1
gesetzt wurde. Am Ende des Soft-Neustarts bleibt das Display ausgeschaltet und es ist eine explizite Benutzerinteraktion erforderlich, um es zu aktivieren.
Dateisystem-Checkpointing
Wenn vor dem Soft-Neustart ein Dateisystem-Checkpoint angefordert wurde, werden userdata
während des Soft-Neustarts im Checkpoint-Modus erneut bereitgestellt. Die Remounting-Logik ist in der Funktion fs_mgr_remount_userdata_into_checkpointing
implementiert und unterscheidet sich zwischen den Checkpointing-Methoden. Insbesondere wenn userdata
unterstützen:
Beim Checkpointing auf Dateisystemebene (z. B.
f2fs
) werdenuserdata
mit der Optioncheckpoint=disable
erneut bereitgestellt.Checkpointing auf Blockebene (z. B.
ext4
), dann wird/data
ausgehängt und alle übergeordneten Device-Mapper-Geräte, auf denen es gemountet wurde, werden zerstört. Als nächstes werdenuserdata
unter Verwendung desselben Codepfads gemountet, der auch beim normalen Checkpointing-Boot verwendet wird.
Wenn ein Schlüsselbund auf Dateisystemebene zum Verwalten von mit Anmeldeinformationen verschlüsselten (CE) und geräteverschlüsselten (DE) Schlüsseln verwendet wird, gehen die Schlüssel verloren, nachdem die Bereitstellung userdata
aufgehoben wurde. Um eine Schlüsselwiederherstellung zu ermöglichen, installiert vold
bei der Installation eines Schlüssels für einen Dateisystemschlüsselbund auch denselben Schlüssel vom Typ fscrypt-provisioning
für den Schlüsselbund auf Sitzungsebene. Wenn init_user0
aufgerufen wird, installiert vold
die Schlüssel im Dateisystem-Schlüsselbund neu.
Fallback auf harten Neustart
Um sicherzustellen, dass ein Soft-Neustart ein Gerät nicht in einem unbrauchbaren Zustand zurücklässt, enthält Android 11 einen Fallback auf einen Hard-Neustart, der ausgelöst wird, wenn eine der folgenden Bedingungen erfüllt ist:
- Ein Gerät kann innerhalb eines bestimmten Zeitlimits keinen Soft-Neustart starten (d. h.
sys.init.userspace_reboot.in_progress=1
). - Ein Prozess kann nicht innerhalb einer bestimmten Zeitüberschreitung beendet werden.
- Der Vorgang
/system/bin/vdc volume reset
schlägt fehl. - Das Aufheben der Bereitstellung des zRAM-Geräts schlägt fehl.
- Die Bereitstellung eines aktiven APEX-Pakets wird fälschlicherweise aufgehoben.
- Ein Versuch,
userdata
erneut in den Prüfpunktmodus zu laden, schlägt fehl. - Ein Gerät kann innerhalb einer bestimmten Zeitüberschreitung nicht erfolgreich gestartet werden (d. h.
sys.boot_completed=1
).
Konfiguration pro Gerät
Einige Aspekte des Soft-Neustarts können durch Ändern der Werte der folgenden Eigenschaften optimiert werden:
-
init.userspace_reboot.is_supported
steuert, wann ein Gerät einen Soft-Neustart durchführen kann. Wenn der Wert dieser Eigenschaftfalse
,0
oder nicht angegeben ist, werden Neustartversuche abgelehnt. -
init.userspace_reboot.sigkill.timeoutmillis
steuert das Timeout in Millisekunden für Prozesse, die einSIGKILL
Signal zum Stoppen erhalten haben. Wenn einer der Prozesse innerhalb des angegebenen Zeitlimits nicht gestoppt werden kann, wird ein Fallback auf einen harten Neustart ausgelöst. -
init.userspace_reboot.sigterm.timeoutmillis
steuert das Timeout in Millisekunden für Prozesse, die einSIGTERM
Signal zum Beenden erhalten haben. Alle Prozesse, die innerhalb des angegebenen Timeouts nicht beendet werden konnten, erhalten einSIGKILL
Signal. -
init.userspace_reboot.started.timeoutmillis
steuert das Timeout in Millisekunden für den Start eines Soft-Neustarts (d. h.sys.init.userspace_reboot.in_progress=1
). Wenn ein Gerät innerhalb der angegebenen Zeitspanne keinen Soft-Neustart startet, wird ein Fallback auf einen Hard-Neustart ausgelöst. -
init.userspace_reboot.userdata_remount.timeoutmillis
steuert die Zeitüberschreitung in Millisekunden, um die Bereitstellunguserdata
aufzuheben. Wenn ein Gerätuserdata
nicht innerhalb des angegebenen Zeitlimits aushängen kann, wird ein Fallback auf einen harten Neustart ausgelöst. -
init.userspace_reboot.watchdog.timeoutmillis
steuert das Timeout für den erfolgreichen Start eines Geräts (d. h.sys.boot_completed=1
). Wenn ein Gerät innerhalb des angegebenen Zeitlimits nicht startet, wird ein Fallback auf einen harten Neustart ausgelöst.
Passen Sie die Animation während des Soft-Neustarts an
Die Referenzimplementierung eines Soft-Neustarts umfasst die Möglichkeit, die während des Soft-Neustarts angezeigte Animation anzupassen.
Am Ende der Aktion userspace-reboot-fs-remount
startet init
den bootanim
Dienst. Dieser Dienst sucht in der aufgeführten Reihenfolge nach dem Vorhandensein der 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 Soft-Restart-spezifischen Animationsdateien angegeben sind, zeigt bootanim
eine Standard android
Animation an.
Testen
Android 11 enthält eine Referenzimplementierung eines Soft-Restarts. Darüber hinaus können Sie einen Soft-Neustart mithilfe von CTS-Tests in UserspaceRebootHostTest
überprüfen.