Google Backup: Multiple devices using the same account - what happens on Restore?

Question

It is nothing new that one can use multiple Android devices with a single Google account. Switching on a new device for the first time asks whether one wants to store one's data with Google, which then would always sync "some stuff" to the Google servers, basically

• some application data (if the apps support it explicitly)
• Wi-Fi passwords
• browser bookmarks
• a list of the apps installed from Google Play
• words added to the dictionary used by the onscreen keyboard
• most of your customized settings

Details might be found in the Google Dashboard. Relevant questions here covering those issues include:

• What info does Google backup?
• What exactly is synced with Google?
• How does Android sync the WiFi Profiles?

The Developers API on Google Backup gives some further insight on how the backup stuff is supposed to work (and several questions here show how it really works -- that is, sometimes it does, sometimes only partly, and sometimes not at all). Aside from reliability and the fact that not everybody wants his private data in the cloud (and even mentioned API reference² warns: Android makes no guarantees about the security of your data while using backup. You should always be cautious about using backup to store sensitive data, such as usernames and passwords.), my main question is:

Having backed up data from multiple devices using the same account:

• what would happen to a factory-reset device being used that way before? Would it be recognized, and have only those things restored which have been used on it before?
  ^{(device-identification could e.g. take place e.g. via IMEI (but not via the Android_ID, as that might be gone with a factory reset) -- and this could be the reason for the behaviour described in Nalum's answer)}
• what would be restored to a (new/factory-reset) device you just initialize for the first time with this Google account?
  ^{(if devices would be identified with backups in the Google account used, this could trigger a special action for "new device", e.g. "restore all, device changed!" -- or "restore all from the no longer connected device X, as it was probably replaced!" -- but stick to "restore only what was on that device" in case of a factory-reset)}

The deal is: If one has multiple devices, they are often used for specific issues, so one does not want everything on all devices. As I've seen no way to chose which data to backup (e.g. to exclude those "sensitive data" we have been warned about: WiFi passwords would belong to that category), I assume there's no choice on restore either? So how is this handled?

Answer 1

Let's talk about sets, baby

Android's backup service has a concept called a set: the set of all data backed-up from one device (on one transport, but that's a detail). Each set is identified by a unique string, such as the IMEI on the device. When an app (or the list of installed apps) is backed up, its backup data go into the set associated with the device it's being backed up from. All the sets are still specific to the user's Google account. If you wipe your device and sell it to someone else, he won't be able to access that device's set unless he can log into your Google account.

Default behaviour

When an app is installed, or a device has its list of apps restored, the backup system first looks in that device's set for backup data for that package. If it doesn't find any (either because it's a completely new device with no backed-up data, or because that package has never been installed on that device), it'll expand the search to other sets. (If there's a choice, it'll use the last set that was used for a full-device restore.)

Thus, when you set up a new device, it'll restore the list of apps from an old device's backup, and restore each app from the old device's backup. If you had an app installed on one device and you install it on another device, the app will be restored with its data from the old device. In either case, the data are now backed up into the new device's set, which means that the backup data from the two devices are separate from now on.

After you factory-reset a device, it'll restore from that device's last backup if there is one, and failing that, from some other device's backup if there is one, but it will start to create its own set from then on. That's why Nalum's two devices don't see each others' backed-up apps: they're each restoring from their own last backups.

Source

This mechanism doesn't have any user-facing documentation, since it's supposed to automatically do the right thing, but the code is available.

bmgr: basic use

As Izzy found, the bmgr tool gives you some control over this process. It's intended as an aid for programmers to help test and debug the backup integration in their apps. You can use this tool in an adb shell to trigger backups and restores of chosen packages, wipe packages' backed-up data, and even a whole-device restore.

Don't try to use it in an on-device shell except as root: you need the system-level android.permission.BACKUP to do anything interesting with it.

You can make an app update its backed-up data immediately:

bmgr backup com.shadowburst.showr
bmgr run

(or whatever the app's package name is). There's not normally any need to do this, as apps request their own backups whenever their data changes, but this lets you work around a badly-written app. To restore one package from the backed-up data it would choose by default:

bmgr restore com.shadowburst.showr

but again, this will only do what the device would do on its own, so you shouldn't need to use it. Note also that the device already needs to be installed to make this work.

More control

Now for the stuff that the backup system won't do on its on. To see what sets of backed-up data are available:

bmgr list sets

and you'll get some output like this:

  3ff7800e963f25c5 : manta
  3f0e5c90a412cca7 : manta
  3dd65924a70e14c8 : TF101
  3baa67e9ce029355 : m0

The 64-bit hex number on the left is a token. You'll need this in a minute. The thing on the right is a (relatively) friendly name for the device that owns the set. For example, manta is the code name for the nexus-10; TF-101 refers to the original asus-eee-pad-transformer. Once you've figured out which set you want, you can restore an app from that set using its token:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

You can add more package names to the end of the command to restore several packages at once, or you can specify no package name (just the token) to restore every app with data in that set (that is, it does a full-system restore).

Finally, you can wipe an app's data from the current set:

bmgr wipe com.shadowburst.showr

This will make its next backup operation start from scratch. This might be useful after uninstalling an app, if an error in the app corrupted its backup data and you don't want it restored.

You can't make a device start writing into a different set, nor can you wipe a whole set.

Answer 2

The following is by far no answer to the question, but might shed some light on some details:

Some pieces extracted from the Backup API

Though the API is mainly targeted at developers, there are a few facts we might be able to extract for our case. In the following list, italics mark quotes from the API documentation.

• Android automatically performs a restore operation when your application is installed and there exists backup data associated with the user.
  → this can mean two things:
  • if an app supports the Google Backup API, and the user has the Google Backup enabled, available backup-data will automatically be restored on installation. Good thing when you install an app used on a single device to a second device for the first time.
  • backups are only associated with the Google Account, not with the device (and there exists backup data associated with the user) -- or the other fact was just ignored as irrelevant for this special case ("app is installed")
• The backup transport is the client-side component of Android's backup framework, which is customizable by the device manufacturer and service provider. The backup transport may differ from device to device [...]
  → this might explain the unreliability when it comes to different devices (or different Android versions).
  ^{(emphasis mine)}
• Data backup is not guaranteed to be available on all Android-powered devices.
  (no comment)
• Google provides a backup transport with Android Backup Service for most Android-powered devices running Android 2.2 or greater.
  → here we have the minumum Android version required for Google Backup being available at all: Froyo, AKA Android 2.2
• To get your Backup Service Key, register for Android Backup Service. [...]
  → each app must have its own key. There's no "why" described, but a good guess: to isolate the backups so no app can read backups of another app (wrong key; as for backups of another user: wrong account)
• While developing your application, you can initiate an immediate backup operation from the Backup Manager with the bmgr tool.
  → looks like there's a way to manually trigger backups? Let's dig into that later. ↓
• When it's time to restore your application data, the Backup Manager calls your backup agent's onRestore() method.
  → this again underlines the first item of this list: first the app must be installed, then their own implementations are used to restore its data. On a second look: if the app-restore fails, there wont be a data-restore for the failed apps -- until you manually install them via Google Play. Then, as the first item showed, data should automatically be restored via Google Backup under the explained conditions (must have been backed up with it, same account, etc.)
• Backing up other files
  → forgive me not quoting from the (technical) contents of that chapter, but in short: only files from internal storage can be backed up according to it.

Some pieces extracted from the bmgr API

• It provides commands to induce backup and restore operations [...]
  → looks like here's a way how to trigger actions manually if the "automatism" fails
• These commands are accessed via the adb shell.
  → this does not need any explanation :)
• adb shell bmgr backup <package>
  → OK, so this action is bound to apps. Guess if you know the data provider's package name, this should work as well (e.g. com.android.providers.settings for the system settings, or com.android.providers.telephony for SMS/MMS etc?)
• you can force all pending backup operations to run immediately by using the bmgr run command
  → the first command just "schedules" backups. Having triggered all packages, this can be used to immediately execute them.
• adb shell bmgr restore <package>
  → this looks to nice to be true, right? Exactly, because: The Backup Manager will immediately instantiate the application's backup agent and invoke it for restore. Data only, as the app already needs to be there (as its routines are called).

So in short: bmgr can be used to trigger backups for apps supporting Google Backup, which you have installed -- and it can trigger data restore for the same. It can not be used to trigger a complete restore -- at least that's not documented here.

Answer 3

Some more info on Google backup. When I flashed a custom firmware it didn't restore the apps as I expected. In Settings -> Backup & reset it was showing "Backing up to debug-only private cache", and bmgr list sets gave no results.
I solved my problem by doing these steps in adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
This wasn't enough, though. It didn't start installing apps. This showed the reason why:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
It had created a new set, although the IMEI obviously was the same. Anyway, this was the fix:
$ bmgr restore 3a0a00a516a1daf1 (the ID it showed the first time)
$ bmgr run (to be sure)
Then it started downloading the apps.

Answer 4

My experience with it has been that each device has it's own backup. I get this from messing around with my Nexus 7 and my Galaxy S II. Other than that I do not know.

Apps:

My Nexus 7 has these apps Caustic, DC Comics and 20 Minute Meals that upon factory reset of my Galaxy S II are not installed on the Galaxy S II.

My Galaxy S II has theses apps DriveDroid and Human Japanese that upon factory reset of my Nexus 7 are not installed on the Nexus 7.

The apps are compatible with both devices, so incompatibility cannot be the reason for them to not be installed on the respective other device.

Data:

As for Wifi and other data I'm unsure as each time I have set up the Wifi on each device during the initial android setup. As to other google accounts that you may have they do not seem to be copied to each device and the same has been true of Skype and GitHub accounts on each device.

Answer 5

I backed stuff up using both built-in Google backup and Helium backup before I wiped and installed Carbon custom ROM on a Nexus 4 (from KitKat stock). Expected Google to restore apps, settings etc. as it has done before when I've restored this phone but no joy.

Tried Helium as well, also no joy, even with manual 'PC Download' restores - said 'restored' but Wifi and app data still not there.

Running bmgr restore <xxx> full restore and bmgr run as detailed above triggered the full Google restore and worked a treat - lifesaver for me!

Google could make a better effort, especially if they want to compete with the Apple 'just works' idea... Still I do love the hackability of Android despite its pitfalls!