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.

Вопрос

Есть ли общая справочная страница или документация по команде Android adb shell dumpsys [service]? Я не имею в виду this, поскольку это, похоже, не дает подробностей о выводе конкретных услуг, например adb shell dumpsys backup

Задний план

Я прочитал этот вопрос < / a> что касается команды dumpsys в целом, но, похоже, нет ссылки на какую-либо общую документацию или страницу руководства. Этот ответ связан с тем, что пользователь читает исходный код C и описывает свои наблюдения, а этот ответ , похоже, представляет собой лишь некоторые конкретные варианты использования, которые пользователь нашел полезными. Один комментарий даже спрашивает

Это откуда-то из документа или просто ваши собственные эксперименты?

Без ответа.

В частности, я пришел к ранее связанному вопросу, основанному на том факте, что я не был уверен, на что я смотрю в выводе adb shell dumpsys backup.

В документации Android говорится:

Чтобы найти резервные токены, запустите adb shell dumpsys backup. Токен представляет собой шестнадцатеричную строку после меток Ancestral: и Current :. Родовой токен относится к набору данных резервной копии, который использовался для восстановления устройства при его первоначальной настройке (с помощью мастера настройки устройства). Текущий токен относится к текущему набору данных резервного копирования устройства (набору данных, в который устройство в настоящее время отправляет свои данные резервного копирования).

Урезанная версия моего вывода:

Backup Manager is enabled / provisioned / not pending init
Auto-restore is enabled
Last backup pass started: 0 (now = 1575271089047)
  next scheduled: 1575281388106
Transport whitelist:
    android/com.android.internal.backup.LocalTransportService
    com.google.android.gms/.backup.component.D2dTransportService
    com.google.android.gms/.backup.BackupTransportService
Available transports:
    android/com.android.internal.backup.LocalTransport
       destination: Backing up to debug-only private cache
       intent: null
  * com.google.android.gms/.backup.BackupTransportService
       destination: *****@gmail.com
       intent: Intent { cmp=com.google.android.gms/.backup.SetBackupAccountActivity }
       @pm@ - 3794 state bytes
       com.google.android.dialer - 124 state bytes
       com.google.android.videos - 72 state bytes
       com.android.providers.settings - 76 state bytes
       ...
Pending init: 0
Ancestral: 0
Current:   39b423cbcb6862e5
Participants:
  uid: 1000
    com.android.providers.settings
    android
  uid: 1027
    com.android.nfc
  uid: 10004
    com.android.providers.userdictionary
    com.android.providers.blockednumber
    com.android.calllogbackup
  ...
Ancestral packages: none
Ever backed up: 66
    com.android.cellbroadcastreceiver
    com.allrecipes.spinner.free
    com.google.android.youtube
    ...
Pending key/value backup: 47
    BackupRequest{pkg=com.google.android.dialer}
    BackupRequest{pkg=com.google.android.videos}
    BackupRequest{pkg=com.android.cellbroadcastreceiver}
    ...
Full backup queue:68
    0 : com.jb.gokeyboard.langpack.ja
    0 : com.Splitwise.SplitwiseMobile
    1575154802432 : com.google.android.gsf.login
    1575156372751 : com.google.android.backuptransport
    1575159051168 : com.google.android.ext.services
    ...

Backup Manager is enabled / provisioned / not pending init
Auto-restore is enabled
Last backup pass started: 0 (now = 1575271089047)
  next scheduled: 1575281388106
Transport whitelist:
    android/com.android.internal.backup.LocalTransportService
    com.google.android.gms/.backup.component.D2dTransportService
    com.google.android.gms/.backup.BackupTransportService
Available transports:
    android/com.android.internal.backup.LocalTransport
       destination: Backing up to debug-only private cache
       intent: null
  * com.google.android.gms/.backup.BackupTransportService
       destination: *****@gmail.com
       intent: Intent { cmp=com.google.android.gms/.backup.SetBackupAccountActivity }
       @pm@ - 3794 state bytes
       com.google.android.dialer - 124 state bytes
       com.google.android.videos - 72 state bytes
       com.android.providers.settings - 76 state bytes
       ...
Pending init: 0
Ancestral: 0
Current:   39b423cbcb6862e5
Participants:
  uid: 1000
    com.android.providers.settings
    android
  uid: 1027
    com.android.nfc
  uid: 10004
    com.android.providers.userdictionary
    com.android.providers.blockednumber
    com.android.calllogbackup
  ...
Ancestral packages: none
Ever backed up: 66
    com.android.cellbroadcastreceiver
    com.allrecipes.spinner.free
    com.google.android.youtube
    ...
Pending key/value backup: 47
    BackupRequest{pkg=com.google.android.dialer}
    BackupRequest{pkg=com.google.android.videos}
    BackupRequest{pkg=com.android.cellbroadcastreceiver}
    ...
