A partire dal 2026, per allinearci al nostro modello di sviluppo trunk stabile e garantire la stabilità della piattaforma per l'ecosistema, pubblicheremo il codice sorgente su AOSP nel secondo e nel quarto trimestre. Per compilare e contribuire ad AOSP, utilizza android-latest-release. Il branch del manifest android-latest-release farà sempre riferimento alla release più recente pubblicata su AOSP. Per saperne di più, consulta la sezione Modifiche ad AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 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 aver richiesto un riavvio silenzioso (tramite PowerManager o da una shell), init esegue i seguenti passaggi:

Riceve sys.powerctl=reboot,userspace.
Avvia 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 silenzioso. 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 qualsiasi processo 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 silenzioso, userdata viene rimontato in modalità checkpointing durante l'azione userspace-reboot-fs-remount (vedi la sezione seguente per i dettagli). Un riavvio silenzioso viene considerato dopo che sys.boot_completed property è impostato su 1. Al termine del riavvio silenzioso, il display rimane spento e per riattivarlo è necessaria un'interazione utente esplicita.

Creazione di checkpoint del file system

Se è stato richiesto un checkpoint del file system prima del riavvio silenzioso, userdata viene rimontato in modalità di checkpoint durante il riavvio silenzioso. 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 del codice utilizzato nell'avvio del checkpointing normale.

Se viene utilizzato un keyring a livello di file system per gestire le chiavi criptate con credenziali (CE) e criptate con 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 silenzioso 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 silenzioso (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 si avvia correttamente (ovvero sys.boot_completed=1) entro un determinato timeout.

Configurazione per dispositivo

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

init.userspace_reboot.is_supported controlla quando un dispositivo può eseguire un riavvio silenzioso. 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 si arresta 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 silenzioso

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

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 silenzioso, bootanim mostra un'animazione android predefinita.

Test

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