Нет ничего нового в том, что можно использовать несколько устройств Android с одной учетной записью Google . При первом включении нового устройства спрашивается, хочет ли он хранить свои данные в Google, который затем всегда синхронизирует «некоторые вещи» с серверами Google, в основном

• некоторые данные приложения (если приложения поддерживают это явно)
• Wi-Fi пароли
• закладки браузера
• список приложений, установленных из Google Play
• слова, добавленные в словарь, используемый экранной клавиатурой
• большинство ваших индивидуальных настроек

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

• Какую информацию резервная копия Google?
• Что именно синхронизируется с гуглом?
• Как Android синхронизирует профили WiFi?

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

Сделав резервную копию данных с нескольких устройств с использованием одной учетной записи:

• что произойдет с устройством с сбросом к заводским настройкам, используемым таким образом раньше? Будет ли оно признано, и будут ли восстановлены только те вещи, которые использовались на нем раньше?
  ^{(идентификация устройства может, например, происходить, например, через IMEI (но не через Android_ID, поскольку это может быть выполнено с заводским сбросом ) - и это может быть причиной поведения, описанного в ответе Налума )}
• что будет восстановлено на (новом / заводском сбросе) устройстве, которое вы впервые инициализируете с помощью этой учетной записи Google?
  ^{(если устройства будут идентифицироваться с помощью резервных копий в используемой учетной записи Google, это может вызвать специальное действие для «нового устройства», например, «восстановить все, устройство изменилось!» - или «восстановить все с более не подключенного устройства X, как это, вероятно, было заменено! "- но придерживайтесь" восстановить только то, что было на этом устройстве "в случае сброса к заводским настройкам)}

Дело в том, что если у вас есть несколько устройств, они часто используются для решения определенных проблем, поэтому вам не нужно все на всех устройствах. Поскольку я не видел способа выбрать данные для резервного копирования (например, чтобы исключить те «конфиденциальные данные», о которых нас предупреждали: пароли WiFi будут принадлежать к этой категории), я полагаю, что и при восстановлении выбора нет? Так как это обрабатывается?

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

Некоторые части, извлеченные из API bmgr

• Он предоставляет команды для
  запуска операций резервного копирования и восстановления [...] → похоже, что это способ запуска действий вручную, если «автоматизация» завершается неудачей
• Эти команды доступны через оболочку 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, - и может инициировать восстановление данных для них. Его нельзя использовать для запуска полного восстановления - по крайней мере, здесь это не задокументировано.

Еще немного информации о резервной копии 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.

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

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

Данные:

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

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

Пробовал и Helium, тоже не радость, даже с ручным восстановлением «PC Download» - сказал «восстановлено», но данных Wifi и приложений все еще нет.

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

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