Давай поговорим о наборах, детка

Служба резервного копирования Android имеет концепцию, называемую набором : набор всех данных, зарезервированных с одного устройства (на одном транспорте , но это деталь). Каждый набор идентифицируется уникальной строкой, такой как IMEI на устройстве. При резервном копировании приложения (или списка установленных приложений) данные его резервной копии попадают в набор, связанный с устройством, с которого выполняется резервное копирование. Все наборы по-прежнему привязаны к учетной записи Google пользователя. Если вы очистите свое устройство и продадите его кому-то другому, он не сможет получить доступ к набору этого устройства, если не войдет в вашу учетную запись Google.

Поведение по умолчанию

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

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

После того, как вы восстановите заводские настройки устройства, оно будет восстановлено из последней резервной копии этого устройства, если она есть, и, если это не удастся, из резервной копии какого-либо другого устройства, если она есть, но с этого момента оно начнет создавать свой собственный набор. Вот почему два устройства Налума не видят резервные копии приложений друг друга: каждое из них восстанавливается из своих последних резервных копий.

Источник

Этот механизм не имеет документации для пользователя, поскольку он должен автоматически выполнять правильные действия, но код доступен .

bmgr: основное использование

Как обнаружил Иззи, bmgrинструмент дает вам некоторый контроль над этим процессом. Он предназначен для помощи программистам в тестировании и отладке интеграции резервного копирования в их приложениях. Вы можете использовать этот инструмент adb shellдля запуска резервного копирования и восстановления выбранных пакетов, очистки резервных копий данных пакетов и даже восстановления всего устройства.

Не пытайтесь использовать его в оболочке на устройстве, кроме как root : вам нужен системный уровень android.permission.BACKUP, чтобы делать с ним что-нибудь интересное.

Вы можете заставить приложение немедленно обновить свои резервные данные:

bmgr backup com.shadowburst.showr
bmgr run

(или любое другое имя пакета приложения). Обычно в этом нет необходимости, так как приложения запрашивают свои собственные резервные копии всякий раз, когда их данные изменяются, но это позволяет вам обойти плохо написанное приложение. Чтобы восстановить один пакет из резервной копии данных, по умолчанию будет выбрано:

bmgr restore com.shadowburst.showr

но опять же, это будет делать только то, что устройство будет делать само по себе, поэтому вам не нужно его использовать. Также обратите внимание, что устройство уже должно быть установлено, чтобы это работало.

Больше контроля

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

bmgr list sets

и вы получите такой вывод:

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

64-битное шестнадцатеричное число слева — это токен . Это понадобится вам через минуту. То, что справа, — это (относительно) понятное имя для устройства, которому принадлежит набор. Например, manta — это кодовое название nexus-10 ; TF-101 относится к оригинальному asus-eee-pad-transformer . Как только вы определились, какой набор вам нужен, вы можете восстановить приложение из этого набора, используя его токен:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

Вы можете добавить больше имен пакетов в конец команды, чтобы восстановить несколько пакетов одновременно, или вы можете не указывать имя пакета (только токен), чтобы восстанавливать каждое приложение с данными в этом наборе (т . восстановить).

Наконец, вы можете стереть данные приложения из текущего набора:

bmgr wipe com.shadowburst.showr

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

Вы не можете заставить устройство начать запись в другой набор и не можете стереть весь набор.

Следующее, безусловно, не является ответом на вопрос, но может пролить свет на некоторые детали:

Некоторые фрагменты, извлеченные из Backup API

Хотя API в основном предназначен для разработчиков, есть несколько фактов, которые мы могли бы извлечь для нашего случая. В следующем списке курсивом отмечены цитаты из документации по API.

• Android автоматически выполняет операцию восстановления, когда ваше приложение установлено и существует резервная копия данных, связанных с пользователем.
  → это может означать две вещи:
  • если приложение поддерживает API резервного копирования Google и у пользователя включено резервное копирование Google, доступные данные резервного копирования будут автоматически восстановлены при установке. Хорошо, когда вы впервые устанавливаете приложение, используемое на одном устройстве, на второе устройство.
  • резервные копии связаны только с учетной записью Google, а не с устройством ( и существуют резервные данные, связанные с пользователем ), или другой факт был просто проигнорирован как не относящийся к этому особому случаю («приложение установлено»)
• Резервный транспорт — это клиентский компонент платформы резервного копирования Android, который настраивается производителем устройства и поставщиком услуг. Резервный транспорт может отличаться от устройства к устройству [...]
  → это может объяснить ненадежность, когда речь идет о разных устройствах (или разных версиях Android).
  ^{(выделено мной)}
• Резервное копирование данных не гарантируется на всех устройствах под управлением Android.
  (без комментариев)
• Google предоставляет резервный транспорт со службой резервного копирования Android для большинства устройств на базе Android под управлением Android 2.2 или более поздней версии.
  → здесь у нас есть минимальная версия Android, необходимая для Google Backup, которая вообще доступна: Froyo, также известная как Android 2.2.
• Чтобы получить ключ службы резервного копирования, зарегистрируйтесь в службе резервного копирования Android. [...]
  → у каждого приложения должен быть свой ключ. Там нет описания «почему», но есть хорошее предположение: изолировать резервные копии, чтобы ни одно приложение не могло читать резервные копии другого приложения (неправильный ключ; что касается резервных копий другого пользователя: неправильная учетная запись)
