Soft-Neustarts (bis AOSP 14)

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 PowerManager durch Aufrufen PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Über die Shell mit adb shell svc power reboot userspace oder adb 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:

  1. sys.powerctl=reboot,userspace wird empfangen.

  2. Ein separater UserspaceRebootWatchdogThread() Prozess wird verzweigt, um den Neustart im Hintergrund zu überwachen.

  3. 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.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 Bootsequenz wieder festgelegt werden. Bei Bedarf können Sie zusätzliche Eigenschaften zurücksetzen. Beispiele finden Sie in der on userspace-reboot-requested Aktion in rootdir/init.rc.

  4. Die Funktion DoUserspaceReboot wird ausgeführt, die die folgenden Aktionen ausführt:

    1. SIGTERM wird an Prozesse gesendet, die nach dem Mounten von userdata gestartet wurden, und es wird gewartet, bis sie beendet werden.
    2. Nach Ablauf des Zeitlimits wird SIGKILL gesendet, um alle laufenden Prozesse zu beenden.
    3. /system/bin/vdc volume reset wird aufgerufen.
    4. Das zRAM-Sicherungsgerät wird unmountet.
    5. Aktive APEX-Pakete werden unmountet.
    6. Es wird wieder zum Bootstrap-Mount-Namespace gewechselt.
    7. Die userspace-reboot-resume Aktion 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), wird userdata mit der Option checkpoint=disable neu gemountet.

  • Checkpointing auf Blockebene (z. B. ext4), wird /data unmountet und alle übergeordneten Device Mapper-Geräte, auf denen es gemountet wurde, werden zerstört. Anschließend wird userdata mit 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 reset schlägt fehl.
  • Das Unmounten des zRAM-Geräts schlägt fehl.
  • Ein aktives APEX-Paket wird falsch unmountet.
  • Ein Versuch, userdata im 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_supported steuert, wann ein Gerät einen Neustart im Hintergrund ausführen kann. Wenn der Wert dieser Eigenschaft false, 0 oder nicht angegeben ist, werden Versuche, das Gerät neu zu starten, abgelehnt.
  • init.userspace_reboot.sigkill.timeoutmillis steuert das Zeitlimit in Millisekunden für Prozesse, die ein SIGKILL-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.timeoutmillis steuert das Zeitlimit in Millisekunden für Prozesse, die ein SIGTERM-Signal erhalten haben, um beendet zu werden. Alle Prozesse, die nicht innerhalb des angegebenen Zeitlimits beendet wurden, erhalten ein SIGKILL-Signal.
  • init.userspace_reboot.started.timeoutmillis steuert 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.timeoutmillis steuert das Zeitlimit in Millisekunden für das Unmounten von userdata. Wenn ein Gerät userdata nicht innerhalb des angegebenen Zeitlimits unmounten kann, wird ein Fallback auf einen Neustart 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 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
haben:

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.