Auto Backup is a nifty feature introduced in Android 6.0 (23) that allows users to have the data from their apps backed up onto their Google Drive accounts.

You can leverage auto backup in your Android app so that your users can more quickly recover their data if they ever switch phones or reinstall your app after having uninstalled it.

Users can store up to 25MB of data which persists across the lifetime of an app being installed on your device.

If the user deletes the app in any way, including via a factory reset of their device, the data for the app will still be available when the user re-downloads the app and the .apk is installed. Auto Backup also works across devices, meaning that when your user gets a new phone, they won’t lose key information from your app.

This sounds like a pretty great feature for your users.
So what kinds of issues might you as a developer need to keep an eye out for?

This post will explore:

• Where you can enable Auto Backup
• Exactly what user data you can expect Auto Backup will save
• Some caveats you must take into consideration as a developer that may influence your workflow
• How you can control what data is actually stored

How to Enable Auto Backup

Users are first prompted to enable Auto Backup when setting up their phone for the first time.
If they need to do so after the fact, they can enable back ups of their data by navigating to Settings -> Backup & Reset, and opting in to having their data stored on their Google Drive.

The device backs up all of the eligible data in the 24 hours since the last Auto Backup was completed, as long as your phone is charged, idle, and connected to a Wi-Fi network.
Unless those constraints are met, the backup will never happen.
This is because during the backup the system shuts down the apps that are getting backed up to make sure they are not writing anything else to the file system.
As such, apps in the foreground won’t actually be getting backed up.

As a developer you can support Auto Backup in your app by toggling it in your manifest.
If you are targeting any version 6.0 and up, it should already be enabled by default with the android:allowBackup="true" in the manifest’s <application> tag.

If you want to override the default behavior of having to shut down the app in order to back it up, you can also include the setting android:backupInForeground="true".

What Is Backed Up

As a developer, you probably store and cache a lot of data on your apps.
So what data am I talking about when I keep saying that your data gets stored in your drive by Auto Backup?

• Shared preferences

• Files in your app’s internal storage: getFilesDir() and getDir(String, Int).

• Files stored in your databases: getDatabasePath(String).

These seem to encompass most of the data that persists in your application, but some notable sources of data that isn’t backed up are data that gets cached for your app by the Android OS and user permissions.

Namely, information in directories accessing via the following APIs:

• getCacheDir()

• getCodeCacheDir()

• getNoBackupFilesDir()

Managing the Auto Backup User Experience

In getting to know a little bit about how Auto Backup works, you might be wondering if it’s an all-or-nothing game: Is a massive, uncontrollable chunk of data sent up by the system?

As it turns out, Android gives you a lot of flexibility on handling what is sent up to our Drives.

Specify What You Want to Include or Exclude from the Backup

As previously stated, Auto Backup backs up almost all of your data, but you can define an .xml file that allows us to specify rules for what you allow to get backed up.

You can do this in just a couple of steps.

• Create an xml file auto_backup_rules.xml in the res/xml directory.

• Specify what you want to include or exclude from the backup using the syntax below:

  • If a type is specified in both the include and the exclude tags, the item specified in the exclude tag takes precedence
  • You can add a new <include> or <exclude> tag for every new resource you want to specify
  • The path tag specifies the path to a resource you want to include or exclude. For example:
    • <exclude domain="database" path="my_db.db"/>

    <full-backup-content>  
        <include  domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" />  
        <exclude  domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" />  
    </full-backup-content>
  

• Include your backup file in your Android Manifest:

    <application ... 
        android:fullBackupContent="@xml/my_backup_rules">
  

• Below is an example where you might decide you actually want to include all of your Shared Preferences, except some user credentials.

    <?xml version="1.0" encoding="utf-8"?>
    <full-backup-content>
        <include domain="sharedpref" path="."/>
        <exclude domain="sharedpref" path="credentials.xml"/>
    </full-backup-content>
  

Disable Auto Backup Completely

If you choose to not support Auto Backup, replace android:allowAutoBackup="true" in your manifest with the following.

<application ...
	android:allowBackup="false"  
	tools:replace="android:allowBackup"

This will make sure that your app data never gets backed up by the system.

This also eliminates the possibility of potentially backing up any data that might be particularly sensitive.

Without a backup, however, you may have to rely on some other way to keep track of the state of your app on a new install, such as recovering data from a REST endpoint that you have access to.

After some time, you should no longer see your app when managing app backups on your Google Drive, because obsolete datasets are deleted after being inactive.

How Does Auto Backup Affect Your Developer Workflow?

As a developer, you probably run fresh builds from Android Studio on your devices and usually have an expectation of the state your app will be in.

If you uninstall the app from your device, you may expect that all the app data from the previous installation is deleted.
This isn’t true while you have Auto Backup enabled if you haven’t specified what should be backed up.

Consider this test case using Shared Preferences: Being a new user coming onto the app for the first time.

You may have an Activity that checks for first-time users by querying for the user information that’s been stored in a variety of ways.

In this case, you decided to store whether or not someone was a first time user in Shared Preferences.

if (!user.firstTime()) {
  //navigate to Home Activity
} else {
  //take user through onboarding process
}

Since, by default, Shared Preferences is backed up, if you had any Shared Preferences data stored during the last Auto Backup, when you uninstall your app and run your build to test the on-boarding flow, you will still always have the stored Shared Preference values.
In this case, that stored value says that this user is not a first time user.

That means that even though you’re running new builds, your app always thinks that an existing user is entering every time and you will never run your on-boarding flow.

Disable Auto Backup in Your Dev Flavor

If you decide that you want to support Auto Backup for your users but you don’t want the unforeseen circumstances it might cause in manual testing and debugging, you may choose to have different manifest files for each flavor that you have in your build.

Your main Android Manifest file would include Auto Backup, along with the rest of your project configuration, and your debug Android Manifest would only have the command that turns Auto Backup off.

Since your manifests are merged when your APK is packaged, this means you don’t have to have two complete versions of your manifest for both product flavors.

What Now?

You now hopefully know a little more about why your data, like the cat you keep feeding, keeps coming back, why it’s happening and how to control it.

Go forth and Auto Backup!