Google Backup: несколько устройств, использующих одну учетную запись - что происходит при восстановлении?

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

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

Подробности можно найти в Google Dashboard . К таким вопросам относятся следующие вопросы:

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

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

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

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

52 голоса | спросил Izzy 24 MarpmSun, 24 Mar 2013 23:39:37 +04002013-03-24T23:39:37+04:0011 2013, 23:39:37

5 ответов


40

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

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

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

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

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

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

Источник

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

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

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

Не пытайтесь использовать его в оболочке на устройстве, кроме как : вам нужен системный уровень 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 - это кодовое имя для ; TF-101 относится к оригиналу . После того, как вы выяснили, какой набор вы хотите, вы можете восстановить приложение из этого набора, используя его токен:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

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

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

bmgr wipe com.shadowburst.showr

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

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

ответил Dan Hulme 19 J000000Friday13 2013, 03:52:30
7

На этот вопрос нет ответа, но может пролить свет на некоторые детали:

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

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

  • Android автоматически выполняет операцию восстановления, когда ваше приложение установлено, и существуют данные резервного копирования, связанные с пользователем.
    «Это может означать две вещи:
    • Если приложение поддерживает API резервного копирования Google, и пользователь имеет включенную резервную копию Google, доступные резервные данные будут автоматически восстановлены при установке. Хорошо, когда вы впервые устанавливаете приложение, используемое на одном устройстве, на второе устройство.
    • резервные копии связаны только с учетной записью Google, а не с устройством ( и существуют данные резервного копирования, связанные с пользователем ), или другой факт просто игнорировался как несущественный для этого особого случая ( «приложение установлено»)
  • Резервный транспорт - это клиентский компонент платформы резервного копирования Android, который настраивается производителем устройства и поставщиком услуг. Транспорт резервного копирования может отличаться от устройства к устройству > [...]
    â † 'это может объяснить ненадежность, когда дело касается разных устройств (или разных версий Android).
    (выделение)
  • Резервное копирование данных не гарантируется на всех устройствах на базе Android.
    (без комментариев)
  • Google предоставляет резервный транспорт с Android Backup Service для большинства Android-устройств, работающих под управлением Android 2.2 или выше.
    â † ', здесь у нас есть минимальная версия Android для Google Backup, доступная на всех: Froyo, AKA Android 2.2
  • Чтобы получить свой резервный ключ службы, зарегистрируйтесь в службе резервного копирования Android. [...]
    «каждое приложение должно иметь свой собственный ключ. Нет «почему», но есть хорошая предпосылка: изолировать резервные копии, чтобы ни одно приложение не могло читать резервные копии другого приложения (неправильный ключ, а также для резервного копирования другого пользователя: неправильная учетная запись).
  • При разработке приложения вы можете инициировать немедленную операцию резервного копирования из Backup Manager с помощью инструмента bmgr.
    â † 'похоже, что есть способ вручную запускать резервные копии? Пойдем в это позже. â † «
  • Когда пришло время восстановить данные приложения, диспетчер резервного копирования вызывает метод onRestore() вашего резервного агента резервного копирования.
    â † 'это снова подчеркивает первый элемент этого списка: сначала нужно установить приложение, затем их собственные реализации используются для восстановления его данных. Во второй раз: если приложение-восстановление завершится неудачей, не будет восстановления данных для неудавшихся приложений - пока вы не установите их вручную через Google Play. Затем, как показал первый пункт, данные должны быть автоматически восстановлены с помощью Google Backup в соответствии с объясненными условиями (должны были быть скопированы с ним, с той же учетной записью и т. Д.).
  • Резервное копирование других файлов
    «Простите, что я не цитирую (техническое) содержание этой главы, но вкратце: только файлы из внутреннего хранилища могут быть скопированы в соответствии с ним.

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

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

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

ответил Izzy 29 MarpmFri, 29 Mar 2013 23:44:59 +04002013-03-29T23:44:59+04:0011 2013, 23:44:59
6

Дополнительная информация о резервном копировании Google. Когда я высветил пользовательскую прошивку, он не восстановил приложения, как я ожидал. В настройках -> Резервное копирование & reset , он показывал «Резервное копирование в закрытый кеш-файл для отладки», а 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 (точно)
Затем он начал загрузку приложений.

ответил lapis 16 72014vEurope/Moscow11bEurope/MoscowSun, 16 Nov 2014 06:10:22 +0300 2014, 06:10:22
3

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

приложения:

В My Nexus 7 есть эти приложения Caustic , DC Comics и 20 минут еды , что после перезагрузки моей Galaxy S II не установлены на Galaxy S II.

My Galaxy S II имеет тезисы приложений DriveDroid и Человека-японца , что после заводской перезагрузки моего Nexus 7 не установлены на Nexus 7.

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

Данные:

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

ответил Nalum 26 MarpmTue, 26 Mar 2013 23:26:28 +04002013-03-26T23:26:28+04:0011 2013, 23:26:28
1

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

Пробовал гелий, а также не радость, даже с ручным восстановлением «Загрузка ПК» - сказал «восстановлен», но данные Wifi и приложения все еще не существуют.

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

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

ответил kaepora 12 MarpmWed, 12 Mar 2014 18:40:58 +04002014-03-12T18:40:58+04:0006 2014, 18:40:58

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132