Backing up to debug only private cache как исправить

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.

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.

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.