Android 11 supporta i riavvii morbidi, che sono
i riavvii in fase di runtime dei processi nello spazio utente utilizzato per applicare gli aggiornamenti
richiedono il riavvio (ad esempio, gli aggiornamenti dei pacchetti APEX). Attualmente,
Il riavvio è limitato ai processi avviati dopo il montaggio di userdata
.
È richiesto un riavvio software nei seguenti modi:
Da
PowerManager
, chiamandoPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Dalla shell, utilizzando
adb shell svc power reboot userspace
oadb reboot userspace
Dopo un riavvio soft, l'archivio con crittografia delle credenziali rimane sbloccato.
Se un dispositivo supporta i riavvii morbidi,
Il metodo API PowerManager.isRebootingUserspace()
restituisce true
e il valore
della proprietà di sistema init.userspace_reboot.is_supported
è uguale a 1
.
Se il dispositivo non supporta i riavvii flessibili, la chiamata a
PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
, adb reboot
userspace
e adb shell svc power reboot userspace
non riusciti.
Esecuzione riavvio informale
Dopo aver richiesto un riavvio soft (tramite PowerManager
o una shell),
init
esegue questi passaggi:
Riceve
sys.powerctl=reboot,userspace
.Crea un fork separato
UserspaceRebootWatchdogThread()
per monitorare il riavvio software.Attiva un'azione
userspace-reboot-requested
, che reimposta tutto il sistema che potrebbero influire sul riavvio software. Proprietà interessate: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
Le proprietà riportate sopra devono essere impostate di nuovo durante la sequenza di avvio. Se necessario, può reimpostare altre proprietà. Per alcuni esempi, fai riferimento
on userspace-reboot-requested
azione inrootdir/init.rc
Esegue il
DoUserspaceReboot
, che esegue le seguenti azioni:- Invia
SIGTERM
ai processi avviati dopo che è stato montatouserdata
e ne attende l'interruzione. - Una volta raggiunto il timeout, invia
SIGKILL
per terminare qualsiasi esecuzione i processi di machine learning. - Chiama
/system/bin/vdc volume reset
. - Smonta il dispositivo di supporto zRAM.
- Smonta i pacchetti APEX attivi.
- Torna allo spazio dei nomi montaggio bootstrap.
- Attiva il
userspace-reboot-resume
un'azione.
- Invia
Se il checkpoint del file system è stato richiesto prima del riavvio software,
userdata
viene rimontato in modalità di checkpoint durante
userspace-reboot-fs-remount
(per informazioni dettagliate, consulta la sezione seguente). R
il riavvio soft viene considerato dopo l'impostazione di sys.boot_completed property
a 1
. Al termine del riavvio soft, il display rimane spento e
è necessaria un'interazione esplicita dell'utente per riattivarlo.
Checkpoint del file system
Se è stato richiesto un checkpoint del file system prima del riavvio software,
userdata
viene rimontato in modalità di checkpoint durante il riavvio soft.
La logica di rimontaggio è implementata nella
fs_mgr_remount_userdata_into_checkpointing
e la differenza tra i metodi di checkpoint. Nello specifico, quando
userdata
supporta:
Checkpoint a livello di file system (ad esempio,
f2fs
),userdata
è rimontato con l'opzionecheckpoint=disable
.Checkpoint a livello di blocco (ad esempio,
ext4
), dopodiché/data
viene smontato e tutti i dispositivi principali su cui era montato sopra distrutte. Successivamente, il comandouserdata
viene montato utilizzando lo stesso percorso del codice utilizzato in normale avvio di checkpoint.
Se un keyring a livello di file system viene utilizzato per gestire la crittografia delle credenziali (CE)
chiavi criptate in base al dispositivo (DE), dopodiché le chiavi andranno perse dopo lo smontaggio di userdata
. A
consentire il ripristino delle chiavi durante l'installazione di una chiave in un keyring del file system, vold
installa anche la stessa chiave di tipo fscrypt-provisioning
a livello di sessione
il keyring. Quando viene chiamato init_user0
, vold
reinstalla le chiavi nel file
il keyring del sistema.
Usa il riavvio forzato
Per assicurarti che un riavvio temporaneo non lasci il dispositivo in uno stato inutilizzabile: Android 11 include una procedura di riserva al riavvio forzato, Vengono attivati quando si verifica una delle seguenti condizioni:
- Un dispositivo non avvia il riavvio soft (ossia
sys.init.userspace_reboot.in_progress=1
) entro un determinato timeout. - Un processo non si arresta entro un determinato timeout.
- L'operazione
/system/bin/vdc volume reset
non va a buon fine. - Lo smontaggio del dispositivo zRAM non riesce.
- Un pacchetto APEX attivo si smonta in modo errato.
- Un tentativo di rimontare
userdata
in modalità di checkpoint non va a buon fine. - Un dispositivo non si avvia correttamente (ossia
sys.boot_completed=1
) all'interno di un un determinato timeout.
Configurazione per dispositivo
Alcuni aspetti del riavvio soft possono essere ottimizzati modificando i valori dei seguenti elementi proprietà:
init.userspace_reboot.is_supported
stabilisce quando un dispositivo può eseguire una riavvio soft. Se il valore di questa proprietà èfalse
,0
o non è specificato, i tentativi di riavvio vengono rifiutati.init.userspace_reboot.sigkill.timeoutmillis
controlla il timeout in millisecondi per l'arresto dei processi che hanno ricevuto un segnaleSIGKILL
. Se uno di i processi non si arrestano in un determinato timeout, quindi viene eseguito viene attivato il riavvio.init.userspace_reboot.sigterm.timeoutmillis
controlla il timeout in millisecondi per la terminazione dei processi che hanno ricevuto un segnaleSIGTERM
. Tutti i processi che non sono riusciti a essere terminati nel timeout specificato ricevono IndicatoreSIGKILL
.init.userspace_reboot.started.timeoutmillis
controlla il timeout in di millisecondi per avviare il soft start, ovverosys.init.userspace_reboot.in_progress=1
). Se un dispositivo non si avvia soft riavvio entro un determinato timeout, viene attivata l'opzione di riserva a riavvio forzato.init.userspace_reboot.userdata_remount.timeoutmillis
controlla il timeout in millisecondi per smontareuserdata
. Se un dispositivo non riesce a smontareuserdata
entro il timeout specificato, viene attivato un fallback a riavvio forzato.init.userspace_reboot.watchdog.timeoutmillis
controlla il timeout per un dispositivo (sys.boot_completed=1
). Se un dispositivo non si avvia entro un determinato timeout, il passaggio a un riavvio forzato attivata.
Personalizza l'animazione durante il riavvio soft
L'implementazione di riferimento di un riavvio temporaneo include la possibilità di personalizzare dell'animazione mostrata durante il riavvio soft.
Al termine dell'azione userspace-reboot-fs-remount
, init
avvia la
Servizio bootanim
. Questo servizio cerca l'esistenza dei seguenti
file di animazione, nell'ordine elencato, e riproduce il primo che trova:
/product/media/userspace-reboot.zip
/oem/media/userspace-reboot.zip
/system/media/userspace-reboot.zip
Se non vengono specificati file di animazione specifici per il riavvio soft, bootanim
mostra un'immagine
animazione android
predefinita.
Test
Android 11 include un'implementazione di riferimento di un
riavvio soft. Inoltre, puoi verificare un riavvio temporaneo utilizzando CTS
test in
UserspaceRebootHostTest