Your users love your app.
They store all of their content there.
They share things.
They literally squeal in anticipation and delight
when there's an update available.
They're all your number one fan.
But then they get a new phone and use Tap & Go to transfer
their account and apps across.
They open up your app but nothing's there.
With an Android M, we've turned on full updates and backup
for apps, targeting the end release and above.
My name is Matthew, working on Play Services Back
Up and Restore, and I'm going to walk you through these changes.
Not to put words in your brain, but you
might be thinking that this kind of is already handled
by data syncing frameworks.
There's Parse, there's Firebase, there's
the Android Sync Framework, the Google Play Games API.
It's a long list.
But any data fetching is going to be
tied to some sort of user account
requiring a login before you can start pulling down the data.
Backup and Restore still requires an account,
but the account is the user's Google account
is set up elsewhere.
By the time the user enters your app, the data is already there.
And then they still need to consume any welcome screens
and re-accept any Terms of Service.
When an app is restored from an ancestral device,
all of the persisted user state that
existed on a previous device, will now
exist on a new one as an exact duplicate.
If you're smart about what configuration you persist
and how you persist it, you can drastically
shorten you app's out of box flow.
The most powerful part of this is
that once you build your app against the MSDK,
it will just start backing up.
Let's pause for a moment to let this sink in.
It means that with no further effort,
as soon as you download the M developer SDK
and rebuild your app against it, your app will start backing up.
Backups are run, at most, once a day
and use the Job Scheduler API as reintroduced in Lollipop
to only run when the device is idle
and connected to Wi-Fi and power.
Your app has no control over scheduling backups.
The backed up data is encrypted at rest
in the user's Google Drive account
and is not counted against their drive quota.
For now, we've capped the data size
at about 25 megabytes per app per user.
Be careful.
If your app hits this limit, it will stop backing up.
Now a restore will happen at install time.
Whenever an app is installed and we have some corresponding data
present in Drive.
Restore is not restricted to apps
installed by the Play Store.
Side loading an app, for example,
or using a third party app store will still initiate a restore.
Whatever connection is used for the app download
is also going to be used to download this extra restored
data.
All right.
We've covered that all apps targeting [INAUDIBLE] will
automatically start backing up with no further effort
from anybody.
Let's cover how to opt out.
If you don't want to use the feature,
you can add the application attributes,
allow backup, false to you manifest.
OK.
Now that all the lame-ohs have left to go disable backups,
let's get to be cool stuff.
For example, what not to back up.
It's not a good idea to back up certain pieces of data.
For example, user credentials or device-specific tokens.
Let's look at Google Cloud Messaging.
When you register your app with the Cloud Messaging back end,
you get a device-specific ID that your server
uses to push notifications to that specific device.
If you try to restore this ID onto another device,
it just would not work, or rather, it
would work but your server would just not
be able to send any messages to this new device.
So you really have to be careful.
Think about the data that you're persisting to disk
and think about how well it carries over to a completely
different device.
We've made it easy to exclude data
that you might not want stored in the Cloud
or that doesn't make sense to restore across devices.
You add a manifest, flag the points of an XML resource
files.
The XML file is easy.
It's a series of include and exclude tags, each of which
specifies either a directory or a file, along with the domain
that the data belongs to.
An Exclude targets how you would specify
that you want to ignore a specific file or directory.
By default, the backup set is produced reductively.
That means you start with everything
and then you strip things out with Excludes.
Take this example.
This is saying that I want to back up my entire data
directory except for the device info database.
Now, in some cases, it's kind of inconvenient to have
to enumerate every single thing you want to exclude.
So there's also an Include tag.
Specifying an Include changes the default behavior
from back up everything except whatever I explicitly
took out, to only back up the data I ask you to.
Take this example.
The only file that will be backed up is
my_important_file.txt.
In other words, having an Include tag changes
the backup logic from being reductive,
where you start with everything and remove, to constructive,
where you start with nothing and then you add.
Next, we'll talk about exactly what these domains are.
Any time an app creates a file, it
isn't going to the app's root directory
but rather it goes into some Files directory underneath.
Similarly, when you create a Shared Preferences object,
it is persisted as an XML file under some Shared Preference
directory.
Same is true for databases and extra amount of storage.
Finally, you can also manipulate data
that resides within the root directory of the app.
When specifying the data that you want to include or exclude,
you have to tell your Backup Manager what
domain it is or, put equivalently,
which directory to look in.
All righty.
So hopefully at this point you're thinking,
this is so cool and setting it up up here is pretty simple,
but it's a little opaque.
How do I know my data is properly being backed up?
What happens if [INAUDIBLE] is badly formed?
How can I assure myself that this thing is actually working?
We have some more resources to help.
I won't get into the details in this video
but, if you're interested, look at the video description
for instructions to turn on Verbose Logging within your app
as well as how to manually initiate a backup
and restore and appoint it to some sample code.
OK.
This has been fun and, with luck,
if at any point during this video
you're worried about being backed up,
you're now sitting more comfortably.
[MUSIC PLAYING]