Android 10 introduce il Checkpoint dei dati utente (UDC), che
consente ad Android di eseguire il rollback allo stato precedente quando un dispositivo Android over-the-air
L'aggiornamento (OTA) non va a buon fine. Con l'UDC, se un aggiornamento OTA di Android non va a buon fine, il dispositivo può
eseguire in sicurezza il rollback
allo stato precedente. Sebbene
Gli aggiornamenti A/B risolvono il problema per l'avvio anticipato e il rollback
non è supportata quando la partizione dei dati utente (montata su /data) viene modificata.
L'UDC consente al dispositivo di ripristinare la partizione dei dati utente anche dopo modificato. La funzionalità UDC raggiunge questo obiettivo con funzionalità di checkpoint file system, un'implementazione alternativa quando il file system non supporta punti di controllo, integrazione con il meccanismo A/B del bootloader e supporto aggiornamenti non A/B e supporto dell'associazione della versione della chiave e del rollback della chiave prevenzione.
Impatto sugli utenti
La funzionalità UDC migliora l'esperienza di aggiornamento OTA per gli utenti in quanto meno utenti perdono i propri dati quando un aggiornamento OTA non va a buon fine. Ciò può ridurre il numero di chiamate di assistenza dagli utenti che riscontrano problemi durante il processo di aggiornamento. Tuttavia, quando un'agenzia di viaggi online l'aggiornamento non riesce, gli utenti potrebbero notare che il dispositivo si riavvia più volte.
Come funziona
Funzionalità dei checkpoint in file system diversi
Per il file system F2FS, UDC aggiunge la funzionalità di checkpoint all'upstream 4.20 kernel Linux e il backporting in tutti i kernel comuni supportati dai dispositivi con Android 10.
Per gli altri file system, l'UDC utilizza un dispositivo virtuale di mappatura dei dispositivi chiamato dm_bow
per la funzionalità dei checkpoint. dm_bow si trova tra il dispositivo e il file
di un sistema operativo completo. Quando una partizione viene montata, viene generato un taglio che fa sì che il file system
emette comandi di ritaglio su tutti i blocchi liberi. dm_bow intercetta questi ritagli e usa
per creare una lista bloccata senza costi. Le operazioni di lettura e scrittura vengono quindi inviate al dispositivo
non sono stati modificati, ma prima che sia consentita la scrittura viene eseguito il backup dei dati necessari per il ripristino
fino a un blocco senza costi.
Processo di checkpoint
Quando viene montata una partizione con il flag checkpoint=fs/block, Android chiama
restoreCheckpoint sull'unità per consentire al dispositivo di ripristinare lo stato attuale
punto di controllo. init chiama quindi la funzione needsCheckpoint per determinare se
il dispositivo è in stato A/B del bootloader o ha impostato un nuovo tentativo di aggiornamento
conteggio. Se una delle due opzioni è vera, Android chiama createCheckpoint per aggiungere una montatura
o creare un dispositivo dm_bow.
Dopo aver montato la partizione, il codice del checkpoint viene chiamato per emettere i ritagli.
Il processo di avvio continua quindi normalmente. Presso LOCKED_BOOT_COMPLETE, Android
chiama commitCheckpoint per eseguire il commit del checkpoint attuale e dell'aggiornamento
continua normalmente.
Gestisci chiavi keymaster
Le chiavi Keymaster vengono utilizzate per la crittografia dei dispositivi o per altri scopi. Per gestire questi Android ritarda le chiamate di eliminazione delle chiavi fino al commit del checkpoint.
Monitorare lo stato di integrità
Un daemon di integrità verifica che lo spazio su disco sia sufficiente per creare
punto di controllo. Il daemon relativo alla salute si trova
cp_healthDaemon
tra Checkpoint.cpp.
Il daemon di integrità ha i seguenti comportamenti che possono essere configurati:
ro.sys.cp_msleeptime: Controlla la frequenza con cui il dispositivo verifica l'utilizzo del disco.ro.sys.cp_min_free_bytes: Controlla il valore minimo cercato dal daemon di integrità.ro.sys.cp_commit_on_full: Controlla se il daemon relativo all'integrità riavvia il dispositivo o esegue il commit della al checkpoint e continua quando il disco è pieno.
API Checkpoint
Le API Checkpoint vengono utilizzate dalla funzionalità UDC. Per altre API utilizzate dall'UDC, vedi
IVold.aidl
void startCheckpoint(int riprova)
Crea un checkpoint.
Il framework chiama questo metodo quando è pronto per avviare un aggiornamento. La
il checkpoint viene creato prima che i file system con checkpoint come i dati utente vengano
montato R/W dopo il riavvio. Se il numero di nuovi tentativi è positivo, l'API gestisce
nuovi tentativi di monitoraggio e il programma di aggiornamento chiama needsRollback per verificare se è presente
dell'aggiornamento. Se il numero di nuovi tentativi è -1, l'API rimanda al metodo A/B
il giudizio del bootloader.
Questo metodo non viene chiamato quando si esegue un normale aggiornamento A/B.
void commitChanges()
Esegue il commit delle modifiche.
Il framework chiama questo metodo dopo il riavvio, quando le modifiche sono pronte
impegnato. Viene chiamato prima dei dati (ad esempio immagini, video, SMS,
ricevuta della ricezione) viene scritto nei dati utente e prima del giorno BootComplete.
Se non esiste un aggiornamento con checkpoint attivo, questo metodo non ha alcun effetto.
abortChanges()
Forza il riavvio e torna al checkpoint. Abbandona tutte le modifiche dei dati utente dal primo riavvio.
Il framework chiama questo metodo dopo il riavvio, ma prima del giorno commitChanges.
Il valore retry_counter viene diminuito quando viene chiamato questo metodo. Le voci di log sono
generati.
bool needRollback()
Determina se è necessario un rollback.
Sui dispositivi non di checkpoint, restituisce false. Sui dispositivi di checkpoint, restituisce true
durante un avvio non di checkpoint.
Implementa UDC
Implementazione dei riferimenti
Per un esempio di come UDC può essere implementato, consulta dm-bow.c. Per ulteriore documentazione sulla funzione, vedi dm-bow.txt.
Configura
Nel file on fs nel file init.hardware.rc, assicurati di avere:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Nel file on late-fs nel file init.hardware.rc, assicurati di avere:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Nel file fstab.hardware, assicurati che /data sia taggato come latemount.
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs
Aggiungi partizione di metadati
L'UDC richiede una partizione di metadati per archiviare il numero di nuovi tentativi non bootloader e
chiave. Configura una partizione di metadati e montala anticipatamente su /metadata.
Nel file fstab.hardware, assicurati che /metadata sia taggato come earlymount
o first_stage_mount.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Inizializza la partizione su tutti gli zeri.
Aggiungi le seguenti righe a BoardConfig.mk:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Aggiorna sistemi
Sistemi F2FS
Per i sistemi che utilizzano F2FS per formattare i dati, assicurati che la tua versione di F2FS supporta i checkpoint. Per ulteriori informazioni, consulta la sezione Funzionalità di checkpoint in diversi file system.
Aggiungi il flag checkpoint=fs alla sezione <fs_mgr_flags> di fstab per
dispositivo montato in /data.
Sistemi non F2FS
Per i sistemi non F2FS, dm-bow deve essere abilitato nella configurazione del kernel.
Aggiungi il flag checkpoint=block alla sezione <fs_mgr_flags> di fstab per
dispositivo montato in /data.
Controlla i log
Le voci di log vengono generate quando vengono chiamate le API Checkpoint.
Convalida
Per testare l'implementazione UDC, esegui l'insieme VtsKernelCheckpointTest di VTS
test.