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 AnrufPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Über die Shell mit
adb shell svc power reboot userspace
oderadb 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:
Erhält
sys.powerctl=reboot,userspace
.Verzweigt ein separates
UserspaceRebootWatchdogThread()
um den Softneustart zu überwachen.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 inrootdir/init.rc
Führt den
DoUserspaceReboot
, die folgende Aktionen ausführt:- Sendet
SIGTERM
an Prozesse, die gestartet wurden, nachdemuserdata
bereitgestellt wurde und bis sie aufhören. - Nach Ablauf des Zeitlimits wird
SIGKILL
gesendet, um alle ausgeführten Prozesse. /system/bin/vdc volume reset
wird angerufen.- Trennt das ZRAM-Sicherungsgerät.
- Trennt aktive APEX-Pakete.
- Wechselt zurück zum Bootstrap-Bereitstellungs-Namespace.
- Löst das
userspace-reboot-resume
aus Aktion ausführen.
- Sendet
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 Optioncheckpoint=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 wirduserdata
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 Attributsfalse
,0
oder nicht angegeben ist, wird der Neustart abgelehnt.init.userspace_reboot.sigkill.timeoutmillis
steuert das Zeitlimit in Millisekunden, um Prozesse zu stoppen, die einSIGKILL
-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 einSIGTERM
-Signal empfangen haben, zum Beenden. Alle Die Prozesse, die innerhalb des angegebenen Zeitlimits nicht beendet werden konnten, erhalten eineSIGKILL
-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 vonuserdata
. 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