Sanfte Neustarts (<= AOSP 14)

Android 11 unterstützt sogenannte Soft-Neustarts. Dabei werden Prozesse im Nutzerbereich zur Laufzeit neu gestartet, um Updates anzuwenden, die einen Neustart erfordern (z. B. Updates für APEX-Pakete). Derzeit ist der sanfte Neustart auf Prozesse beschränkt, die gestartet wurden, nachdem userdata bereitgestellt wurde.

So kannst du einen richtlinienkonformen Neustart anfordern:

  • Unter PowerManager durch Aufruf von PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Über die Shell mit adb shell svc power reboot userspace oder adb reboot userspace

Nach einem richtlinienbasierten Neustart bleibt der verschlüsselte Speicher für Anmeldedaten entsperrt.

Wenn ein Gerät einen sanften Neustart unterstützt, gibt die PowerManager.isRebootingUserspace() API-Methode true zurück und der Wert der Systemeigenschaft init.userspace_reboot.is_supported ist 1.

Wenn das Gerät keine sanften Neustarts unterstützt, schlagen Aufrufe von PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace und adb shell svc power reboot userspace fehl.

Ausführung des weichen Neustarts

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

  1. Erhält sys.powerctl=reboot,userspace.

  2. Forking eines separaten UserspaceRebootWatchdogThread()-Prozesses zur Überwachung des richtlinienbasierten Neustarts.

  3. Löst eine userspace-reboot-requested-Aktion aus, wodurch alle Systemeigenschaften zurückgesetzt werden, die sich auf den richtlinienbasierten 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 Eigenschaften sollten während des Bootvorgangs noch einmal festgelegt werden. Bei Bedarf können Sie auch weitere Properties zurücksetzen. Beispiele finden Sie in der Aktion on userspace-reboot-requested in rootdir/init.rc.

  4. Führt die Funktion DoUserspaceReboot aus, die die folgenden Aktionen ausführt:

    1. Sendet SIGTERM an Prozesse, die gestartet wurden, nachdem userdata bereitgestellt wurde, und wartet, bis sie beendet sind.
    2. Nach Ablauf des Zeitlimits wird SIGKILL gesendet, um alle laufenden Prozesse zu beenden.
    3. Ruft /system/bin/vdc volume reset an.
    4. Trennt das zRAM-Sicherungsgerät.
    5. Aktive APEX-Pakete werden getrennt.
    6. Wechselt zurück zum Bootstrap-Bereitstellungs-Namespace.
    7. Löst die Aktion userspace-reboot-resume aus.

Wenn vor dem richtlinienbasierten Neustart ein Dateisystem-Checkpoint angefordert wurde, wird userdata während der userspace-reboot-fs-remount-Aktion im Checkpoint-Modus neu bereitgestellt. Weitere Informationen finden Sie im folgenden Abschnitt. Ein richtlinienbasierter Neustart wird berücksichtigt, nachdem sys.boot_completed property auf 1 festgelegt wurde. Am Ende des Softneustarts bleibt das Display ausgeschaltet und es ist eine explizite Nutzerinteraktion erforderlich, um den Ruhemodus zu beenden.

Dateisystem-Checkpoints

Wenn vor dem richtlinienbasierten Neustart ein Dateisystem-Checkpoint angefordert wurde, wird userdata während des richtlinienbasierten Neustarts im Checkpoint-Modus neu bereitgestellt. Die Logik für die erneute Bereitstellung ist in der Funktion fs_mgr_remount_userdata_into_checkpointing implementiert und unterscheidet sich zwischen den Prüfpunktmethoden. Insbesondere wenn userdata Folgendes unterstützt:

  • Prüfpunkte auf Dateisystemebene (z. B. f2fs): userdata wird mit der Option checkpoint=disable neu bereitgestellt.

  • Blockebene-Prüfpunkt (z. B. ext4): /data wird getrennt und alle übergeordneten Device Mapper-Geräte, auf denen es bereitgestellt wurde, werden gelöscht. Als Nächstes wird userdata über denselben Codepfad bereitgestellt, der auch beim normalen Start mit Checkpointing verwendet wird.

