Sanfte Neustarts

Android 11 unterstützt weiche Neustarts, d. h. Laufzeitneustarts von Prozessen im Benutzerbereich, die zum Anwenden von Updates verwendet werden, die einen Neustart erfordern (z. B. Updates für APEX-Pakete). Derzeit ist weich Neustart Prozesse beschränkt, begann nach userdata angebracht war.

Ein sanfter Neustart wird auf folgende Weise angefordert:

  • Von PowerManager , durch den Aufruf PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Von der Schale, mit adb shell svc power reboot userspace - adb reboot userspace adb shell svc power reboot userspace oder adb reboot userspace - adb reboot userspace

Nach einem sanften Neustart bleibt der mit Anmeldeinformationen verschlüsselte Speicher entsperrt.

Wenn ein Gerät neu startet soft unterstützt, dann werden die PowerManager.isRebootingUserspace() API - Methode zurückgibt true , und der Wert der Systemeigenschaft init.userspace_reboot.is_supported ist gleich 1 .

Wenn das Gerät nicht weich Neustart nicht unterstützt, ruft dann zu PowerManager.reboot(PowerManager.REBOOT_USERSPACE) , adb reboot userspace - adb shell svc power reboot userspace adb reboot userspace und adb shell svc power reboot userspace - adb shell svc power reboot userspace scheitern.

Soft-Restart-Ausführung

Nach einem Soft Neustart (durch angefordert wird PowerManager oder von einem Shell), init die folgenden Schritte ausführen:

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

  2. Gabeln einem separaten UserspaceRebootWatchdogThread() Prozess des weichen Neustart zu überwachen.

  3. Löst eine userspace-reboot-requested - userspace-reboot-requested Aktion, die alle Systemeigenschaften setzt, die den weichen 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 obigen Eigenschaften sollten während des Bootvorgangs erneut eingestellt werden. Bei Bedarf können Sie zusätzliche Eigenschaften zurücksetzen. Beispiele finden Sie die on userspace-reboot-requested - rootdir/init.rc on userspace-reboot-requested Aktion in rootdir/init.rc .

  4. Läuft die DoUserspaceReboot - Funktion, die die folgenden Aktionen ausführt:

    1. Sendet SIGTERM an Prozesse gestartet , nachdem userdata wurde montiert und wartet darauf , sie zu stoppen.
    2. Nachdem das Timeout erreicht ist, sendet SIGKILL alle laufenden Prozesse zu töten.
    3. Anrufe /system/bin/vdc volume reset .
    4. Unmounten des zRAM-Backing-Geräts.
    5. Unmounten aktiver APEX-Pakete.
    6. Wechselt zurück zum Bootstrap-Mount-Namespace.
    7. Löst die userspace-reboot-resume - userspace-reboot-resume Aktion.

Wenn Dateisystem Prüfpunkten vor dem weichen Neustart angefordert wurde, userdata in Betrieb während der Prüfpunkte remounted userspace-reboot-fs-remount - userspace-reboot-fs-remount Aktion (siehe den folgenden Abschnitt). Ein weicher Neustart gilt nach der sys.boot_completed property gesetzt ist 1 . Am Ende des Soft-Restarts bleibt das Display ausgeschaltet und es ist eine explizite Benutzerinteraktion erforderlich, um es aufzuwecken.

Dateisystem-Checkpointing

Wenn ein Dateisystem Kontrollpunkt vor dem weichen Neustart angefordert wurde, userdata in Prüfpunktverfahrens Modus während des Soft - Neustart wieder montiert. Remontage wird in der Logik implementiert fs_mgr_remount_userdata_into_checkpointing Funktion und unterscheidet zwischen Checkpointing Methoden. Insbesondere wird , wenn userdata Träger:

  • Dateisystemebene Prüfpunkten (zB f2fs ), userdata mit der remounted checkpoint=disable Option.

  • Blockebene Checkpointing (beispielsweise ext4 ), dann wird /data ist unmontiert und alle die übergeordnete Gerät Mapper Geräte wurde montiert auf der Oberseite werden zerstört. Als nächstes userdata wird montiert mit dem gleichen Codepfad im normalen Prüfpunkten Boot verwendet als.

