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)

Android 11 supporta i riavvii soft, ovvero i riavvii in fase di runtime 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 soft è limitato ai processi avviati dopo il montaggio di userdata.

Un riavvio soft viene richiesto nei seguenti modi:

A partire dal giorno PowerManager, chiamando il numero PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Dalla shell, utilizzando adb shell svc power reboot userspace o adb reboot userspace

Dopo un riavvio soft, l'archivio delle credenziali criptato 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 aver richiesto un riavvio soft (tramite PowerManager o da una shell), init esegue i seguenti passaggi:

Riceve sys.powerctl=reboot,userspace.
Forca un processo UserspaceRebootWatchdogThread() separato per monitorare il riavvio soft.
Attiva un'azione userspace-reboot-requested, che reimposta tutte le proprietà di sistema che potrebbero influire sul riavvio soft. 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à precedenti devono essere impostate di nuovo durante la sequenza di avvio. Se necessario, puoi reimpostare le proprietà aggiuntive. Per alcuni 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 attende che si arrestino.
2. Una volta raggiunto il timeout, invia SIGKILL per terminare tutti i processi 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 è stato richiesto il checkpointing del file system prima del riavvio soft, userdata viene rimontato in modalità checkpointing durante l'azione userspace-reboot-fs-remount (vedi la sezione seguente per i dettagli). Un riavvio soft 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.

Checkpointing del file system

Se è stato richiesto un checkpoint del file system prima del riavvio soft, userdata viene rimontato in modalità di checkpoint durante il riavvio soft. La logica di rimontaggio è implementata nella funzione fs_mgr_remount_userdata_into_checkpointing e varia a seconda dei metodi di checkpointing. Nello specifico, quando userdata supporta:

Checkpointing a livello di file system (ad esempio, f2fs), userdata viene rimontato con l'opzione checkpoint=disable.
Checkpointing a livello di blocco (ad esempio ext4), quindi /data viene smontato e tutti i dispositivi mapper del dispositivo principale su cui era montato vengono distrutti. Successivamente, userdata viene montato utilizzando lo stesso percorso di codice utilizzato nell'avvio del normale checkpoint.

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

Ripristino del riavvio forzato

Per garantire che un riavvio soft non lasci un dispositivo in uno stato inutilizzabile, Android 11 include un fallback al riavvio forzato che viene attivato quando si verifica 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 viene interrotto entro un determinato timeout.
L'operazione /system/bin/vdc volume reset non riesce.
Lo smontaggio del dispositivo zRAM non riesce.
Un pacchetto APEX attivo viene smontato in modo errato.
Un tentativo di rimontaggio di userdata in modalità di checkpointing non va a buon fine.
Un dispositivo non riesce ad avviarsi correttamente (ovvero sys.boot_completed=1) entro un determinato timeout.

Configurazione per dispositivo

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

init.userspace_reboot.is_supported controlla quando un dispositivo può eseguire un 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 i processi che hanno ricevuto un segnale SIGKILL per l'interruzione. Se uno dei processi non viene interrotto nel timeout specificato, viene attivato un fallback al riavvio forzato.
init.userspace_reboot.sigterm.timeoutmillis controlla il timeout in millisecondi per i processi che hanno ricevuto un segnale SIGTERM per terminare. Tutti i processi che non sono stati terminati nel timeout specificato ricevono un segnale SIGKILL.
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 un fallback al riavvio forzato.
init.userspace_reboot.userdata_remount.timeoutmillis controlla il timeout in millisecondi per smontare userdata. Se un dispositivo non viene smontato userdata entro il timeout specificato, viene attivato un 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 si avvia 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 soft. Inoltre, puoi verificare un riavvio soft utilizzando i test CTS in UserspaceRebootHostTest.