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 dell'app per assicurarti che gli utenti possano continuare a utilizzare la tua app 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, in particolare il trasferimento ha un limite di dimensioni dei dati molto più elevato di 2 GB, rispetto ai 25 MB per il backup sul cloud.
Questa guida mostra come testare in modo efficiente sia il backup e il ripristino sul cloud sia il trasferimento D2D durante il ciclo di sviluppo.
Come funzionano i test di backup
Questa sezione descrive i vari componenti del framework di backup di Android e come 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 viene astratta, 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 dei dati durante il backup e il recupero del cloud. Per scopi di test, lo stesso dispositivo può essere utilizzato per il backup e il ripristino nel cloud.
Il seguente diagramma illustra il flusso dei dati durante un trasferimento D2D:
A differenza dei test per il backup e il ripristino sul cloud, i test D2D richiedono un dispositivo di origine e un dispositivo di destinazione da e in cui copiare.
Il servizio di gestione backup è un servizio di sistema Android che orchestra 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 recuperare i dati di backup, poi li inoltra al trasporto di backup, che li archivia sul 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 sulla tua app per recuperare 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 Android può avere zero o più mezzi di trasporto di riserva, ma solo uno di questi può essere contrassegnato come attivo. I metodi di backup disponibili variano da dispositivo a dispositivo, a causa delle personalizzazioni dei produttori di dispositivi e dei fornitori di servizi, ma la maggior parte dei dispositivi compatibili con Google Play viene fornita con i seguenti metodi:
- Trasporto GMS: il trasporto di backup sul cloud attivo sulla maggior parte dei dispositivi, parte di Google Mobile Services. Questo trasporto memorizza i dati in Android Backup Service.
- D2D Transport: questo trasporto viene utilizzato nella migrazione D2D per trasferire 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 recupero.logcat: per visualizzare l'output delle operazioni di backup e recupero.
Testare il backup sul cloud
Il backup e il ripristino sul cloud possono essere eseguiti utilizzando un singolo dispositivo seguendo i passaggi indicati in questa sezione.
Preparare il dispositivo o l'emulatore per i backup sul cloud
Prepara il dispositivo o l'emulatore per i test di backup seguendo il seguente elenco di controllo:
- 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 delle 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 di 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, attiva un backup sul cloud, 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 localmente, 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 di 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, con tutti i dati conservati.
Non vuoi che gli utenti debbano accedere e che tutte le loro impostazioni, i progressi e i dati dell'app rimangano invariati. Se i risultati del test non soddisfano questi criteri, assicurati di aver configurato correttamente i backup, senza omettere dati chiave e di gestire anche la ricreazione di eventuali dati memorizzati nella cache esclusi dal backup. Ripeti i passaggi da 1 a 3 per ogni iterazione del test.
Testare il trasferimento P2P
Il modo più completo per testare il trasferimento P2P è trasferire l'intero contenuto dello smartphone su un nuovo dispositivo con i dati di fabbrica ripristinati e verificare che funzioni correttamente. Tuttavia, questa operazione può essere scomoda e richiedere molto tempo se devi ripeterla più volte. Questi passaggi mostrano come simulare un trasferimento con un singolo dispositivo senza eseguire ripetutamente un ripristino dei dati di fabbrica sul dispositivo.
Prepara il dispositivo per i test D2D
Per testare il trasferimento P2P su un singolo dispositivo, preparalo come segue:
- Sul tuo dispositivo deve essere installato Android 12 (livello API 31) o versioni successive.
- Per testare la versione più recente di D2D, scegli come target Android 12 (livello API 31) o versioni successive nella tua app.
- Crea lo script
test_d2d.shseguente 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 di test
- Installa l'app che vuoi testare sul dispositivo.
- Apri l'app, accedi e modifica le impostazioni dell'app.
- Esegui lo script sul 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, mantenendo tutti i dati.
Non vuoi che gli utenti debbano accedere e tutte le loro impostazioni, i progressi e i dati dell'app devono essere visualizzati come prima dell'esecuzione dello script. Se i risultati del test non soddisfano questi criteri, assicurati di aver configurato correttamente il trasferimento, senza omettere elementi chiave dei dati e di gestire anche la ricreazione di eventuali dati memorizzati nella cache esclusi 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 per i trasporti 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 i dati nella cache solo nella directory della cache dell'app. La directory della cache non è inclusa nei backup.
Backup completo non possibile
Il seguente messaggio in Logcat indica che l'operazione di backup completa non è riuscita perché sul dispositivo non è ancora stata eseguita alcuna operazione di backup della coppia chiave-valore:
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
Avvia un backup delle coppie chiave-valore con il comando bmgr run e riprova.
Timeout in attesa dell'agente
Il seguente messaggio in Logcat indica che l'avvio dell'app richiede più di 10 secondi 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 l'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 il gestore del backup con il comando adb shell bmgr run, quindi riprova a eseguire il backup.
Metodi dell'app non chiamati
Poiché il backup automatico avvia l'app con una classe di base di
Application, i metodi di configurazione dell'app
potrebbero non essere chiamati. Anche il backup automatico non avvia le attività della tua app, pertanto potresti visualizzare errori se la tua app esegue la configurazione in un'attività. Per saperne di più, consulta Implementare BackupAgent.
Al contrario, il backup delle coppie chiave/valore avvia l'app con qualsiasi Application
sottoclasse dichiarata nel file manifest dell'app.
Nessun dato di cui eseguire il backup
I seguenti messaggi in Logcat indicano che la tua 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, probabilmente non hai aggiunto dati o file al backup.