Wenn ein Dateisystemebene Schlüsselanhänger verwendet wird Credential-verschlüsselt (CE) und geräte verschlüsselt (DE) Schlüssel zu verwalten, dann werden die Schlüssel verloren , nachdem userdata abgehängt. Um Schlüsselwiederherstellung zu ermöglichen, wenn ein Schlüssel zu einem Dateisystem Keyring Installation vold installiert auch die gleichen Schlüssel vom Typ fscrypt-provisioning auf Sitzungsebene Schlüsselbund. Wenn init_user0 genannt wird, vold neu installiert den Schlüssel im Dateisystem Schlüsselbund.

Fallback auf Hard Reboot

Um sicherzustellen, dass ein sanfter Neustart ein Gerät nicht in einem unbrauchbaren Zustand zurücklässt, bietet Android 11 einen Fallback auf einen harten Neustart, der ausgelöst wird, wenn eine der folgenden Bedingungen erfüllt ist:

  • Ein Gerät ausfällt soft restart starten (das ist sys.init.userspace_reboot.in_progress=1 ) innerhalb einer vorgegebenen Timeout.
  • Ein Prozess kann nicht innerhalb eines bestimmten Timeouts gestoppt werden.
  • Der /system/bin/vdc volume reset - /system/bin/vdc volume reset - Vorgang fehlschlägt.
  • Das Aushängen des zRAM-Geräts schlägt fehl.
  • Ein aktives APEX-Paket wird falsch ausgehängt.
  • Ein Versuch, Remount userdata in Prüfpunkten Modus ausfällt.
  • Ein Gerät ausfällt , um erfolgreich Boot (das heißt, sys.boot_completed=1 ) innerhalb einer vorgegebenen Timeout.

Konfiguration pro Gerät

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

  • init.userspace_reboot.is_supported steuert , wenn ein Gerät mit einem weichen Neustart durchführen kann. Wenn der Wert dieser Eigenschaft ist false , 0 oder nicht angegeben ist , dann versucht neu zu starten , werden zurückgewiesen.
  • init.userspace_reboot.sigkill.timeoutmillis steuert die Timeout in Millisekunden für Prozesse , die ein empfangenes SIGKILL Signal zu stoppen. Wenn einer der Prozesse innerhalb des angegebenen Timeouts nicht stoppt, wird ein Fallback auf einen harten Neustart ausgelöst.
  • init.userspace_reboot.sigterm.timeoutmillis steuert die Timeout in Millisekunden für Prozesse , die ein empfangenes SIGTERM Signal zu beenden. Alle Prozesse , die in der angegebenen Timeout zu beenden , scheiterten erhalten ein SIGKILL - Signal.
  • init.userspace_reboot.started.timeoutmillis steuert die Timeout in Millisekunden für soft restart zu starten (das heißt, sys.init.userspace_reboot.in_progress=1 ). Wenn ein Gerät den Soft-Restart nicht innerhalb des angegebenen Timeouts startet, wird ein Fallback auf einen Hard-Reboot ausgelöst.
  • init.userspace_reboot.userdata_remount.timeoutmillis steuert die Timeout in Millisekunden auszuhängen userdata . Wenn ein Gerät ausfällt unmout userdata innerhalb der gegebenen Zeitüberschreitung wird ein Rückfall auf harten Neustart ausgelöst.
  • init.userspace_reboot.watchdog.timeoutmillis steuert die Zeitüberschreitung für ein Gerät zum erfolgreichen Boot (das heißt, sys.boot_completed=1 ). Wenn ein Gerät innerhalb des angegebenen Timeouts nicht booten kann, wird ein Fallback auf einen harten Neustart ausgelöst.

Anpassen der Animation während des sanften Neustarts

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

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

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

Wenn keine Soft - Neustart spezifische Animationsdateien angegeben werden, bootanim zeigt eine Standard - android - Animation.

Testen

Android 11 enthält eine Referenzimplementierung eines sanften Neustarts. Darüber hinaus können Sie einen weichen Neustart mit CTS - Tests in verifizieren UserspaceRebootHostTest .