29 Temmuz 2015
Posted by Wojtek Kaliciński, Developer Advocate, Android
Auto Backup for Apps makes seamless app data backup and restore possible with zero lines of application code. This feature will be available on Android devices running the upcoming M release. All you need to do to enable it for your app is update the targetSdkVersion to 23. You can test it now on the M Developer Preview, where we’ve enabled Auto Backup for all apps regardless of targetSdkVersion.
Auto Backup for Apps is provided by Google to both users and developers at no charge. Even better, the backup data stored in Google Drive does not count against the user's quota. Please note that data transferred may still incur charges from the user's cellular / internet provider.
By default, for users that have opted in to backup, all of the data files of an app are automatically copied out to a user’s Drive. That includes databases, shared preferences and other content in the application’s private directory, up to a limit of 25 megabytes per app. Any data residing in the locations denoted by Context.getCacheDir()
, Context.getCodeCacheDir()
and Context.getNoBackupFilesDir()
is excluded from backup. As for files on external storage, only those in Context.getExternalFilesDir()
are backed up.
You can customize what app data is available for backup by creating a backup configuration file in the res/xml
folder and referencing it in your app’s manifest:
<application android:fullBackupContent="@xml/mybackupscheme">
In the configuration file, specify <include/>
or <exclude/>
rules that you need to fine tune the behavior of the default backup agent. Please refer to a detailed explanation of the rules syntax available in the documentation.
You may not want to have certain app data eligible for backup. For such data, please use one of the mechanisms above. For example:
With such a diverse landscape of apps, it’s important that developers consider how to maximise the benefits to the user of automatic backups. The goal is to reduce the friction of setting up a new device, which in most cases means transferring over user preferences and locally saved content.
For example, if you have the user’s account stored in shared preferences such that it can be restored on install, they won’t have to even think about which account they used to sign in with previously - they can submit their password and get going!
If you support a variety of log-ins (Google Sign-In and other providers, username/password), it’s simple to keep track of which log-in method was used previously so the user doesn’t have to.
If you have previously implemented the legacy, key/value backup by subclassing BackupAgent and setting it in your Manifest (android:backupAgent
), you’re just one step away from transitioning to full-data backups. Simply add the android:fullBackupOnly="true"
attribute on <application/>
. This is ignored on pre-M versions of Android, meaning onBackup/onRestore
will still be called, while on M+ devices it lets the system know you wish to use full-data backups while still providing your own BackupAgent.
You can use the same approach even if you’re not using key/value backups, but want to do any custom processing in onCreate(), onFullBackup()
or be notified when a restore operation happens in onRestoreFinished()
. Just remember to call super.onFullBackup()
if you want to retain the system implementation of XML include/exclude rules handling.
The data restore happens as part of the package installation, before the user has a chance to launch your app. Backup runs at most once a day, when your device is charging and connected to Wi-Fi. If your app exceeds the data limit (currently set at 25 MB), no more backups will take place and the last saved snapshot will be used for subsequent restores. Your app’s process is killed after a full backup happens and before a restore if you invoke it manually through the bmgr command (more about that below).
Before you begin testing Auto Backup, make sure you have the latest M Developer Preview on your device or emulator. After you’ve installed your APK, use the adb shell command to access the bmgr tool.
Bmgr is a tool you can use to interact with the Backup Manager:
bmgr run
schedules an immediate backup pass; you need to run this command once after installing your app on the device so that the Backup Manager has a chance to initialize properlybmgr fullbackup <packagename>
starts a full-data backup operation.bmgr restore <packagename>
restores previously backed up dataIf you forget to invoke bmgr run
, you might see errors in Logcat when trying the fullbackup
and restore commands. If you are still having problems, make sure you have Backup enabled and a Google account set up in system Settings -> Backup & reset.
You can find a sample application that shows how to use Auto Backup on our GitHub. The full documentation is available on developer.android.com
Join the Android M Developer Preview Community on Google+ for more information on Android M features and remember to report any bugs you find with Auto Backup in the bug tracker.