Full backup queue:68
    0 : com.jb.gokeyboard.langpack.ja
    0 : com.Splitwise.SplitwiseMobile
    1575154802432 : com.google.android.gsf.login
    1575156372751 : com.google.android.backuptransport
    1575159051168 : com.google.android.ext.services
    ...
Backup Manager is enabled / provisioned / not pending init
Auto-restore is enabled
Last backup pass started: 0 (now = 1575271089047)
  next scheduled: 1575281388106
Transport whitelist:
    android/com.android.internal.backup.LocalTransportService
    com.google.android.gms/.backup.component.D2dTransportService
    com.google.android.gms/.backup.BackupTransportService
Available transports:
    android/com.android.internal.backup.LocalTransport
       destination: Backing up to debug-only private cache
       intent: null
  * com.google.android.gms/.backup.BackupTransportService
       destination: *****@gmail.com
       intent: Intent { cmp=com.google.android.gms/.backup.SetBackupAccountActivity }
       @pm@ - 3794 state bytes
       com.google.android.dialer - 124 state bytes
       com.google.android.videos - 72 state bytes
       com.android.providers.settings - 76 state bytes
       ...
Pending init: 0
Ancestral: 0
Current:   39b423cbcb6862e5
Participants:
  uid: 1000
    com.android.providers.settings
    android
  uid: 1027
    com.android.nfc
  uid: 10004
    com.android.providers.userdictionary
    com.android.providers.blockednumber
    com.android.calllogbackup
  ...
Ancestral packages: none
Ever backed up: 66
    com.android.cellbroadcastreceiver
    com.allrecipes.spinner.free
    com.google.android.youtube
    ...
Pending key/value backup: 47
    BackupRequest{pkg=com.google.android.dialer}
    BackupRequest{pkg=com.google.android.videos}
    BackupRequest{pkg=com.android.cellbroadcastreceiver}
    ...
Full backup queue:68
    0 : com.jb.gokeyboard.langpack.ja
    0 : com.Splitwise.SplitwiseMobile
    1575154802432 : com.google.android.gsf.login
    1575156372751 : com.google.android.backuptransport
    1575159051168 : com.google.android.ext.services
    ...

Части, упомянутые в приведенном выше тексте, кажутся понятными, но есть значительный объем дополнительной информации, с которой я не уверен, что делать. В частности, я искал способ проверить, что было зарезервировано, а что нет, но с такими заголовками, как «Участники, пакеты предков, когда-либо резервное копирование, Ожидание резервного копирования ключа / значения, Полная очередь резервного копирования», я не уверен что есть, а что нет.

Я пробовал adb shell dumpsys backup -h, но ничего не помогло:

$ adb shell dumpsys backup -h
'dumpsys backup' optional arguments:
  -h       : this help text
  a[gents] : dump information about defined backup agents

Резюме

Я ищу объяснение вывода adb shell dumpsys backup и всех его заголовков. Кроме того, есть ли документация, в которой это обсуждается более подробно? Может быть, его нет, и поэтому люди вместо него прибегают к чтению исходного кода?

Искал такую ​​же, без особого успеха. Но я нашел несколько фрагментов, которые я склею здесь в ответе — без претензий на полноту или «абсолютную правильность»: я не разработчик Android, а просто энтузиаст (опытный) пользователь. Найдите мои источники в конце (сноски) и ссылки на них во фрагментах. Я воспользуюсь выводом dumpsys backup и прокомментирую то, что нашел.

Статус BackupManager

Backup Manager is enabled / provisioned / not pending init
Auto-restore is enabled
Last backup pass started: 0 (now = 1575271089047)
  next scheduled: 1575281388106

Эта часть должна быть достаточно ясной. Можно использовать bmgr enable 0|1 для (де) активации диспетчера резервного копирования. При отключении резервное копирование не выполняется (если не запускается через adb backup). Значения в строках 3 + 4 — это временные метки Unix с за исключением 0, что просто означает, что резервная копия еще не была сделана.

Транспорт

Transport whitelist:
    android/com.android.internal.backup.LocalTransportService
    com.google.android.gms/.backup.component.D2dTransportService
    com.google.android.gms/.backup.BackupTransportService

Это системные транспорты из белого списка ([2]) — хотя источник не объясняет, что это означает. Кажется, они соответствуют «доступным транспортам» из следующего блока.

Available transports:
    android/com.android.internal.backup.LocalTransport
       destination: Backing up to debug-only private cache
       intent: null
  * com.google.android.gms/.backup.BackupTransportService
       destination: *****@gmail.com
       intent: Intent { cmp=com.google.android.gms/.backup.SetBackupAccountActivity }
       @pm@ - 3794 state bytes
       com.google.android.dialer - 124 state bytes
       com.google.android.videos - 72 state bytes
       com.android.providers.settings - 76 state bytes
       ...