• При разработке приложения вы можете инициировать немедленную операцию резервного копирования из диспетчера резервного копирования с помощью инструмента bmgr.
  → похоже, есть способ вручную запустить резервное копирование? Давайте углубимся в это позже. ↓
• Когда пришло время восстановить данные вашего приложения, диспетчер резервного копирования вызывает onRestore()метод вашего агента резервного копирования.
  → это еще раз подчеркивает первый пункт этого списка: сначала должно быть установлено приложение, затем используются собственные реализации для восстановления его данных. На второй взгляд: если восстановление приложения завершится неудачно, восстановление данных для сбойных приложений не произойдет, пока вы не установите их вручную через Google Play. Затем, как показал первый пункт, данные должны автоматически восстановиться через Google Backup при объясненных условиях (должна быть сделана резервная копия с его помощью, та же учетная запись и т. д.)
• Резервное копирование других файлов
  → извините, что я не цитирую (техническое) содержание этой главы, но вкратце: в соответствии с ней можно создавать резервные копии только файлов из внутренней памяти.

Некоторые фрагменты извлечены из bmgr API

• Он предоставляет команды для запуска операций резервного копирования и восстановления [...]
  → похоже, вот способ запуска действий вручную, если «автоматизм» не работает
• Доступ к этим командам осуществляется через оболочку adb.
  → это не требует пояснений :)
• adb shell bmgr backup <package>
  → ОК, значит, это действие привязано к приложениям. Угадайте, если вы знаете имя пакета поставщика данных, это также должно работать (например com.android.providers.settings, для системных настроек или com.android.providers.telephonyдля SMS / MMS и т. д.?)
• вы можете заставить все ожидающие операции резервного копирования выполняться немедленно, используя bmgr runкоманду
  → первая команда просто «планирует» резервное копирование. Запустив все пакеты, это можно использовать для их немедленного выполнения.
• adb shell bmgr restore <package>
  → это выглядит красиво, чтобы быть правдой, верно? Именно потому, что: Менеджер резервного копирования немедленно создаст экземпляр агента резервного копирования приложения и вызовет его для восстановления. Только данные, так как приложение уже должно быть там (так называются его подпрограммы).

Короче говоря: bmgrможет использоваться для запуска резервного копирования для приложений, поддерживающих Google Backup, которые вы установили, и может запускать восстановление данных для того же самого. Его нельзя использовать для запуска полного восстановления — по крайней мере, это не задокументировано здесь.

Еще немного информации о резервном копировании Google. Когда я прошил кастомную прошивку, приложения не восстановились, как я ожидал. В «Настройки» -> « Резервное копирование и сброс » показывалось «Резервное копирование в частный кеш только для отладки» и bmgr list setsне давало никаких результатов.
Я решил свою проблему, выполнив следующие шаги adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Однако этого было недостаточно. Не начал установку приложений. Это показало причину:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
он создал новый набор, хотя IMEI, очевидно, был тем же самым. Во всяком случае, это было исправлением:
$ bmgr restore 3a0a00a516a1daf1(идентификатор, который он показал в первый раз)
$ bmgr run(чтобы быть уверенным)
. Затем он начал загружать приложения.

По моему опыту, у каждого устройства есть собственная резервная копия. Я понял это из-за возни со своим Nexus 7 и Galaxy S II. Кроме этого я не знаю.

Программы:

В моем Nexus 7 есть приложения Caustic , DC Comics и 20 Minute Meals , которые после сброса настроек моего Galaxy S II не устанавливаются на Galaxy S II.

В моем Galaxy S II есть эти приложения DriveDroid и Human Japanese , которые после сброса настроек моего Nexus 7 не устанавливаются на Nexus 7.

Приложения совместимы с обоими устройствами, поэтому несовместимость не может быть причиной того, что они не могут быть установлены на соответствующем другом устройстве.

Данные:

Что касается Wi-Fi и других данных, я не уверен, так как каждый раз, когда я устанавливал Wi-Fi на каждом устройстве во время первоначальной настройки Android. Что касается других учетных записей Google, которые у вас могут быть, похоже, они не копируются на каждое устройство, и то же самое относится к учетным записям Skype и GitHub на каждом устройстве.

Я сделал резервную копию, используя как встроенную резервную копию Google, так и резервную копию Helium, прежде чем стереть и установить пользовательское ПЗУ Carbon на Nexus 4 (со склада KitKat). Ожидал, что Google восстановит приложения, настройки и т. д., как это было раньше, когда я восстановил этот телефон, но без радости.

Пробовал и Helium, тоже без радости, даже при ручном восстановлении «Загрузка с ПК» - сказал «восстановлено», но данных Wi-Fi и приложений по-прежнему нет.

Запуск bmgr restore <xxx>полного восстановления и bmgr run, как подробно описано выше, запустил полное восстановление Google и сработал - спасение для меня!

Google мог бы приложить больше усилий, особенно если они хотят конкурировать с идеей Apple «просто работает»… Тем не менее, мне нравится взламываемость Android, несмотря на его подводные камни!