Soft-Neustarts (bis AOSP 14)

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 Anmeldedatenspeicher 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 Soft-Neustarts

Nachdem ein richtlinienkonformer Neustart angefordert wurde (über PowerManager oder eine Shell), 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 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. Nach dem richtlinienbasierten Neustart bleibt das Display aus und es ist eine explizite Nutzerinteraktion erforderlich, um es zu aktivieren.

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 Neumontage ist in der Funktion fs_mgr_remount_userdata_into_checkpointing implementiert und unterscheidet sich je nach Checkpoint-Methode. Insbesondere, wenn userdata Folgendes unterstützt:

• Prüfpunkt 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 verwendet wird, um mit Anmeldedaten verschlüsselte (CE) und geräteverschlüsselte (DE) Schlüssel zu verwalten, gehen die Schlüssel verloren, nachdem userdata getrennt wurde. 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 richtlinienbasierten Neustart nicht unbrauchbar wird, gibt es in Android 11 einen Fallback zum Hard-Reset, der ausgelöst wird, wenn eine der folgenden Bedingungen erfüllt ist:

• Ein Gerät startet innerhalb eines bestimmten Zeitlimits nicht durch einen richtlinienbasierten Neustart (sys.init.userspace_reboot.in_progress=1).
• Ein Prozess wird nicht innerhalb einer bestimmten Zeitüberschreitung beendet.
• Der Vorgang /system/bin/vdc volume reset schlägt fehl.
• Das Trennen des zRAM-Geräts schlägt fehl.
• Ein aktives APEX-Paket wird nicht richtig getrennt.
• Der Versuch, userdata im Checkpoint-Modus neu 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 nicht innerhalb der angegebenen Zeitüberschreitung beendet wird, wird ein Fallback zum 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 Beginn 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 auf einem Gerät userdata nicht innerhalb der angegebenen Zeitdauer bereitgestellt wird, wird ein Fallback zum 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 in der angegebenen Reihenfolge nach den folgenden Animationsdateien und spielt die erste davon ab:

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

entsprechen.

Wenn keine Animationen für den sanften Neustart angegeben sind, zeigt bootanim die Standardanimation android 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.