A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Riavvii soft (<= AOSP 14)
Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Android 11 supporta i riavvii soft, ovvero i riavvii in fase di esecuzione dei processi nello spazio utente utilizzati per applicare gli aggiornamenti che richiedono un riavvio (ad esempio gli aggiornamenti ai pacchetti APEX). Al momento, il riavvio morbido è limitato ai processi avviati dopo il montaggio di userdata.

Un riavvio soft viene richiesto nei seguenti modi:

Da PowerManager, chiamando PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Dalla shell, utilizzando adb shell svc power reboot userspace o adb reboot userspace

Dopo un riavvio soft, lo spazio di archiviazione criptato delle credenziali rimane sbloccato.

Se un dispositivo supporta i riavvii soft, il metodo dell'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 soft, le chiamate a PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace e adb shell svc power reboot userspace non vanno a buon fine.

Esecuzione del riavvio silenzioso

Dopo che è stato richiesto un riavvio soft (tramite PowerManager o da una shell), init esegue i seguenti passaggi:

Riceve sys.powerctl=reboot,userspace.
Forka un processo UserspaceRebootWatchdogThread() separato per monitorare il riavvio graduale.
Attiva un'azione userspace-reboot-requested, che reimposta tutte le proprietà sistema che potrebbero influire sul riavvio graduale. Strutture 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à sopra indicate devono essere impostate di nuovo durante la sequenza di avvio. Se necessario, puoi reimpostare proprietà aggiuntive. Per esempi, consulta l'azione on userspace-reboot-requested in rootdir/init.rc.
Esegue la funzione DoUserspaceReboot, che esegue le seguenti azioni:
1. Invia SIGTERM ai processi avviati dopo il montaggio di userdata e aspetta che si fermino.
2. Una volta raggiunto il timeout, invia SIGKILL per interrompere tutte le attività in esecuzione.
3. Chiamate /system/bin/vdc volume reset.
4. Smonta il dispositivo di supporto zRAM.
5. Smonta i pacchetti APEX attivi.
6. Torna allo spazio dei nomi di montaggio del bootstrap.
7. Attiva l'azione userspace-reboot-resume.

Se il checkpoint del file system è stato richiesto prima del riavvio soft,userdata viene montato di nuovo in modalità di checkpoint durante l'azioneuserspace-reboot-fs-remount (per maggiori dettagli, vedi la sezione seguente). Un riavvio graduale viene considerato dopo che sys.boot_completed property è impostato su 1. Al termine del riavvio soft, il display rimane spento e per riattivarlo è necessaria un'interazione esplicita dell'utente.

Controllo dei punti di controllo del file system

Se è stato richiesto un checkpoint del file system prima del riavvio graduale,userdata viene montato di nuovo in modalità di checkpoint durante il riavvio graduale. La logica di rimontaggio è implementata nella funzione fs_mgr_remount_userdata_into_checkpointing e varia in base ai metodi di controllo. Nello specifico, quando userdata supporta:

Controllo dei punti di controllo a livello di file system (ad esempio f2fs), userdata viene nuovamente montato con l'opzione checkpoint=disable.
Controllo dei punti di controllo a livello di blocco (ad esempio ext4), quindi /data viene smontato e tutti i dispositivi mapper dei dispositivi principali su cui è stato montato vengono distrutti. Successivamente, userdata viene montato utilizzando lo stesso percorso del codice utilizzato nel normale avvio con controllo dei punti di controllo.

Se viene utilizzato un portachiavi a livello di file system per gestire le chiavi con crittografia delle credenziali (CE) e con crittografia del dispositivo (DE), le chiavi vengono perse dopo lo smontaggio di userdata. Per consentire il ripristino delle chiavi, quando ne installi una in un portachiavi del file system, vold installa anche la stessa chiave di tipo fscrypt-provisioning nel portachiavi a livello di sessione. Quando viene chiamato init_user0, vold reinstalla le chiavi nel portachiavi del sistema di file.

Ripristino tramite riavvio forzato

Per assicurarti che un riavvio soft non lasci un dispositivo in uno stato inutilizzabile, Android 11 include un fallback al riavvio forzato che viene attivato quando viene soddisfatta una delle seguenti condizioni:

Un dispositivo non riesce ad avviare il riavvio soft (ovvero sys.init.userspace_reboot.in_progress=1) entro un determinato timeout.
Un processo non si interrompe 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 viene smontato in modo errato.
Un tentativo di riavviare userdata in modalità di controllo non va a buon fine.
Un dispositivo non riesce ad avviarsi correttamente (ovvero sys.boot_completed=1) entro un determinato tempo di attesa.

Configurazione per dispositivo

Alcuni aspetti del riavvio graduale possono essere ottimizzati modificando i valori delle seguenti proprietà:

init.userspace_reboot.is_supported controlla quando un dispositivo può eseguire un riavvio graduale. 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 i processi che hanno ricevuto un segnale SIGKILL di interruzione. Se uno dei processi non si arresta nel tempo di spegnimento specificato, viene attivato un riavvio forzato.
init.userspace_reboot.sigterm.timeoutmillis controlla il timeout in millisecondi per l'interruzione dei processi che hanno ricevuto un segnale SIGTERM. Tutti i processi che non sono riusciti a terminare nel timeout specificato ricevono un SIGKILL indicatore.
init.userspace_reboot.started.timeoutmillis controlla il timeout in millisecondi per l'avvio del riavvio silenzioso (ovvero sys.init.userspace_reboot.in_progress=1). Se un dispositivo non riesce ad avviare il riavvio silenzioso entro il timeout specificato, viene attivato il fallback al riavvio forzato.
init.userspace_reboot.userdata_remount.timeoutmillis controlla il timeout in millisecondi per smontare userdata. Se un dispositivo non riesce a smontare userdata entro il timeout specificato, viene attivato il fallback al riavvio forzato.
init.userspace_reboot.watchdog.timeoutmillis controlla il timeout per l'avvio corretto di un dispositivo (ovvero sys.boot_completed=1). Se un dispositivo non riesce ad avviarsi entro il timeout specificato, viene attivato un fallback al riavvio forzato.

Personalizzare l'animazione durante il riavvio soft

L'implementazione di riferimento di un riavvio soft include la possibilità di personalizzare l'animazione mostrata durante il riavvio soft.

Al termine dell'azione userspace-reboot-fs-remount, init avvia il 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'animazione android predefinita.

Test

Android 11 include un'implementazione di riferimento di un riavvio graduale. Inoltre, puoi verificare un riavvio soft utilizzando i test CTS in UserspaceRebootHostTest.