Questions about the new auto-backup feature of Android M

Question

background

Google has introduced a nice new feature on Android M that allows you to backup and restore apps, even using ADB , as shown on this video .

It seems all you have to do is use the adb shell bmgr command to backup and restore apps, as such:

backup:

adb shell bmgr fullbackup PACKAGE_NAME

restore an app:

adb shell bmgr restore PACKAGE_NAME

And it works well.

The problem

The docs are quite in their new phase, so I can't find answers to some questions about this new tool.

What I've tried

When typing the adb shell bmgr, I get some clues about how to use it, but I can't find the answers to the questions. Not having a device with Android M , but an emulator instead, I guess it will work differently.

Here's what's written when typing this command:

usage: bmgr [backup|restore|list|transport|run] bmgr backup PACKAGE bmgr enable BOOL bmgr enabled bmgr list transports bmgr list sets bmgr transport WHICH bmgr restore TOKEN bmgr restore TOKEN PACKAGE... bmgr restore PACKAGE bmgr run bmgr wipe TRANSPORT PACKAGE bmgr fullbackup PACKAGE...

The 'backup' command schedules a backup pass for the named package. Note that the backup pass will effectively be a no-op if the package does not actually have changed data to store.

The 'enable' command enables or disables the entire backup mechanism. If the argument is 'true' it will be enabled, otherwise it will be disabled. When disabled, neither backup or restore operations will be performed.

The 'enabled' command reports the current enabled/disabled state of the backup mechanism.

The 'list transports' command reports the names of the backup transports currently available on the device. These names can be passed as arguments to the 'transport' and 'wipe' commands. The currently active transport is indicated with a '*' character.

The 'list sets' command reports the token and name of each restore set available to the device via the currently active transport.

The 'transport' command designates the named transport as the currently active one. This setting is persistent across reboots.

The 'restore' command when given just a restore token initiates a full-system restore operation from the currently active transport. It will deliver the restore set designated by the TOKEN argument to each application that had contributed data to that restore set.

The 'restore' command when given a token and one or more package names initiates a restore operation of just those given packages from the restore set designated by the TOKEN argument. It is effectively the same as the 'restore' operation supplying only a token, but applies a filter to the set of applications to be restored.

The 'restore' command when given just a package name intiates a restore of just that one package according to the restore set selection algorithm used by the RestoreSession.restorePackage() method.

The 'run' command causes any scheduled backup operation to be initiated immediately, without the usual waiting period for batching together data changes.

The 'wipe' command causes all backed-up data for the given package to be erased from the given transport's storage. The next backup operation that the given application performs will rewrite its entire data set. Transport names to use here are those reported by 'list transports'.

The 'fullbackup' command induces a full-data stream backup for one or more packages. The data is sent via the currently active transport.

The questions

I have a few questions:

1. Suppose I call those commands via the device itself, will they work? If not, will they work on a rooted device? Or at least backup&restore the current app (app X backups&restores itself) ?

2. Where are the backups being stored? Is it possible to store them into a customized path ? Maybe even the one of the PC ?

3. Is it possible to backup the same app into multiple states? For example, an app could have a backup for when it has logged in, and a backup for when it has some settings being configured. This way, you could restore to each of those backups.

4. They write in the above description about "currently active transport" . What is it exactly ? Can it be customized?

5. Is it possible to run a backup/restore on all apps? Or should I put the packages of all apps?

6. It seems the "fullbackup" does the backup right away. What does the "run" attribute used for? Or maybe that's all because I use an emulator?

Answer 1

Hi there android developer. It seems like we have a lot of shared interests (i answered your questions on GcmNetworkManager).

1. Suppose I call those commands via the device itself, will they work? If not, will they work on a rooted device? Or at least backup&restore the current app (app X backups&restores itself) ?*

   Unfortunately I am not sure exactly what you mean. I think you are asking if they will work on a real device as compared to an emulator and the answer is yes. There is little chance that something will work on an emulator but not work on the real device - usually it is the other way around.

2. Where are the backups being stored? Is it possible to store them into a customized path ? Maybe even the one of the PC ?*

   There are 2 types of backup - the older key/value backup which is driven by the application itself by implementing a BackupAgent, and as of Android M there is "full app data backup" which is where the framework provides the BackupAgent implementation for you.

   In both of these cases the backup data is stored on Google's servers. There's no way to store them in a customized path, short of writing your own backup transport (which is something that only OEMs can do, or people who build their own custom ROMS).

