Auto Backup for Apps semplificato
10 settembre 2015
Auto Backup for Apps rende possibile il backup e il ripristino costante dei dati delle app senza scrivere alcuna riga di codice applicativo. Questa funzione sarà disponibile sui dispositivi Android dotati della prossima versione M. Per abilitarla gli sviluppatori dovranno limitarsi all’aggiornamento alla versione 23 del targetSdkVersion delle app. È possibile provare questa funzione già ora su M Developer Preview, dove abbiamo abilitato Auto Backup per tutte le app indipendentemente dalla versione di targetSdkVersion.
L’offerta di Auto Backup for Apps da parte di Google non comporta alcun costo né per gli utenti né per gli sviluppatori. Un altro vantaggio è che i dati del backup archiviati in Google Drive non incidono sulla quota dell’utente. Ricordiamo tuttavia che il trasferimento dei dati potrebbe comportare dei costi applicati dal gestore della rete cellulare/provider Internet dell’utente.
Per impostazione predefinita, nel caso degli utenti che hanno dato il consenso esplicito al backup, tutti i file di dati di un’app vengono automaticamente copiati su un Drive dell’utente. Ciò comprende database, preferenze condivise e altri contenuti della directory privata dell’applicazione, fino a un limite di 25 MB per app. Eventuali dati presenti nei percorsi e denominati Context.getCacheDir(), Context.getCodeCacheDir() e Context.getNoBackupFilesDir() vengono esclusi dal backup. Per quanto riguarda i dati presenti sui dispositivi di archiviazione esterne, viene eseguito il backup dei soli dati memorizzati in Context.getExternalFilesDir().
Gli sviluppatori possono personalizzare il tipo di dati disponibili per il backup creando un file di configurazione del backup nella cartella res/xml e indicandolo nel manifesto dell’app:
Nel file di configurazione, specificare le regole <include> o <exclude> necessarie per ottimizzare il comportamento dell’agente di backup predefinito. La spiegazione dettagliata della sintassi delle regole è reperibile nella documentazione.
Sarebbe preferibile non inserire nel backup determinati dati dell’app e in tal caso si può ricorrere a uno dei meccanismi indicati sopra, ad esempio:
Ad esempio, se l’account utente è archiviato nelle preferenze condivise in modo da poter essere ripristinato all’installazione, non occorre pensare da quale account sia stato utilizzato per eseguire precedentemente l’accesso: è sufficiente inserire la propria password e andare avanti!
Se gli sviluppatori supportano vari metodi di accesso (Google Sign-In e altri provider, nome utente/password), è semplice tener traccia del metodo di accesso precedentemente utilizzato in modo che non debba farlo l’utente.
Se lo sviluppatore ha precedentemente implementato il backup di legacy per chiave/valore creando sottoclassi BackupAgent e impostandole nel Manifesto (android:backupAgent), manca veramente poco per la transizione ai backup di tutti i dati. È sufficiente aggiungere l’attributo android:fullBackupOnly="true" in <application>. Questo viene ignorato nelle versioni di Android precedenti alla M, per cui onBackup/onRestore viene comunque richiamato, mentre sui dispositivi M+ consente al sistema di sapere che lo sviluppatore desidera utilizzare i backup di tutti i dati fornendo contemporaneamente il proprio BackupAgent.
Lo sviluppatore può utilizzare lo stesso approccio anche se non utilizza i backup per chiave/valore, ma preferisce eseguire un’elaborazione personalizzata in onCreate(), onFullBackup() o essere avvisato quando viene eseguita un’operazione di ripristino in onRestoreFinished(). Basta ricordare di richiamare super.onFullBackup() se si preferisce mantenere l’implementazione da parte del sistema della gestione delle regole di inclusione/esclusione XML.
Il ripristino dei dati viene eseguito in quanto parte dell’installazione del pacchetto, prima che l’utente abbia la possibilità di avviare l’app. Il backup viene eseguito al massimo una volta al giorno, quando il dispositivo è in carica e connesso a una rete Wi-Fi. Se l’app supera il limite di dati, attualmente impostato su 25 MB, non vengono eseguiti altri backup e per i ripristini successivi viene utilizzata l’ultima snapshot salvata. Il processo dell’app viene terminato dopo l’esecuzione di un backup completo e prima di un ripristino, se questo richiamato manualmente tramite il comando bmgr, approfondito di seguito.
Prima di iniziare a provare Auto Backup, occorre accertarsi di disporre della versione più recente di M Developer Preview sul proprio dispositivo o emulatore. Dopo aver installato l’APK, utilizzare il comando shell adb per accedere allo strumento bmgr.
Bmgr è uno strumento utilizzabile per l’interazione con Backup Manager:
Nel nostro GitHub è disponibile un esempio di applicazione che mostra come utilizzare Auto Backup. La documentazione completa è reperibile su developer.android.com
Per ulteriori informazioni sulle funzioni di Android M è possibile partecipare alla Android M Developer Preview Community su Google+. Si prega di segnalare eventuali bug riscontrati in Auto Backup nel bug tracker.
L’offerta di Auto Backup for Apps da parte di Google non comporta alcun costo né per gli utenti né per gli sviluppatori. Un altro vantaggio è che i dati del backup archiviati in Google Drive non incidono sulla quota dell’utente. Ricordiamo tuttavia che il trasferimento dei dati potrebbe comportare dei costi applicati dal gestore della rete cellulare/provider Internet dell’utente.
In che cosa consiste Auto-Backup for Apps?
Per impostazione predefinita, nel caso degli utenti che hanno dato il consenso esplicito al backup, tutti i file di dati di un’app vengono automaticamente copiati su un Drive dell’utente. Ciò comprende database, preferenze condivise e altri contenuti della directory privata dell’applicazione, fino a un limite di 25 MB per app. Eventuali dati presenti nei percorsi e denominati Context.getCacheDir(), Context.getCodeCacheDir() e Context.getNoBackupFilesDir() vengono esclusi dal backup. Per quanto riguarda i dati presenti sui dispositivi di archiviazione esterne, viene eseguito il backup dei soli dati memorizzati in Context.getExternalFilesDir().
Come controllare il contenuto del backup
Gli sviluppatori possono personalizzare il tipo di dati disponibili per il backup creando un file di configurazione del backup nella cartella res/xml e indicandolo nel manifesto dell’app:
<application android:fullBackupContent="@xml/mybackupscheme">
Nel file di configurazione, specificare le regole <include> o <exclude> necessarie per ottimizzare il comportamento dell’agente di backup predefinito. La spiegazione dettagliata della sintassi delle regole è reperibile nella documentazione.
Che cosa escludere dal backup
Sarebbe preferibile non inserire nel backup determinati dati dell’app e in tal caso si può ricorrere a uno dei meccanismi indicati sopra, ad esempio:
- È necessario escludere qualsiasi identificatore specifico del dispositivo, sia trasmesso da un server che generato sul dispositivo. Questa categoria include il token di registrazione Google Cloud Messaging (GCM) che, quando ripristinato su un altro dispositivo, può impedire all’app installata su tale dispositivo di ricevere messaggi GCM.
- È consigliabile escludere le credenziali dell’account o altre informazioni riservate, ad esempio chiedendo all’utente di rieseguire l’autenticazione la prima volta che avvia un’app ripristinata anziché consentire l’archiviazione di tali dati nel backup.
Ad esempio, se l’account utente è archiviato nelle preferenze condivise in modo da poter essere ripristinato all’installazione, non occorre pensare da quale account sia stato utilizzato per eseguire precedentemente l’accesso: è sufficiente inserire la propria password e andare avanti!
Se gli sviluppatori supportano vari metodi di accesso (Google Sign-In e altri provider, nome utente/password), è semplice tener traccia del metodo di accesso precedentemente utilizzato in modo che non debba farlo l’utente.
Transizione dai backup per chiave/valore
Se lo sviluppatore ha precedentemente implementato il backup di legacy per chiave/valore creando sottoclassi BackupAgent e impostandole nel Manifesto (android:backupAgent), manca veramente poco per la transizione ai backup di tutti i dati. È sufficiente aggiungere l’attributo android:fullBackupOnly="true" in <application>. Questo viene ignorato nelle versioni di Android precedenti alla M, per cui onBackup/onRestore viene comunque richiamato, mentre sui dispositivi M+ consente al sistema di sapere che lo sviluppatore desidera utilizzare i backup di tutti i dati fornendo contemporaneamente il proprio BackupAgent.
Lo sviluppatore può utilizzare lo stesso approccio anche se non utilizza i backup per chiave/valore, ma preferisce eseguire un’elaborazione personalizzata in onCreate(), onFullBackup() o essere avvisato quando viene eseguita un’operazione di ripristino in onRestoreFinished(). Basta ricordare di richiamare super.onFullBackup() se si preferisce mantenere l’implementazione da parte del sistema della gestione delle regole di inclusione/esclusione XML.
Qual è il ciclo di vita del backup/ripristino?
Il ripristino dei dati viene eseguito in quanto parte dell’installazione del pacchetto, prima che l’utente abbia la possibilità di avviare l’app. Il backup viene eseguito al massimo una volta al giorno, quando il dispositivo è in carica e connesso a una rete Wi-Fi. Se l’app supera il limite di dati, attualmente impostato su 25 MB, non vengono eseguiti altri backup e per i ripristini successivi viene utilizzata l’ultima snapshot salvata. Il processo dell’app viene terminato dopo l’esecuzione di un backup completo e prima di un ripristino, se questo richiamato manualmente tramite il comando bmgr, approfondito di seguito.
Per testare subito le app
Prima di iniziare a provare Auto Backup, occorre accertarsi di disporre della versione più recente di M Developer Preview sul proprio dispositivo o emulatore. Dopo aver installato l’APK, utilizzare il comando shell adb per accedere allo strumento bmgr.
Bmgr è uno strumento utilizzabile per l’interazione con Backup Manager:
- bmgr run pianifica un’operazione di backup immediata; questo comando deve essere eseguito dopo aver installato l’app sul dispositivo in modo tale che Backup Manager abbia la possibilità di eseguire correttamente l’inizializzazione.
- bmgr fullbackup <packagename> avvia un’operazione di backup completo.
- bmgr restore <packagename> ripristina i dati precedentemente sottoposti a backup
Se lo sviluppatore dimentica di richiamare bmgr run, potrebbe riscontrare errori in Logcat quando prova i comandi fullbackup e di ripristino. Se i problemi persistono, accertarsi di aver abilitato Backup e di aver impostato un account Google in Impostazioni -> Backup e ripristino del sistema.
Approfondimento
Nel nostro GitHub è disponibile un esempio di applicazione che mostra come utilizzare Auto Backup. La documentazione completa è reperibile su developer.android.com
Per ulteriori informazioni sulle funzioni di Android M è possibile partecipare alla Android M Developer Preview Community su Google+. Si prega di segnalare eventuali bug riscontrati in Auto Backup nel bug tracker.
