Riavvii temporanei (<= AOSP 14)

Android 11 supporta i riavvii soft, ovvero riavvii in fase di esecuzione di processi nello spazio utente utilizzati per applicare aggiornamenti che richiedono un riavvio (ad esempio gli aggiornamenti ai pacchetti APEX). Al momento, il riavvio graduale è 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 software, 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 temporanei, le chiamate a PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace e adb shell svc power reboot userspace non andranno 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:

  1. Riceve sys.powerctl=reboot,userspace.

  2. Crea un fork di un processo UserspaceRebootWatchdogThread() separato per monitorare il riavvio software.

  3. Attiva un'azione userspace-reboot-requested, che reimposta tutte le proprietà di sistema che potrebbero influire sul riavvio graduale. 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à 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.

  4. Esegue la funzione DoUserspaceReboot, che esegue le seguenti azioni:

    1. Invia SIGTERM ai processi avviati dopo il montaggio di userdata e attende l'arresto.
    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 montaggio bootstrap.
    7. Attiva l'azione userspace-reboot-resume.

Se il checkpoint del file system è stato richiesto prima del riavvio software, userdata viene rimontato in modalità di checkpoint durante l'azione userspace-reboot-fs-remount (per maggiori dettagli, consulta 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.

  • Checkpoint a livello di blocco (ad esempio, ext4), /data viene smontato e tutti i dispositivi Mapper dispositivi padre su cui era montato vengono eliminati. Successivamente, userdata viene montato utilizzando lo stesso percorso di codice utilizzato nel normale avvio con checkpoint.

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.

Usa il 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 rimontare userdata in modalità di checkpoint 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 morbido. 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 timeout specificato, viene attivato un fallback al 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 essere terminati nel timeout specificato ricevono un indicatore 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 il fallback al riavvio forzato.
  • init.userspace_reboot.userdata_remount.timeoutmillis controlla il timeout in millisecondi per lo smontaggio di 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.