Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Soft-Neustarts (bis AOSP 14)

Android 11 unterstützt Soft-Neustarts. Das sind Laufzeit-Neustarts von Prozessen im Nutzerbereich, die zum Anwenden von Updates verwendet werden, für die ein Neustart erforderlich ist, z. B. Updates für APEX-Pakete. Derzeit ist der Soft-Neustart auf Prozesse beschränkt, die nach dem Mounten von userdata gestartet wurden.

Ein Soft-Restart kann auf folgende Weise angefordert werden:

Ab PowerManager unter PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Über die Shell mit adb shell svc power reboot userspace oder adb reboot userspace

Nach einem Soft-Restart bleibt der mit Anmeldedaten verschlüsselte Speicher entsperrt.

Wenn ein Gerät Soft-Neustarts 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 Soft-Neustarts unterstützt, schlagen Aufrufe von PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace und adb shell svc power reboot userspace fehl.

Neustart im Hintergrund ausführen

Nachdem ein Soft-Neustart angefordert wurde (über PowerManager oder über eine Shell), führt init die folgenden Schritte aus:

Empfängt sys.powerctl=reboot,userspace.
Forks einen separaten UserspaceRebootWatchdogThread()-Prozess, um den Soft-Restart 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 Unterkünfte:
- 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 Attribute sollten während der Bootsequenz noch einmal festgelegt werden. Bei Bedarf können Sie zusätzliche Properties zurücksetzen. Beispiele finden Sie in der Aktion on userspace-reboot-requested in rootdir/init.rc.
Führt die Funktion DoUserspaceReboot aus, die die folgenden Aktionen ausführt:
1. Sendet SIGTERM an Prozesse, die nach dem Mounten von userdata gestartet wurden, und wartet, bis sie beendet werden.
2. Nach Ablauf des Zeitlimits wird SIGKILL gesendet, um alle laufenden Prozesse zu beenden.
3. Ruft /system/bin/vdc volume reset an.
4. Hebt die Bereitstellung des zRAM-Sicherungsgeräts auf.
5. Aktive APEX-Pakete werden unmountet.
6. Wechselt zurück zum Bootstrap-Bereitstellungs-Namespace.
7. Löst die Aktion userspace-reboot-resume aus.

Wenn vor dem Soft-Restart ein Dateisystem-Checkpointing angefordert wurde, wird userdata während der userspace-reboot-fs-remount-Aktion im Checkpointing-Modus neu gemountet (siehe Details im nächsten Abschnitt). Ein Soft-Restart wird ausgeführt, nachdem sys.boot_completed property auf 1 gesetzt wurde. Am Ende des Soft-Neustarts bleibt das Display aus und es ist eine explizite Nutzerinteraktion erforderlich, um es zu aktivieren.

Dateisystem-Checkpointing

Wenn vor dem Soft-Restart ein Dateisystem-Checkpoint angefordert wurde, wird userdata während des Soft-Restarts im Checkpointing-Modus neu bereitgestellt. Die Logik für das erneute Mounten ist in der Funktion fs_mgr_remount_userdata_into_checkpointing implementiert und unterscheidet sich je nach Checkpointing-Methode. Insbesondere wenn userdata Folgendes unterstützt:

Checkpointing auf Dateisystemebene (z. B. f2fs): userdata wird mit der Option checkpoint=disable neu gemountet.
Block-Level-Checkpointing (z. B. ext4), dann wird /data unmounted und alle übergeordneten Device Mapper-Geräte, auf denen es gemountet war, werden zerstört. Als Nächstes wird userdata mit demselben Codepfad eingebunden, der auch beim normalen Checkpointing-Bootvorgang verwendet wird.

