Sanfte Neustarts

Android 11 unterstützt sog. Neustarts, Laufzeitneustarts von Prozessen im Userspace, in dem Updates angewendet werden, einen Neustart erfordern, z. B. bei Aktualisierungen von APEX-Paketen. Derzeit weich Neustart ist auf Prozesse beschränkt, die gestartet wurden, nachdem userdata bereitgestellt wurde.

Ein vorläufiger Neustart wird folgendermaßen angefordert:

• Ab PowerManager, per Anruf PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

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

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

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

Unterstützt das Gerät Soft-Neustarts nicht, werden Anrufe an PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace und adb shell svc power reboot userspace schlagen fehl.

Ausführung von vorläufigem Neustart

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

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

2. Verzweigt ein separates UserspaceRebootWatchdogThread() um den Softneustart zu überwachen.

3. Löst eine userspace-reboot-requested-Aktion aus, mit der das gesamte System zurückgesetzt wird Eigenschaften, die sich auf den weichen 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 Attribute sollten während der Startsequenz neu festgelegt werden. Bei Bedarf können Sie können zusätzliche Eigenschaften zurücksetzen. Beispiele finden Sie in der on userspace-reboot-requested Aktion in rootdir/init.rc

4. Führt den DoUserspaceReboot , die folgende Aktionen ausführt:

   1. Sendet SIGTERM an Prozesse, die gestartet wurden, nachdem userdata bereitgestellt wurde und bis sie aufhören.
   2. Nach Ablauf des Zeitlimits wird SIGKILL gesendet, um alle ausgeführten Prozesse.
   3. /system/bin/vdc volume reset wird angerufen.
   4. Trennt das ZRAM-Sicherungsgerät.
   5. Trennt aktive APEX-Pakete.
   6. Wechselt zurück zum Bootstrap-Bereitstellungs-Namespace.
   7. Löst das userspace-reboot-resume aus Aktion ausführen.

Wenn vor dem weichen Neustart eine Prüfpunktausführung des Dateisystems angefordert wurde, userdata wird während des folgenden Zeitraums wieder im Prüfpunktmodus bereitgestellt: userspace-reboot-fs-remount-Aktion (weitere Informationen finden Sie im folgenden Abschnitt). A wird ein vorläufiger Neustart berücksichtigt, nachdem sys.boot_completed property festgelegt wurde an 1. Nach Abschluss des Soft-Neustarts bleibt das Display ausgeschaltet und ist eine explizite Nutzerinteraktion erforderlich, um den Ruhemodus zu beenden.

Prüfpunktausführung des Dateisystems

Wurde vor dem Soft-Neustart ein Dateisystem-Prüfpunkt angefordert, userdata wird während des Soft-Neustarts im Prüfpunktmodus wieder bereitgestellt. Die Logik für die erneute Bereitstellung ist in der fs_mgr_remount_userdata_into_checkpointing und unterscheidet sich bei den Prüfpunktmethoden. Wenn vor allem userdata unterstützt:

• Prüfpunktausführung auf Dateisystemebene (z. B. f2fs), userdata ist mit der Option checkpoint=disable wieder angebracht.

• Prüfpunktausführung auf Blockebene (z. B. ext4), dann wird /data getrennt und alle übergeordneten Mapper-Geräte, auf denen das Gerät montiert wurde, zerstört. Als Nächstes wird userdata mit demselben Codepfad bereitgestellt, der in Prüfpunktausführung normal.

Ob ein Schlüsselbund auf Dateisystemebene verwendet wird, um Anmeldedaten verschlüsselt (CE) zu verwalten geräteverschlüsselten DE-Schlüsseln, gehen die Schlüssel nach dem Trennen von userdata verloren. Bis Wiederherstellung von Schlüsseln zulassen, wenn ein Schlüssel in einem Dateisystem-Schlüsselbund installiert wird, vold Außerdem wird derselbe Schlüssel vom Typ fscrypt-provisioning auf Sitzungsebene installiert. Schlüsselbund enthält. Wenn init_user0 aufgerufen wird, installiert vold die Schlüssel in der Datei neu Systemschlüsselring.

Fallback auf harten Neustart

So sorgen Sie dafür, dass ein Gerät bei einem vorläufigen Neustart nicht unbrauchbar wird: Android 11 bietet einen Fallback auf einen harten Neustart, der wird ausgelöst, wenn eine der folgenden Bedingungen erfüllt ist:

• Ein Gerät startet den Soft-Neustart nicht, d. h. sys.init.userspace_reboot.in_progress=1) innerhalb eines bestimmten Zeitlimits.
• 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 korrekt bereitgestellt.
• Ein Versuch, userdata wieder im Prüfpunktmodus bereitzustellen, schlägt fehl.
• Ein Gerät (sys.boot_completed=1) kann nicht innerhalb Zeitüberschreitung.

Gerätespezifische Konfiguration

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

• init.userspace_reboot.is_supported legt fest, wann ein Gerät Folgendes ausführen kann: einen vorläufigen Neustart. Wenn der Wert dieses Attributs false, 0 oder nicht angegeben ist, wird der Neustart abgelehnt.
• init.userspace_reboot.sigkill.timeoutmillis steuert das Zeitlimit in Millisekunden, um Prozesse zu stoppen, die ein SIGKILL-Signal empfangen haben. Wenn eines der Elemente werden die Prozesse nicht innerhalb des vorgegebenen Zeitlimits beendet, wird beim Fallback auf „harte“ wird ein Neustart ausgelöst.
• init.userspace_reboot.sigterm.timeoutmillis steuert das Zeitlimit in Millisekunden für Prozesse, die ein SIGTERM-Signal empfangen haben, zum Beenden. Alle Die Prozesse, die innerhalb des angegebenen Zeitlimits nicht beendet werden konnten, erhalten eine SIGKILL-Signal.
• init.userspace_reboot.started.timeoutmillis steuert das Zeitlimit in Millisekunden für den sanften Neustart (d. h. sys.init.userspace_reboot.in_progress=1). Wenn ein Gerät nicht mit einem weichen Startvorgang startet wird innerhalb des festgelegten Zeitlimits neu gestartet, wird ein Fallback auf einen harten Neustart ausgelöst.
• init.userspace_reboot.userdata_remount.timeoutmillis steuert das Zeitlimit in Millisekunden zum Trennen von userdata. Wenn ein Gerät nicht getrennt werden kann, userdata innerhalb des angegebenen Zeitlimits wird ein Fallback auf einen harten Neustart ausgelöst.
• init.userspace_reboot.watchdog.timeoutmillis steuert das Zeitlimit für eine Gerät gestartet werden kann (d. h. sys.boot_completed=1). Wenn ein Gerät nicht innerhalb des festgelegten Zeitlimits startet, ist ein Fallback auf einen harten Neustart ausgelöst.

Animation während des Soft-Neustarts anpassen

Die Referenzimplementierung eines weichen Neustarts bietet die Möglichkeit, Animation, die während des Soft-Neustarts angezeigt wird.

Am Ende der Aktion userspace-reboot-fs-remount startet init den bootanim-Dienst. Dieser Dienst prüft, ob Folgendes vorhanden ist: und gibt die erste gefundene Datei wieder:

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

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

Testen

Android 11 enthält eine Referenzimplementierung eines einen vorläufigen Neustart. Darüber hinaus können Sie einen Soft-Neustart mithilfe von CTS Tests in UserspaceRebootHostTest