Weiche Neustarts

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

  • Von der Shell aus mit adb shell svc power reboot userspace oder adb 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:

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

  2. Verzweigt einen separaten UserspaceRebootWatchdogThread() -Prozess, um den Soft-Neustart zu überwachen.

  3. 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 in rootdir/init.rc .

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

    1. Sendet SIGTERM an Prozesse, die nach dem Mounten userdata gestartet wurden, und wartet darauf, dass sie gestoppt werden.
    2. Nach Erreichen des Timeouts wird SIGKILL gesendet, um alle laufenden Prozesse abzubrechen.
    3. Ruft /system/bin/vdc volume reset auf.
    4. Hebt die Bereitstellung des zRAM-Backup-Geräts auf.
    5. Hebt die Bereitstellung aktiver APEX-Pakete auf.
    6. Wechselt zurück zum Bootstrap-Mount-Namespace.
    7. Löst die Aktion userspace-reboot-resume aus.

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 ) werden userdata mit der Option checkpoint=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 werden userdata 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 Eigenschaft false , 0 oder nicht angegeben ist, werden Neustartversuche abgelehnt.
  • init.userspace_reboot.sigkill.timeoutmillis steuert das Timeout in Millisekunden für Prozesse, die ein SIGKILL 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 ein SIGTERM Signal zum Beenden erhalten haben. Alle Prozesse, die innerhalb des angegebenen Timeouts nicht beendet werden konnten, erhalten ein SIGKILL 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 Bereitstellung userdata aufzuheben. Wenn ein Gerät userdata 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.