android

Retain returning users with Android’s app backup (part 2)

"It depends" — Google Developer Expert for Android and Identity, geek, and stuff. I have a serious thing for good design.

In the previous post we saw why one should care about backing up and restoring their apps’ data, and one possible way of doing it. In this second and last part, we’ll see an easier way to backup data, and how we can ease migrations/reinstalls even more by preserving login information, too.

Auto Backup

If you think that implementing Key/Value Backup is a bit of a pain, with the whole API key and BackupAgent thing to do, there’s great news for you.

What if I told you that your app can get backups without any effort?

Here’s the thing, on Android 6.0 and later (API 23) the crafty team at Google added the tremendously underrated Auto Backup APIs. Now, calling it an API is a bit exaggerated in my opinion, since there’s barely some XML involved, and nothing else. No API keys, no code, it just works.

What is this wondrous Auto Backup then? Simply put, it means that if you target API 23 or later your app’s private data folder is automatically backed up to the user’s Google Drive, in a separate storage container that can hold up to 25MB of arbitrary data. Best of all, it doesn’t even count against the user’s Drive storage quota.

Auto Backup

Implementing Auto Backup

Now that I have gotten the easy stuff out, you’ll probably be wondering that’s cool, but is there anything I need to do then? Do I need to care about anything?

The answer is — unfortunately for my idyllic vision of zero-effort backup outlined above — yes, there is something you should do. First of all, while Auto Backup is smart enough to avoid backing up cache folders, you likely have something you don’t want to back up in your app’s data folder. Examples would be databases, downloaded assets, install or device-specific IDs, sensitive information about the user, and FCM tokens. For the latter there is a very helpful Lint warning to remind you to add exclusions, so at least that’s covered, but the rest is on you.

Many apps[citation needed] target Android 23+ and have stuff backed up that should not be.

Don’t be one of them! You will save yourself some serious headaches.

How do you do decide what to back up then? The default behaviour on Marshmallow and later for apps that target 23+ is to back everything up, as we mentioned. If you wanted to opt-out of auto-backup (don’t!), you could set android:allowBackup="false" in your app manifest. If you want to be a good dev, on the other hand, you would specify an XML resource for the android:fullBackupContent attribute.

An Auto Backup configuration XML is very simple to write. It consists of a list of inclusions, or of exclusions. If you specify inclusions, everything else is excluded automatically. If you specify exclusions, whatever is not mentioned explicitly is included. Depending on what you store in your app’s data folder, either one might work better for you.

You can also decide that you need more flexibility, in which case you can set android:fullBackupOnly="true" in the app's Manifest and implement a BackupAgent that will be invoked to decide how to behave when restoring. At that point you can easily do things such as excluding a device specific identifier, by just clearing its value in onRestoreFinished() instead of having it in a separate file and excluding the whole file. Be warned though, there are some serious limitations when running a BackupManager — it will run in a so called "Restricted Mode" in which content providers are not started, you don't have your custom Application subclass, and so on. See the documentation for further details.

Auto Backup will by default not restore a backup that was created from a newer version of your app, because it assumes it may not work for you. This might be a problem if your user is migrating to a new device that has an older version of your app preinstalled, because it would mean that nothing is restored. If you are confident you can handle forward compatibility, you can use android:restoreAnyVersion="true" to override the behaviour.

While Auto Backup is super convenient, it is not as flexible as Key/Value Backup unless you implement a BackupManager. For one, it cannot handle migrations or other custom logic. If that’s what you need, you’re better off with Key/Value Backup. Lastly, remember that Auto Backup is only available on Android 6.0 and later, so if your minimum SDK level is below 23, you’re leaving all those users out in the cold.

What to use then?

If there’s one thing you should take out of this blog post, is that there is really no reason why you shouldn’t have backup support in your app. Whether you end up using Key/Value Backup or Auto Backup, is really up to your use case and your app.

This summary should help you make a choice:

Key/Value Backup Auto Backup
`minSdkVersion 8` — Froyo `minSdkVersion 23` — Marshmallow
5MB max 25MB max
Requires API key
(for Android Backup Service)
No API key required
Requires code implementation
(`BackupAgent` subclass)
No code required
(configure via XML)
Supports migrations/custom logic Doesn’t support custom logic

If you are developing a game, you also have the option of using the Google Play Games APIs to persist your game saves across installs using Saved Games.

Remember that enabling Auto Backup will also enable adb backup, which will include or exclude files based on the XML configuration. Also note that, starting with Android 8.0, Key/Value Backup will be used by adb backup too and will enable it implicitly (but it's not the case before Oreo).

One more thing

If you remember, at the beginning I mentioned that users hate to have to log in again to all apps when they migrate to a new device. That’s something Backup and Restore cannot really help with, unfortunately.

But that is not game over! There’s other APIs one can use to keep people signed in and happy, reducing friction and making the UX better. For example, there is Smart Lock For Passwords which I wrote about a couple of years ago. Smart Lock for Passwords — yeah, I know, long name! — allows you to sign users in with a seamless zero-click experience by using auth tokens. If you only rely on username and password, it can still offer a one-tap sign in flow which greatly simplifies things for users anyway.

If you cannot implement Smart Lock for Passwords’ great signin flows, and your users are running Android 8.0 or later, then you can also take advantage of Auto-fill, which again requires almost zero work, except from providing it some hints as to what data type your form accepts.

Lastly, in the "new device" scenario, if you have an account backed by the system AccountManager, then you can use the brand new Account Transfer API from Play Services, that allows you to transfer an account from an old to a new device during the out-of-the-box wizard.


This is it. Now go and make sure that the next time I get a new phone I don’t have to re-configure any apps 💛

Many thanks to the Android Backup & Restore team at Google for their help and guidance in writing these articles. Thanks to Wojtek Kaliciński‏ for pointing out an inaccuracy in the Auto Back up section.

Enjoyed this article? There's more...

We send out a small, valuable newsletter with the best stories, app design & development resources every month.

No spam, no giving your data away, unsubscribe anytime.

About Novoda

We plan, design, and develop the world’s most desirable software products. Our team’s expertise helps brands like Sony, Motorola, Tesco, Channel4, BBC, and News Corp build fully customized Android devices or simply make their mobile experiences the best on the market. Since 2008, our full in-house teams work from London, Liverpool, Berlin, Barcelona, and NYC.

Let’s get in contact