Questa pagina mostra come testare i backup sul cloud e il processo di trasferimento da dispositivo a dispositivo (D2D) per la tua app. È importante testare entrambi con ogni release principale della tua app per garantire che gli utenti possano continuare a utilizzarla su un nuovo dispositivo. Sebbene il backup e il trasferimento siano simili, esistono differenze importanti tra i due in Android 12 (livello API 31) e versioni successive. La più importante è che il trasferimento ha un limite di dimensioni dei dati molto più elevato, pari a 2 GB, rispetto ai 25 MB del backup sul cloud.
Questa guida mostra come testare in modo efficiente il backup e il ripristino sul cloud e il trasferimento D2D durante tutto il ciclo di sviluppo.
Come funziona il test dei backup
Questa sezione descrive i vari elementi del framework di backup di Android e il modo in cui interagiscono con le app che supportano il backup automatico e il backup delle coppie chiave-valore. Durante la fase di sviluppo dell'app, la maggior parte del funzionamento interno del framework è astratto, quindi non è necessario conoscere queste informazioni. Tuttavia, durante la fase di test, la comprensione di questi concetti diventa più importante.
Il seguente diagramma illustra il flusso di dati durante il backup e il ripristino nel cloud. Per scopi di test, è possibile utilizzare lo stesso dispositivo per il backup e il ripristino nel cloud.
Il seguente diagramma illustra il flusso di dati durante un trasferimento D2D:
A differenza dei test di backup e ripristino dal cloud, i test D2D richiedono un dispositivo di origine e un dispositivo di destinazione da cui e su cui copiare.
Il servizio di gestione dei backup è un servizio di sistema Android che coordina e avvia le operazioni di backup e ripristino. Il servizio è accessibile tramite l'API
Backup Manager
.
Durante un'operazione di backup, il servizio esegue query sull'app per i dati di backup, quindi li passa al trasporto di backup, che poi li archivia nel cloud. Durante un'operazione di ripristino, il servizio Backup Manager recupera i dati di backup dal trasporto di backup e li ripristina sul dispositivo. Per un trasferimento D2D, il servizio Backup Manager esegue query nella tua app per i dati di backup e li passa direttamente al servizio Backup Manager sul nuovo dispositivo, che li carica nella tua app.
I trasporti di backup sono componenti Android responsabili dell'archiviazione e del recupero dei dati delle app. Un dispositivo basato su Android può avere zero o più trasporti di backup, ma solo uno di questi può essere contrassegnato come attivo. I meccanismi di backup disponibili variano da dispositivo a dispositivo a causa delle personalizzazioni di produttori di dispositivi e fornitori di servizi, ma la maggior parte dei dispositivi compatibili con Google Play viene fornita con i seguenti meccanismi:
- GMS Transport: il trasporto di backup sul cloud attivo sulla maggior parte dei dispositivi, parte di Google Mobile Services. Questo trasporto memorizza i dati nel servizio di backup Android.
- Trasporto D2D:questo trasporto viene utilizzato nella migrazione D2D per trasferire i dati direttamente da un dispositivo all'altro.
Strumenti
Per testare le operazioni di backup e ripristino, devi conoscere un po' i seguenti strumenti.
adb
: per eseguire comandi sul dispositivo o sull'emulatore.bmgr
: per eseguire varie operazioni di backup e ripristino.logcat
: per visualizzare l'output delle operazioni di backup e ripristino.
Testare il backup nel cloud
Il backup e il ripristino sul cloud possono essere eseguiti utilizzando un singolo dispositivo seguendo i passaggi descritti in questa sezione.
Preparare il dispositivo o l'emulatore per i backup sul cloud
Prepara il dispositivo o l'emulatore per il test del backup seguendo l'elenco di controllo seguente:
- Per il backup automatico, verifica di utilizzare un dispositivo o un emulatore con Android 6.0 (livello API 23) o versioni successive.
- Per il backup di coppie chiave-valore, verifica di utilizzare un dispositivo o un emulatore con Android 2.2 (livello API 8) o versioni successive.
- Per testare il backup sul cloud, devi disporre dell'accesso a internet.
- Accedi al dispositivo con un Account Google e impostalo come account di backup in Impostazioni -> Google -> Backup.
Per testare il backup sul cloud, attivalo, quindi disinstalla e reinstalla l'app. Per rendere ripetibili questi passaggi, puoi utilizzare il seguente script, test_cloud_backup.sh
, che esegue il backup dell'app, scarica l'APK in locale, lo disinstalla e lo reinstalla:
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"
# Initialize and create a backup
adb shell bmgr enable true
adb shell bmgr transport com.android.localtransport/.LocalTransport | grep -q "Selected transport" || (echo "Error: error selecting local transport"; exit 1)
adb shell settings put secure backup_local_transport_parameters 'is_encrypted=true'
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)
# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
(( ++apk_number ))
apk_path=${apk_line:8:1000}
adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks
# Clean up
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks
echo "Done"
Passaggi del test
- Apri l'app, accedi e modifica tutte le impostazioni.
- Esegui lo script, passando il nome del pacchetto, ad esempio
test_cloud_backup.sh com.example.myapp
- Riapri l'app e verifica che funzioni correttamente e che tutti i dati siano stati conservati.
Non vuoi che i tuoi utenti debbano accedere e tutte le loro impostazioni, i progressi e i dati delle app devono rimanere invariati. Se i risultati del test non soddisfano questi criteri, assicurati di aver configurato i backup correttamente, senza omettere dati chiave, e di gestire anche la ricreazione di tutti i dati memorizzati nella cache che hai escluso dal backup. Ripeti i passaggi 1-3 per ogni iterazione del test.
Testare il trasferimento D2D
Il modo più completo per testare il trasferimento D2D è trasferire l'intero contenuto dello smartphone su un nuovo dispositivo ripristinato ai dati di fabbrica e verificare che funzioni correttamente. Tuttavia, questa operazione può essere scomoda e richiedere molto tempo se devi ripetere la procedura più volte. Questi passaggi mostrano come simulare un trasferimento con un singolo dispositivo senza eseguire ripetutamente un ripristino dei dati di fabbrica sul dispositivo.
Preparare il dispositivo per i test D2D
Per testare il trasferimento D2D su un singolo dispositivo, preparalo nel seguente modo:
- Sul tuo dispositivo deve essere installato Android 12 (livello API 31) o versioni successive.
- Per testare l'ultima versione di D2D, scegli come target Android 12 (livello API 31) o versioni successive nella tua app.
- Crea il seguente script,
test_d2d.sh
, per supportare la ripetizione del test:
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"
# Initialize and create a backup
adb shell bmgr enable true
adb shell settings put secure backup_enable_d2d_test_mode 1
adb shell bmgr transport com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr list transports | grep -q -F " * com.google.android.gms/.backup.migrate.service.D2dTransport" || (echo "Failed to select and initialize backup transport"; exit 1)
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)
# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
(( ++apk_number ))
apk_path=${apk_line:8:1000}
adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks
# Clean up
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell settings put secure backup_enable_d2d_test_mode 0
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks
echo "Done"
Passaggi del test
- Installa l'app che vuoi testare sul dispositivo.
- Apri l'app, accedi e modifica le impostazioni.
- Esegui lo script sul tuo dispositivo, passando il nome del pacchetto, ad esempio
test_d2d.sh com.example.myapp
. - Al termine dello script, apri l'app sul dispositivo e verifica che funzioni correttamente e che tutti i dati siano stati conservati.
Non vuoi che i tuoi utenti debbano accedere e tutte le loro impostazioni, i progressi e i dati delle app devono apparire come prima dell'esecuzione dello script. Se i risultati del test non soddisfano questi criteri, assicurati di aver configurato il trasferimento correttamente, senza omettere i dati chiave e di gestire anche la ricreazione di tutti i dati memorizzati nella cache che hai escluso dal trasferimento. Ripeti i passaggi 2-4 per ogni iterazione del test.
Risolvere i problemi di backup e ripristino
Questa sezione ti aiuta a risolvere alcuni problemi comuni.
Quota di trasporto superata
I seguenti messaggi in Logcat indicano che la tua app ha superato la quota di trasporto:
I/PFTBT: Transport rejected backup of <PACKAGE>, skipping
--- or ---
I/PFTBT: Transport quota exceeded for package: <PACKAGE>
Riduci la quantità di dati di backup e riprova. Ad esempio, verifica di memorizzare nella cache i dati solo nella directory della cache della tua app. La directory della cache non è inclusa nei backup.
Backup completo non possibile
Il seguente messaggio in Logcat indica che l'operazione di backup completo non è riuscita perché sul dispositivo non è ancora stata eseguita alcuna operazione di backup di coppie chiave-valore:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Attiva un backup delle coppie chiave-valore con il comando bmgr run
, quindi riprova.
Timeout in attesa dell'agente
Il seguente messaggio in Logcat indica che l'app impiega più di 10 secondi per l'avvio per il backup:
12-05 18:59:02.033 1910 2251 D BackupManagerService:
awaiting agent for ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117 1910 2251 W BackupManagerService:
Timeout waiting for agent ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117 1910 2251 W BackupManagerService:
Can't find backup agent for com.your.app.package
Nota la differenza di timestamp nell'output del log. Questo errore si verifica in genere quando la tua app utilizza una configurazione multidex senza ProGuard.
Account di backup non inizializzato
I seguenti messaggi in Logcat indicano che il backup è stato interrotto perché il set di dati di backup non è stato inizializzato:
01-31 14:32:45.698 17280 17292 I Backup: [GmsBackupTransport] Try to backup for
an uninitialized backup account.
01-31 14:32:45.699 1043 18255 W PFTBT: Transport failed; aborting backup: -1001
01-31 14:32:45.699 1043 18255 I PFTBT: Full backup completed with status: -1000
Esegui
Backup Manager con il comando adb shell bmgr run
, quindi prova a
eseguire di nuovo il backup.
Metodi dell'app non chiamati
Poiché il backup automatico avvia l'app con una classe base di
Application
, i metodi di configurazione dell'app
potrebbero non essere chiamati. Il backup automatico non avvia nessuna delle attività della tua app,
quindi potresti visualizzare errori se la tua app esegue la configurazione in un'attività. Per saperne
di più, leggi
Implementare BackupAgent.
Al contrario, il backup delle coppie chiave-valore avvia l'app con qualsiasi sottoclasse Application
dichiarata nel file manifest dell'app.
Nessun dato di cui eseguire il backup
I seguenti messaggi in Logcat indicano che l'app non ha dati di cui eseguire il backup:
I Backup : [FullBackupSession] Package com.your.app.package doesn't have any backup data.
--- or ---
I Backup : [D2dTransport] Package com.your.app.package doesn't have any backup data.
Se hai implementato il tuo
BackupAgent
, è probabile che tu non abbia aggiunto dati o file al backup.