Список транспортов, доступных для резервного копирования. Облако Google BackupTransportService используется по умолчанию (помечено *), но требует настройки учетной записи на устройстве ([1]) (как и передача данных между устройствами {{X3}) } мне кажется). Насколько я понимаю, можно изменить значение по умолчанию с помощью bmgr transport <transportName> — и запустить резервное копирование с помощью bmgr run (для всех ожидающих резервного копирования на транспорт по умолчанию?).

Обратите внимание, что этот список соответствует выходным данным bmgr list transports. Похоже, что локальное резервное копирование (LocalTransport) запускается adb backup.

Лексемы

Pending init: 0
Ancestral: 0
Current:   39b423cbcb6862e5

Цитата из источника [5]:

Чтобы найти резервные токены, запустите adb shell dumpsys backup. Маркер представляет собой шестнадцатеричную строку после меток Ancestral: и Current:. Родовой токен относится к набору данных резервной копии, который использовался для восстановления устройства при его первоначальной настройке (с помощью мастера настройки устройства). Текущий токен относится к текущему набору данных резервного копирования устройства (набору данных, в который устройство в настоящее время отправляет свои данные резервного копирования).

Это также должно объяснить, что означает «Пакеты предков» (ниже в выходных данных).

Приложения, которые могут запрашивать резервную копию

Participants:
  uid: 1000
    com.android.providers.settings
    android
  uid: 1027
    com.android.nfc
  uid: 10004
    com.android.providers.userdictionary
    com.android.providers.blockednumber
    com.android.calllogbackup
  ...

Участники — это приложения, которые могут запрашивать резервное копирование, отсортированное по AID. ([1])

Статистика резервного копирования

Ancestral packages: none

Информацию о пакетах предков см. Также выше. Я не знаю, как бы это выглядело, если бы они были (но я предполагаю, что это похоже на ever backed up ниже); Я сам запускаю свои устройства Android «Google free» (LineageOS, без Google Apps) и поэтому никогда не использовал эту часть. Еще несколько примечаний по этому поводу: похоже, они происходят из набора резервных копий, который не был создан на том же устройстве (или, по крайней мере, не из одной и той же «итерации», т.е. если они пришли с одного физического устройства, то это было с завода сброс настроек). В строке 481 исходного кода [2] мы находим примечание:

Профиль работы предков соответствует профилю, который использовался для восстановления профиля вызывающих абонентов.

Далее, в справке по BackupManager [3]:

У наследственного серийного номера будет соответствующий UserHandle, если у устройства есть рабочий профиль, который был восстановлен из другого рабочего профиля с серийным номером ancestralSerialNumber.

Наконец, в руководстве по резервному копированию [4]:

Во время мастера начальной настройки устройства пользователю отображается список доступных наборов данных резервного копирования и его спрашивают, из какого из них следует восстановить данные. Какой бы набор резервных данных ни был выбран, он становится родительским набором данных для устройства. Устройство может восстанавливать данные либо из собственных резервных копий, либо из набора данных предков. Устройство отдает приоритет своему собственному резервному копированию, если доступны резервные копии из обоих источников. Если пользователь не прошел через мастер настройки устройства, то устройство может восстановить только из собственных резервных копий.

Ever backed up: 66
    com.android.cellbroadcastreceiver
    com.allrecipes.spinner.free
    com.google.android.youtube
    ...

Это кажется само собой разумеющимся: количество и список приложений, которые уже являются частью резервного набора.

Pending key/value backup: 47
    BackupRequest{pkg=com.google.android.dialer}
    BackupRequest{pkg=com.google.android.videos}
    BackupRequest{pkg=com.android.cellbroadcastreceiver}
    ...

Я не нашел упоминания об этом, но из всего вышесказанного можно предположить, что это «участники», запросившие резервную копию, и их запросы еще не были обработаны.

Full backup queue:68
    0 : com.jb.gokeyboard.langpack.ja
    0 : com.Splitwise.SplitwiseMobile
    1575154802432 : com.google.android.gsf.login
    1575156372751 : com.google.android.backuptransport
    1575159051168 : com.google.android.ext.services
    ...

В этом комментарии [1] это список Last backup : package name (причем Last backup, скорее всего, снова является меткой времени Unix или 0, когда он еще не был скопирован). На устройстве очередь резервного копирования находится на устройстве в /data/backup.

Надеюсь, мне удалось пролить свет, и приведенная выше информация будет полезна вам (и другим). Вы можете узнать больше подробностей из источников, упомянутых ниже — особенно при сканировании исходного кода ([2]), я мог кое-что пропустить.

Источники

1. Android Internals :: Поваренная книга кондитера — WikiLeaks от Джонатана Левина . Соответствующая часть доступна в виде отрывка: Резервное копирование и восстановление приложений; найти подробную информацию на веб-сайте книги
2. Исходный код для BackupManagerService.java
3. Справочное руководство по BackupManager
4. Руководство разработчика по автоматическому резервному копированию
5. Руководство разработчика по тестированию резервного копирования