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

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

Деталі можуть бути знайдені на інформаційній панелі Google . Відповідні питання, що стосуються цих питань, включають:

• Яку інформацію створює резервна копія 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-бітний шістнадцятковий номер зліва - це маркер . Вам знадобиться це за хвилину. Справа - це (відносно) доброзичлива назва пристрою, який володіє набором. Наприклад, манта - кодове ім'я для Nexus-10 ; TF-101 відноситься до оригінального трансформатора asus-eee-pad . Після того, як ви зрозуміли, який набір хочете, ви можете відновити додаток із цього набору, використовуючи його маркер:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

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

Нарешті, ви можете стерти дані програми з поточного набору:

bmgr wipe com.shadowburst.showr

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

Ви не можете змусити пристрій починати писати в інший набір, а також не можете витерти весь набір.

Далі - це далеко не відповідь на питання, але може пролити трохи інформації на деякі деталі:

Деякі фрагменти, витягнуті з API резервного копіювання

Хоча API орієнтований в основному на розробників, є кілька фактів, які ми можемо отримати для нашого випадку. У наведеному нижче списку курсив позначає цитати з документації API.

• Android автоматично виконує операцію відновлення, коли встановлено ваш додаток і існують резервні дані, пов’язані з користувачем.
  → це може означати дві речі:
  • якщо додаток підтримує API резервного копіювання Google, а користувач увімкнув резервну копію Google, наявні резервні дані автоматично будуть відновлені під час встановлення. Добре, що ви вперше встановите додаток, що використовується на одному пристрої, на другий пристрій.
  • резервні копії асоціюються лише з обліковим записом Google, а не з пристроєм ( і існують дані резервного копіювання, пов’язані з користувачем ) - або інший факт був просто проігнорований як неактуальний для цього особливого випадку ("додаток встановлено")
• Транспорт резервного копіювання - це клієнтська складова резервної системи Android, яку можна налаштувати виробником пристрою та постачальником послуг. Транспорт резервного копіювання може відрізнятися від пристрою до пристрою [...]
  → це може пояснити ненадійність, коли мова йде про різні пристрої (або різні версії Android).
  ^{(наголос мій)}
• Резервне копіювання даних не гарантується на всіх пристроях, що працюють на Android.
  (без коментарів)
• Google надає резервний транспорт із сервісом резервного копіювання Android для більшості пристроїв на базі ОС Android, на яких працює Android 2.2 або новішої версії.
  → тут у нас є мінімальна версія Android, необхідна для того, щоб взагалі була доступна резервна копія Google: Froyo, AKA Android 2.2
• Щоб отримати Ваш сервісний ключ резервного копіювання, зареєструйтесь для служби резервного копіювання Android. [...]
  → у кожного додатка має бути свій ключ. Немає опису "чому", але гарна здогадка: ізолювати резервні копії, щоб жоден додаток не міг прочитати резервні копії іншого додатка (неправильний ключ; як для резервних копій іншого користувача: неправильний обліковий запис)
• Під час розробки програми ви можете запустити негайну операцію резервного копіювання з диспетчера резервних копій за допомогою інструмента bmgr.
  → схоже, що існує спосіб вручну створити резервні копії? Давайте розберемося пізніше. ↓
• Коли настає час відновити дані вашої програми, диспетчер резервних копій викликає onRestore()метод вашого агента резервного копіювання .
  → це ще раз підкреслює перший пункт цього списку: спочатку додаток має бути встановлено, потім для відновлення його даних використовуються власні реалізації. По-друге: якщо не вдалося відновити додаток, для несправних програм не буде відновлення даних, поки ви не встановите їх вручну через Google Play. Потім, як показав перший елемент, дані повинні автоматично відновлюватися через резервну копію Google за пояснених умов (повинні бути резервні копії, той самий обліковий запис тощо)
• Створення резервних копій інших файлів
  → вибачте, я не цитую з (технічного) вмісту цієї глави, а коротко: відповідно до нього можна створити резервні копії лише файлів із внутрішнього сховища.

Деякі фрагменти, вилучені з 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 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 хвилинної їжі, які після заводського скидання мого 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 та резервної копії гелію перед тим, як стерти та встановити Carbon на замовлення ROM на Nexus 4 (зі складу KitKat). Очікував, що Google відновить програми, налаштування тощо, як це робилося раніше, коли я відновив цей телефон, але не радість.

Випробуваний гелій також не радіє, навіть якщо вручну "Завантажити ПК" відновлюється - сказано "відновлено", але даних Wi-Fi та додатків все ще немає.

Виконання bmgr restore <xxx>повного відновлення та, bmgr runяк описано вище, спричинило повне відновлення Google та запрацювало для мене частування - рятівник!

Google може докласти більше зусиль, особливо якщо вони хочуть конкурувати з ідеєю Apple "просто працює" ... Я все ж люблю руйнування Android, незважаючи на його підводні камені!