Wenn ein Schlüsselbund auf Dateisystemebene zum Verwalten von credential-encrypted (CE) und device-encrypted (DE) keys verwendet wird, gehen die Schlüssel nach dem Unmounten von userdata verloren. Damit Schlüssel wiederhergestellt werden können, wird beim Installieren eines Schlüssels in einem Dateisystem-Schlüsselbund mit vold auch derselbe Schlüssel vom Typ fscrypt-provisioning im Schlüsselbund auf Sitzungsebene installiert. Wenn init_user0 aufgerufen wird, werden die Schlüssel von vold im Dateisystem-Schlüsselbund neu installiert.

Fallback auf Neustart erzwingen

Damit ein Gerät nach einem Soft-Neustart nicht in einem nicht nutzbaren Zustand verbleibt, enthält Android 11 einen Fallback zum Hard-Neustart, der ausgelöst wird, wenn eine der folgenden Bedingungen erfüllt ist:

Ein Gerät kann den Soft-Neustart (sys.init.userspace_reboot.in_progress=1) innerhalb eines bestimmten Zeitlimits nicht starten.
Ein Prozess kann innerhalb eines bestimmten Zeitlimits nicht beendet werden.
Der Vorgang /system/bin/vdc volume reset schlägt fehl.
Das Unmounten des zRAM-Geräts schlägt fehl.
Ein aktives APEX-Paket wird fälschlicherweise demounted.
Der Versuch, userdata im Checkpointing-Modus neu zu mounten, schlägt fehl.
Ein Gerät kann innerhalb eines bestimmten Zeitlimits nicht ordnungsgemäß 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 angepasst werden:

Mit init.userspace_reboot.is_supported wird gesteuert, wann ein Gerät einen Soft-Neustart durchführen kann. Wenn der Wert dieses Attributs false, 0 oder nicht angegeben ist, werden Neustartversuche abgelehnt.
init.userspace_reboot.sigkill.timeoutmillis steuert das Zeitlimit in Millisekunden für Prozesse, die ein SIGKILL-Signal zum Beenden erhalten haben. Wenn einer der Prozesse innerhalb des angegebenen Zeitlimits nicht beendet wird, wird ein Fallback auf einen Hard-Reboot ausgelöst.
Mit init.userspace_reboot.sigterm.timeoutmillis wird das Zeitlimit in Millisekunden für Prozesse festgelegt, die ein SIGTERM-Signal zum Beenden erhalten haben. Alle Prozesse, die im angegebenen Zeitlimit nicht beendet werden konnten, erhalten ein SIGKILL-Signal.
init.userspace_reboot.started.timeoutmillis steuert das Zeitlimit in Millisekunden für den Start des Soft-Neustarts (d. h. sys.init.userspace_reboot.in_progress=1). Wenn ein Gerät den Soft-Neustart nicht innerhalb des angegebenen Zeitlimits startet, wird ein Fallback zum Hard-Neustart ausgelöst.
init.userspace_reboot.userdata_remount.timeoutmillis steuert das Zeitlimit in Millisekunden für das Unmounten von userdata. Wenn das Unmounten von userdata auf einem Gerät innerhalb des angegebenen Zeitlimits fehlschlägt, wird ein Fallback zum Hard-Reboot ausgelöst.
init.userspace_reboot.watchdog.timeoutmillis steuert das Zeitlimit für das erfolgreiche Booten eines Geräts (d. h. sys.boot_completed=1). Wenn ein Gerät innerhalb des angegebenen Zeitlimits nicht booten kann, wird ein Fallback auf einen Hard-Reboot ausgelöst.

Animation während des Soft-Neustarts anpassen

Die Referenzimplementierung eines Soft-Neustarts bietet die Möglichkeit, die während des Soft-Neustarts angezeigte Animation anzupassen.

Am Ende der userspace-reboot-fs-remount-Aktion startet init den bootanim-Dienst. Der Dienst sucht in der aufgeführten 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 Soft-Neustart angegeben sind, wird in bootanim eine Standardanimation für android angezeigt.

Testen

Android 11 enthält eine Referenzimplementierung für einen Soft-Restart. Außerdem können Sie einen Soft-Restart mit CTS-Tests in UserspaceRebootHostTest überprüfen.