Take the 2-minute tour ×
Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. It's 100% free, no registration required.

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:

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 reference2 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?

share|improve this question
    
Two more sources which might be an interesting read on this are: Google backup and restore for Android is device specific? (which describes the "mess" of at least Android versions before 4.x), and Android's automatic backup and restore service is great ... when it works. Both partly mirror my question, but none answer it. So much about googling the issue. –  Izzy Mar 25 '13 at 22:25
1  
The only input I can give is that it's so unreliable. I wish there were a manual backup/restore button I could use. I reset my tablet the other day and it didn't restore all my apps and settings, yet previous times it's been done it did. I don't like that I can't rely on it. –  crdx Mar 28 '13 at 8:36
    
As not even a bounty is able to bring out the details, I guess chances to find a "full answer" are rather low. So we know about the same as before: it might work "the one way or the other", one has to try to figure out, and one might be lucky or not. Thanks, Google, for an unreliable tool without any user-documentation :( So the bounty goes to Nalum: though the answer pre-dated the bounty, it's the best we've got :) –  Izzy May 9 '13 at 11:45
    
Related: stackoverflow.com/questions/8502412/… –  Flow Oct 31 '13 at 10:30
    
@Flow Yeah. And the answer looks astounishingly familar :) –  Izzy Oct 31 '13 at 11:59
add comment

4 Answers

up vote 12 down vote accepted

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 : 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 ; TF-101 refers to the original . 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.

share|improve this answer
    
Very thorough answer, thank you, Dan! The "manual control" (where to restore from) is an added plus I was looking for. I wish there was a user choice for all this, like a pop-up when restore kicks in: "Do you want to restore?"->"From what set?"->"Select details (full-restore, xxx...)". While it might be nice when an app knows to "automatically do the right thing", I like to be in control, and sometimes that's even needed. Also, a restore might be needed in cases other than factory-resets and new devices, so there should be a way for the user to trigger it... –  Izzy Jul 19 '13 at 7:56
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
Only application that have been installed on that device are re-installed from the backup. E.G. the application DriveDroid is installed on my phone and does not download to the Nexus 7 after a factory reset. I have Caustic on the Nexus 7 which does not download on the Galaxy S II among other apps. –  Nalum Mar 26 '13 at 19:44
    
Thanks -- I've integrated this with the answer. As there are quite controverse reports: Would you be so kind to update your answer with the Android versions of the devices used? Thanks in advance! To un-clutter our conversion, I will also go and delete some of my comments (feel free to do the same for those already integradet into the answer itself). –  Izzy Mar 26 '13 at 21:46
    
So now comes the deal: if nothing is cross-restored, what to do if one of the devices "breaks" (or you want to replace the two by one new device) and you want to "merge"? Guess I'm not the only one really missing a good manual... –  Izzy Mar 29 '13 at 18:15
add comment

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!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.