[MUSIC PLAYING]
MARTIN MILLMORE: Hi.
My name is Martin Millmore.
My pronouns are he/him.
I'm here today with my colleague Ruslan Tkhakokhov
to talk to you about how to ensure you retain users
with Android Backup and Restore.
First of all, let's go on a user journey.
Meet Sally.
Sally has a great job as a food microbiologist.
It keeps her really busy.
Her job is pretty exhausting, though,
and she loves nothing more than coming home
from a hard day at the lab and playing
casual games on her phone.
Sally loves her phone.
She bought it in 2017 to watch "The Good Place"
on her commute.
Although these days, she mainly plays games on it.
Unfortunately, though, it's just not got the power it once did.
Sally goes to her local independent phone store,
where she's recommended a fantastic new Android
phone by the highly knowledgeable shop
assistant, Hakeem.
When Sally gets home, she can't wait to setup her new phone,
and she's delighted at how easily she can transfer
all of her apps, photos, messages, and settings
from her old phone.
As soon as the transfer has finished,
she wants to see how some of her favorite games
on this gorgeous new phone work.
Her favorite casual game is Super Soccer Goalie Catch 2.
It's taken her months to get to level 123,
but she can't wait to blast through that on her new phone.
Unfortunately, when she opens it,
she finds that all of her progress is gone.
It's going to take her days and days of playing
to get back to where she was.
Disheartened, Sally decides it's not
worth the time to get back where she was.
She uninstalls the old game and installs archrival app Soccer
Goalie 3D.
Undeterred, Sally opens up her protein shake tracker app.
Sally loves protein shakes, and she
likes to rate them and track how much nutrition she's getting.
When she opens the app, Sally gets prompted to log in,
but Sally doesn't remember her login
and she hasn't got a password manager.
She's pretty sure she's changed her email address since then,
too.
She's kind of stuck.
I'm pretty sure you've guessed what's coming.
Sally uninstalls it and decides to try out the great new app
ProteinMate that has been heavily advertised
on her Instagram feeds.
Sally loves her new phone and she
loves most of the apps on it, but she's
frustrated that a few of them didn't transfer their data.
Now let's meet another user.
Here's Javier.
Javier uses his iPhone to message his grandchildren.
He's got a lot of pictures of them on there
and it means everything to him.
Javier's an early adopter and he regularly gets a new phone.
He really likes the look of the new foldable Android phones.
It'll give him more screen space to message and play games,
as well as bragging rights with his friends.
Javier transfers all of his apps,
and contacts, and photos from his iPhone to his new Android
foldable.
After he transfers, he goes straight to his messaging app
to look at the photos of his grandchildren
on the big screen.
He's devastated to find out that his messaging app hasn't
brought his messages across from his iPhone.
He's thinking, perhaps it's time to use a different messaging
app.
Now you might think all of this is scaremongering.
But at Google, we've done a lot of research
into the switching experience, and users are not happy
when this happens.
Here's a quote from an article in "The Guardian" newspaper
this week, which echoes our research.
The user left his phone on the roof of the car,
and when his game progress was not
transferred onto the new device, he uninstalled the game.
We hear this over and over in our research.
Here's a summary of our research findings.
Users are surprised that the app doesn't pick up where
it left off on the old phone.
They're upset at the loss of their personal data.
And they don't blame Android or the OEM, they blame the app
or they blame themselves.
In the setup experience, only 30% of devices
are setup as new.
The vast majority of users want their data
to be coming across from their old phone.
When that doesn't happen, it upsets
users, which leads to lower ratings in the Play Store
and to a direct loss of users.
Don't be like this developer, wondering
where his users are going.
You fight hard to get those users in the first place.
Make sure you keep them when they get a new device.
Fortunately, Android has made it incredibly simple
to transfer your application's data to a new device
and even back it up to the cloud for free.
Help grow your user base, and ultimately your revenue,
with a high-quality app that users trust.
Here's Ruslan to explain how to do that.
RUSLAN TKHAKOKHOV: Thank you, Martin.
My name's Ruslan, and I'm an engineer
on Android Backup and Restore.
And I'm here to show you how to leverage
Backup and Restore to give your users the perfect experience
when they switch to a new device.
We'll look at two cases, iOS to Android and Android
to Android switches.
So let's get started.
If the user is coming from an iOS phone,
they can connect it to their new Android device using a cable
and go through a Device-To-Device migration,
or D2D for short.
During D2D, we'll look at what apps
they have on their iOS device.
We'll try to find their Android equivalents in the Play Store
and install them automatically.
For some apps, we can also transfer the app data.
Please reach out to us at the email address on the slide
if you're interested in data transfer between the iOS
and Android versions of your app to better retain users when
they're switching platforms.
For Android to Android switches, the users
can also connect their devices by cable.
We'll redownload all their apps, as well as transfer up
to 2 gigabytes of data for each participating
app in Backup and Restore.
If the user doesn't have their old device at the moment,
they can restore data from a cloud backup
that has been created earlier.
That is because app data on Android devices
is regularly backed up to the cloud.
These app data backups are end-to-end encrypted
on devices running Android Pi and later,
provided that the user has set a PIN, pattern, or password
to unlock their screen.
In this mode, we'll back up up to 25 megabytes
of data for each participating app on the device.
On the previous slides, I said that we transferred data
for apps that participate in Backup and Restore.
What does that mean?
Backup and Restore is already enabled
for all apps on Android M and later,
unless you explicitly opt-out.
You can control and customize its behavior very easily,
and we'll look at how to do that later in the talk.
But at this point, you might be thinking,
I already use some kind of solution
to keep my users' data synced to the cloud,
like Firebase or a custom backend.
Why do I need Backup and Restore?
First of all, to take advantage of the in-app cloud sync,
the user needs to sign into your app,
whereas the data handled by Backup and Restore
is available even before that because we've already
identified the user through their Google account.
Second and maybe even more important
point is there is lots of data that is unique to the device
and not to the account within the app.
And such data, apps don't usually sync to the cloud.
For example, let's say that you have an onboarding
tutorial that you show once per device and not per account.
Or let's say that you have a settings screen within your app
where the user can customize how they
want the app to look and behave on this specific device.
I could go on and on here, but the point
is your users would really love for all these preferences
to be already set correctly when they first launch
the app on their new phone.
With that said, let's look at how
you can configure Backup and Restore for your Android app.
By default, all apps participate in Auto Backup.
This means that most of your app data
will be included into both cloud backup and D2D transfers.
We'll only exclude the cache directory
and the special No Backup folder,
where you can put stuff that you don't want
to be backed up or transferred.
And while Auto Backup is the approach we recommend,
there is also something called Key/Value backup, where
you need to, at runtime, provide a set of key/value pairs
that you want to be backed up.
And we'll look at that option, as well, later in the talk.
But for now, assuming that you are happy with Auto Backup.
Let's see what kind of customizations
you could make to the default behavior.
You can set rules on what files or directories should
be included into the cloud backup or device transfer.
You can also say that you want cloud backups
only if the device supports end-to-end encryption.
To do all of that, you just need to create an XML file
with your configuration.
As you can see on the slide, the config
contains two sections, one for cloud-backups
and one for device-transfers.
Inside each section, you can put rules
on what files or directories to exclude or include.
In our example, we excluded our Firebase push token
from the cloud backup because it won't work on any other device.
It makes sense to exclude data that
can't be reused outside of this particular device.
We also excluded a large downloadable file.
If data can easily be redownloaded from somewhere,
there is no point in including it into the cloud backup.
Also, we've set the disableIfNoEncry
ptionCapabilities flag to true for cloud backups.
This means that data will not be backed up to the cloud
unless end-to-end encryption is available.
Finally, we defined a more relaxed configuration
for device-to-device transfers, as there is no cloud storage
involved in the process.
Once your config is ready, you need
to point to it in the AndroidManifest
file using the dataExtractionRules attribute.
Also, don't forget to target Android 12,
as that's where the attribute was introduced.
You can find more detailed instructions
on configuring Auto Backup.
By following the link on this slide.
Now let's briefly look at the alternative I mentioned
earlier, which is Key/Value backup.
Here, you need to extend the class called BackupAgent
and implement the behavior you'd like onBackup and onRestore.
As part of the backup event, you can check the same conditions,
like presence of end-to-end encryption
and whether the operation currently happening
is a cloud backup or a device transfer,
to better determine which key/value pairs should
be included.
And again, when your agent is ready,
don't forget to point to it in the AndroidManifest.
If you're interested in Key/Value backups,
you can follow the link on this slide for a step-by-step guide
on implementing them.
Now there is a specific category of app data
I'd like to talk a bit more about.
One of the biggest obstacles that users
face when they launch an app on their new device
is signing into it again.
Chances are, they don't even remember their login
and password.
Wouldn't it be great if your app could automatically
recognize the user, allowing them
to pick up right where they left off on their old device?
To achieve this, you can use BlockStore,
which allows you to transfer to the new device whatever
login credentials you need to identify the user as part
of a device-to-device migration.
BlockStore is independent of things
like Auto Backup and Key/Value backup,
and you can use it to transfer your auth token,
even if you don't use Backup and Restore for anything else.
Let's take a quick look at how it works.
Whenever the user signs into your app
and you generate an auth token or any other login credentials,
simply save them into BlockStore, which will encrypt
and securely store it.
When your app is launched on the new device following
a device-to-device migration, you
can request the credentials you saved earlier from BlockStore
and sign the user in without asking them
for login and password.
You can learn more about BlockStore
by following the link on the slide.
Once you've configured everything as you like,
whether it's Auto Backup or Key/Value backup,
it's very important to do some testing
to make sure you're getting the behavior you
want when your app is launched for the first time
after a restore.
Testing is very easy with a special workflow that
lets you emulate both cloud and device-to-device transfers
for your app specifically, using just a single device
or emulator.
You can follow detailed instructions
by following the link on the slide.
Last but not least, it's very important
to keep your configuration up-to-date.
As your app evolves and new features get added,
make sure those are covered by Backup and Restore.
If you're using Auto Backup, you likely
don't need to do anything.
All the new data is included by default.
If you're using Key/Value, update your BackupAgent
to cover any relevant info.
Finally, I'd like to highlight some important changes
that we made recently.
These apply to apps running on and targeting Android 12.
First of all, we've heard from app developers
that they were concerned about adb backup
making their app data easily extractable.
To address this, we've turned off adb backup for all apps.
So having Backup and Restore enabled no longer
means your app is exposed to adb backup.
You can still use it, though, for testing and development
purposes, if you need.
Secondly, we've introduced the dataExtractionRules config,
which I demonstrated in the earlier slides,
as the new way to control AutoBackup.
The old way, which is the allowBackup
flag and the fullBackupContent config, are being phased out.
We recommend that you use dataExtractionRules
for Android 12 and beyond, while also maintaining
fullBackupContent config for earlier OS versions.
You can find a detailed description of these changes
by following the link on the slide.
And now I would like to hand it back over to Martin.
MARTIN MILLMORE: Thanks, Ruslan.
I'm sure you're excited to make sure your app data can transfer
over to a new device.
The good news is that backup to the cloud
is available for free on over 2 billion Android devices today.
And Wi-Fi and cable transfers are
expanding to be on every new Android
device from January 2022.
All of this works by default. We'd encourage you to make sure
it's turned on and fine-tune what gets
exported if you have large or sensitive data.
And don't forget the new BlockStore
API to allow you to handle passwords securely.
You can find out more at g.co/android/backup,
and contact us at switching@google.com.
Thank you for your time today.
I hope you found this useful and you
will take advantage of Backup and Restore
to give your users an even better experience.
[MUSIC PLAYING]