3. Is it possible to backup the same app into multiple states? For example, an app could have a backup for when it has logged in, and a backup for when it has some settings being configured. This way, you could restore to each of those backups.*

   No. There is one 'backup set' per application per device. If you do a factory reset then it's considered to be a new device and will have a different backup set.

4. They write in the above description about "currently active transport" . What is it exactly ? Can it be customized?*

   The BackupTransport is the privileged (i.e. /system) app that is responsible for determining where the backup data is stored. The BackupManager is part of the OS and manages when backups are run and takes the data from the application and passes it to the Transport, which then determines what to do with it. The OS can't take responsibility for this b/c it doesn't know where the data is supposed to go, so it delegates to a vendor-supplied Transport. The Transport is a very privileged app that must be shipped with the system image. Currently there are only 2 transports - the local 'debug' transport, and the Google-provided transport.

5. Is it possible to run a backup/restore on all apps? Or should I put the packages of all apps?*

   I assume you mean by doing adb shell bmgr. No there's no way to do this. However there are hidden APIs in the BackupManager that you can call in order to initiate a full restore (the Setup-Wizard does this for example). Because the APIs are hidden you would have to download the source and compile against it (or use reflection). Also you need the permission android.permission.BACKUP which is annotated @SystemApi. I've never done this myself so I know it is theoretically possible but likely a huge headache as it's completely undocumented (it's meant for OEMs and other vendors that ship their own devices).

6. It seems the "fullbackup" does the backup right away. What does the "run" attribute used for? Or maybe that's all because I use an emulator?*

   Prior to android-M there was only key/value backup.

   adb shell bmgr backup <PACKAGE..>
   adb shell bmgr run
   

   Are both for the key/value backup flow. An app can only use key/value backup if they went to the trouble of implementing their own BackupAgent (linked above). For example, a lot of system components do this (this is how your WiFi APs are restored across devices, for example). Some system apps do this as well (Gmail, the Google launcher,..) in fact if you run

   adb shell dumpsys backup
   

   you will see a list of all the packages that use key/value backup. The reason that you have to call 'bmgr backup p1 p2 etc' and then 'bmgr run' is b/c the 'bmgr backup' command will stage the packages to be backed up 'in the future.' When you call 'bmgr run' this manually kicks off the backup pass. As the post above says, it is meant for debugging.

   If you run

   adb shell dumpsys backup
   

   On an M device you should also see the list of apps that have been backed-up using the full app data backup flow, as well as the list of apps using k/v backup that are 'staged' for backup in the future (this might be empty depending on when you run it).

   Now,

   adb shell bmgr fullbackup <PACKAGE..>
   

   is for the full backup flow. However, there is a catch. The two (key/value backup & full backup) are completely independent, except that the BackupManager keeps track of metadata for the full backup packages using the key/value mechanism (this metadata includes things like app version, signature, timestamps, etc). This is why you need to run

   adb shell bmgr run
   

   to ensure that the full app data metadata is correctly backed up, before you can successfully use the full backup flow.

   Don't think of the emulator as any different from an actual device. In theory it is supposed to exactly 'emulate' the real device. There should be no difference between the emulator and the physical thing, so (AFAIK) there are no 'special' commands that work on an emulator that won't work on a real device.

Answer 2

If you haven't already seen them, here are the reference documents for the new features related to auto backup. Backup capabilities existed in previous versions and are described in this guide. I've worked with them on KitKat. After a quick scan, it appears that the new features in the M Preview are:

1. Automatic daily backup
2. More options for configuring and controlling what is included in the backup.

Much of your question focuses on the adb shell bmgr tool. That it for developer testing. In normal device use, the backup is done automatically every 24 hours, when the device is idle, charging, and connected to a Wi-Fi network.

Suppose I call those commands via the device itself, will they work?

With the backup being done automatically, is there really a need for that?

Where are the backups being stored? Is it possible to store them into a customized path ? Maybe even the one of the PC ?

Stored to the user's Google Drive account. No. No.

They write in the above description about "currently active transport" . What is it exactly ? Can it be customized?

Provided by Google. Don't think so.

Is it possible to run a backup/restore on all apps? Or should I put the packages of all apps?

By default, all apps are backed up. Reference docs describe how to limit what is included.

It seems the "fullbackup" does the backup right away. What does the "run" attribute used for? Or maybe that's all because I use an emulator?

In addition to the new auto backup capability, an app can perform incremental backups, as described in the guide mentioned above. The run command is provided for testing, to allow a developer to force an immediate activation of the incremental backup processing.