Wenn ein Schlüsselbund auf Dateisystemebene zum Verwalten von Schlüsseln mit Anmeldedaten (verschlüsselt) und geräteverschlüsselten (DE)-Schlüsseln verwendet wird, gehen die Schlüssel nach dem Trennen von userdata verloren. Damit Schlüssel wiederhergestellt werden können, installiert vold beim Installieren eines Schlüssels in einem Dateisystem-Schlüsselbund denselben Schlüssel vom Typ fscrypt-provisioning auch im Schlüsselbund auf Sitzungsebene. Wenn init_user0 aufgerufen wird, installiert vold die Schlüssel im Schlüsselbund des Dateisystems neu.

Fallback auf Hard-Reset

Damit ein Gerät nach einem richtlinienkonformen Neustart nicht unbrauchbar wird, gibt es in Android 11 einen Fallback zum Hard-Neustart, der ausgelöst wird, wenn eine der folgenden Bedingungen erfüllt ist:

  • Ein Gerät kann innerhalb eines bestimmten Zeitlimits keinen Softneustart (sys.init.userspace_reboot.in_progress=1) starten.
  • Ein Prozess wird innerhalb eines bestimmten Zeitlimits nicht beendet.
  • Der Vorgang /system/bin/vdc volume reset schlägt fehl.
  • Das ZRAM-Gerät kann nicht getrennt werden.
  • Ein aktives APEX-Paket wird nicht richtig getrennt.
  • Ein Versuch, userdata wieder im Prüfpunktmodus bereitzustellen, schlägt fehl.
  • Ein Gerät kann innerhalb einer bestimmten Zeitüberschreitung nicht gestartet werden (sys.boot_completed=1).

Gerätespezifische Konfiguration

Einige Aspekte des weichen Neustarts können durch Ändern der Werte der folgenden Eigenschaften optimiert werden:

  • Mit init.userspace_reboot.is_supported wird festgelegt, wann ein Gerät einen sanften Neustart ausführen kann. Wenn der Wert dieser Property false, 0 oder nicht angegeben ist, werden Neustarts abgelehnt.
  • init.userspace_reboot.sigkill.timeoutmillis steuert die Zeitüberschreitung in Millisekunden für Prozesse, die ein SIGKILL-Signal zum Beenden erhalten haben. Wenn einer der Prozesse innerhalb des festgelegten Zeitlimits nicht beendet wird, wird ein Fallback auf einen harten Neustart ausgelöst.
  • init.userspace_reboot.sigterm.timeoutmillis steuert die Zeitüberschreitung in Millisekunden für Prozesse, die ein SIGTERM-Signal zum Beenden erhalten haben. Alle Prozesse, die nicht innerhalb des angegebenen Zeitlimits beendet werden konnten, erhalten ein SIGKILL-Signal.
  • Mit init.userspace_reboot.started.timeoutmillis wird die Zeitüberschreitung in Millisekunden für den Start des richtlinienbasierten Neustarts gesteuert (sys.init.userspace_reboot.in_progress=1). Wenn der richtlinienbasierte Neustart eines Geräts nicht innerhalb der angegebenen Zeitüberschreitung gestartet wird, wird ein Fallback zum harten Neustart ausgelöst.
  • init.userspace_reboot.userdata_remount.timeoutmillis steuert das Zeitlimit in Millisekunden für das Trennen von userdata. Wenn ein Gerät die Bereitstellung von userdata nicht innerhalb des festgelegten Zeitlimits trennt, wird ein Fallback auf einen harten Neustart ausgelöst.
  • init.userspace_reboot.watchdog.timeoutmillis steuert die Zeitüberschreitung für das erfolgreiche Starten eines Geräts (sys.boot_completed=1). Wenn ein Gerät innerhalb der angegebenen Zeitüberschreitung nicht startet, wird ein Fallback zum Hard-Neustart ausgelöst.

Animation beim weichen Neustart anpassen

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

Am Ende der userspace-reboot-fs-remount-Aktion startet init den bootanim-Dienst. Dieser Dienst sucht nach den folgenden Animationsdateien in der angegebenen Reihenfolge und spielt die erste gefundene Datei ab:

  • /product/media/userspace-reboot.zip
  • /oem/media/userspace-reboot.zip
  • /system/media/userspace-reboot.zip
entsprechen.

Wenn keine spezifischen Animationsdateien für einen vorläufigen Neustart angegeben sind, zeigt bootanim eine standardmäßige android-Animation an.

Testen

Android 11 enthält eine Referenzimplementierung eines richtlinienbasierten Neustarts. Außerdem können Sie einen weichen Neustart mit CTS-Tests in UserspaceRebootHostTest prüfen.