Нет ничего нового в том, что можно использовать несколько устройств Android с одной учетной записью Google . При первом включении нового устройства спрашивается, хочет ли он хранить свои данные в Google, который затем всегда синхронизирует «некоторые вещи» с серверами Google, в основном
- некоторые данные приложения (если приложения поддерживают это явно)
- Wi-Fi пароли
- закладки браузера
- список приложений, установленных из Google Play
- слова, добавленные в словарь, используемый экранной клавиатурой
- большинство ваших индивидуальных настроек
Подробности могут быть найдены в панели инструментов Google . Соответствующие вопросы, охватывающие эти вопросы, включают в себя:
- Какую информацию резервная копия Google?
- Что именно синхронизируется с гуглом?
- Как Android синхронизирует профили WiFi?
Разработчики API на Google Резервное копирование дает более глубокие знания о том , как резервное копирование материал должен работать (и несколько вопросов здесь показать , как на самом деле работает - то есть, иногда это делает, иногда лишь частично, а иногда и не на всех). Помимо надежности и того факта, что не все хотят, чтобы его личные данные находились в облаке (и даже упомянутая ссылка на API 2 предупреждает: Android не дает никаких гарантий относительно безопасности ваших данных при использовании резервного копирования. Вы всегда должны быть осторожны при использовании резервного копирования для хранения конфиденциальных данных). данные, такие как имена пользователей и пароли. ), мой главный вопрос:
Сделав резервную копию данных с нескольких устройств с использованием одной учетной записи:
- что произойдет с устройством с сбросом к заводским настройкам, используемым таким образом раньше? Будет ли оно признано, и будут ли восстановлены только те вещи, которые использовались на нем раньше?
(идентификация устройства может, например, происходить, например, через IMEI (но не через Android_ID, поскольку это может быть выполнено с заводским сбросом ) - и это может быть причиной поведения, описанного в ответе Налума ) - что будет восстановлено на (новом / заводском сбросе) устройстве, которое вы впервые инициализируете с помощью этой учетной записи Google?
(если устройства будут идентифицироваться с помощью резервных копий в используемой учетной записи Google, это может вызвать специальное действие для «нового устройства», например, «восстановить все, устройство изменилось!» - или «восстановить все с более не подключенного устройства X, как это, вероятно, было заменено! "- но придерживайтесь" восстановить только то, что было на этом устройстве "в случае сброса к заводским настройкам)
Дело в том, что если у вас есть несколько устройств, они часто используются для решения определенных проблем, поэтому вам не нужно все на всех устройствах. Поскольку я не видел способа выбрать данные для резервного копирования (например, чтобы исключить те «конфиденциальные данные», о которых нас предупреждали: пароли WiFi будут принадлежать к этой категории), я полагаю, что и при восстановлении выбора нет? Так как это обрабатывается?
Ответы:
Давайте поговорим о наборах, детка
Служба резервного копирования Android имеет концепцию, называемую набором : набор всех данных, сохраняемых с одного устройства (на одном транспорте , но это деталь). Каждый набор идентифицируется уникальной строкой, такой как IMEI на устройстве. При резервном копировании приложения (или списка установленных приложений) его резервные данные попадают в набор, связанный с устройством, с которого выполняется резервное копирование. Все наборы по-прежнему относятся к учетной записи пользователя Google. Если вы протрите свое устройство и продадите его кому-то другому, он не сможет получить доступ к набору этого устройства, если не сможет войти в вашу учетную запись Google.
Поведение по умолчанию
Когда приложение установлено или на устройстве восстановлен список приложений, система резервного копирования сначала ищет в наборе этого устройства данные резервного копирования для этого пакета. Если он не найдет ничего (либо потому, что это совершенно новое устройство без резервных копий данных, либо потому, что этот пакет никогда не устанавливался на это устройство), он расширит поиск на другие наборы. (Если есть выбор, он будет использовать последний набор, который использовался для полного восстановления устройства.)
Таким образом, когда вы настраиваете новое устройство, оно восстанавливает список приложений из резервной копии старого устройства и восстанавливает каждое приложение из резервной копии старого устройства. Если приложение установлено на одном устройстве и вы устанавливаете его на другом устройстве, приложение будет восстановлено с использованием данных со старого устройства. В любом случае данные теперь копируются в набор нового устройства, что означает, что данные резервного копирования с двух устройств теперь отдельно.
После восстановления заводских настроек устройства оно будет восстанавливаться из последней резервной копии этого устройства, если она есть, и, если это не удалось, из резервной копии какого-либо другого устройства, если таковое имеется, но с этого момента оно начнет создавать свой собственный набор. Вот почему два устройства Nalum не видят резервные копии приложений друг друга: каждое из них восстанавливает свои собственные последние резервные копии.
Источник
Этот механизм не имеет никакой пользовательской документации, так как он должен автоматически делать правильные вещи, но код доступен .
bmgr
: основное использованиеКак выяснил Иззи,
bmgr
инструмент дает вам некоторый контроль над этим процессом. Он предназначен для помощи программистам в тестировании и отладке интеграции резервного копирования в их приложениях. Вы можете использовать этот инструментadb shell
для запуска резервного копирования и восстановления выбранных пакетов, удаления данных из резервных копий пакетов и даже восстановления всего устройства.Не пытайтесь использовать его в оболочке на устройстве, кроме как root : вам нужен системный уровень,
android.permission.BACKUP
чтобы делать с ним что-нибудь интересное.Вы можете немедленно обновить приложение из резервной копии приложения:
(или каково бы ни было имя пакета приложения). Обычно в этом нет необходимости, поскольку приложения запрашивают свои собственные резервные копии при изменении данных, но это позволяет вам работать с плохо написанным приложением. Чтобы восстановить один пакет из резервных копий данных, он выберет по умолчанию:
но опять же, это будет делать только то, что устройство будет делать самостоятельно, поэтому вам не нужно его использовать. Обратите также внимание, что устройство уже должно быть установлено, чтобы сделать эту работу.
Больше контроля
Теперь о вещах, которые система резервного копирования не будет делать при включении. Чтобы увидеть, какие наборы резервных копий данных доступны:
и вы получите некоторый вывод, как это:
64-битное шестнадцатеричное число слева является токеном . Вам понадобится это через минуту. Вещи справа - это (относительно) понятное название для устройства, которому принадлежит набор. Например, manta - это кодовое название для nexus-10 ; TF-101 относится к оригинальному asus-eee-pad-transformer . После того, как вы выяснили, какой набор вам нужен, вы можете восстановить приложение из этого набора, используя его токен:
Вы можете добавить больше имен пакетов в конец команды, чтобы восстановить несколько пакетов одновременно, или вы можете не указывать имя пакета (только токен), чтобы восстановить каждое приложение с данными в этом наборе (то есть оно выполняет полную систему). восстановить).
Наконец, вы можете стереть данные приложения из текущего набора:
Это заставит его следующую операцию резервного копирования начать с нуля. Это может быть полезно после удаления приложения, если ошибка в приложении повредила данные резервной копии и вы не хотите, чтобы она была восстановлена.
Вы не можете заставить устройство начать запись в другой набор, и при этом вы не можете стереть весь набор.
источник
Следующее является далеко не ответом на этот вопрос, но может пролить свет на некоторые детали:
Некоторые фрагменты извлечены из API резервного копирования
Хотя API в основном ориентирован на разработчиков, есть несколько фактов, которые мы могли бы извлечь для нашего случая. В следующем списке курсивом отмечены кавычки из документации API.
→ это может означать две вещи:
→ это может объяснить ненадежность, когда речь идет о разных устройствах (или разных версиях Android).
(акцент мой)
(без комментариев)
→ здесь у нас есть минимальная версия Android, необходимая для резервного копирования Google: Froyo, AKA Android 2.2
→ у каждого приложения должен быть свой ключ. Здесь нет описания «почему», но есть хорошая догадка: изолировать резервные копии, чтобы никакое приложение не могло прочитать резервные копии другого приложения (неправильный ключ; как для резервных копий другого пользователя: неправильный аккаунт)
→ Похоже, есть способ запустить резервное копирование вручную? Давайте углубимся в это позже. ↓
onRestore()
метод вашего агента резервного копирования .→ это еще раз подчеркивает первый элемент этого списка: сначала приложение должно быть установлено, а затем его собственные реализации используются для восстановления его данных. С другой стороны: если восстановление приложения завершится неудачно, восстановление данных после сбоя приложений не будет, пока вы не установите их вручную через Google Play. Затем, как показал первый элемент, данные должны автоматически восстанавливаться через Google Backup в соответствии с описанными условиями (должны быть созданы резервные копии с той же учетной записью и т. Д.)
→ простите, я не цитирую (техническое) содержание этой главы, но вкратце: только файлы из внутреннего хранилища могут быть скопированы в соответствии с этим.
Некоторые части, извлеченные из API bmgr
запуска операций резервного копирования и восстановления [...] → похоже, что это способ запуска действий вручную, если «автоматизация» завершается неудачей
→ это не нуждается в объяснении :)
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, несмотря на все его ловушки!
источник