Riavvii temporanei

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, chiamando PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Dalla shell, utilizzando adb shell svc power reboot userspace o adb 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:

  1. Riceve sys.powerctl=reboot,userspace.

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

  3. 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 in rootdir/init.rc

  4. Esegue il DoUserspaceReboot , che esegue le seguenti azioni:

    1. Invia SIGTERM ai processi avviati dopo che è stato montato userdata e ne attende l'interruzione.
    2. Una volta raggiunto il timeout, invia SIGKILL per terminare qualsiasi esecuzione i processi di machine learning.
    3. Chiama /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 il userspace-reboot-resume un'azione.

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'opzione checkpoint=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 comando userdata 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 segnale SIGKILL. 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 segnale SIGTERM. Tutti i processi che non sono riusciti a essere terminati nel timeout specificato ricevono Indicatore SIGKILL.
  • init.userspace_reboot.started.timeoutmillis controlla il timeout in di millisecondi per avviare il soft start, ovvero sys.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 smontare userdata. Se un dispositivo non riesce a smontare userdata 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.
di Gemini Advanced.

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
di Gemini Advanced.

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