Содержание статьи
В прошлом номере мы рассмотрели образцово-показательную реализацию резервного копирования данных на примере устройств Apple iOS. А как обстоят дела на других платформах? Сегодня мы изучим главного антагониста iOS — платформу Google Android и выясним, как сохранить данные с рутом и без, каким образом восстановить данные из резервной копии и как расковырять чужой локальный или облачный бэкап.
Сразу определимся с терминологией. В этой статье мы будем писать исключительно про ту разновидность Android, которая поставляется с сервисами Google. Сторонние прошивки нам не особо интересны: количество их пользователей минимально, при этом создавать и восстанавливать резервные копии данных при прошивке очередного «кастома» эти пользователи отлично умеют. Нет, сегодня мы поговорим об остальных 99% пользователей, которые хотят открыть коробку, ввести логин и пароль от учетной записи и получить что-то работоспособное.
Статья основана на исследовании, в ходе которого мы использовали порядка десяти устройств от ASUS, Google Nexus, LG, Motorola, Oppo и Sony. Тестировались как восстановление данных на то же устройство после сброса к заводским настройкам, так и миграция данных на другое устройство.
Софт от производителя
Производители устройств часто выпускают фирменные утилиты для резервного копирования данных. Некоторые (например, Sony) предлагают установить софт на компьютер, другие (ASUS, LG) встраивают соответствующую функциональность в прошивку. Samsung предоставляет возможность создавать резервные копии в собственном облаке. Короче говоря, разброд и шатание.
Объединяет решения от производителей две вещи. Во-первых, создаваемая резервная копия будет достаточно полной, что позволяет полноценно восстановить данные после сброса устройства, обновления прошивки или апгрейда. Во-вторых, восстановить бэкап от телефона Sony на планшет от ASUS (и наоборот) тебе не удастся: восстанавливать нужно тем же софтом на модель того же производителя.
Впрочем, если ты планируешь пользоваться устройством долгое время, почему бы и не создать резервную копию? Да, это не всегда удобно, и да, это никак не автоматизируется, но ведь возможность-то есть. А если с твоим телефоном что-то случится и если ты решишь заменить его на устройство от того же производителя, то тебе, может быть, даже удастся восстановить на него данные. Уверенности, разумеется, никакой: производитель гарантирует успешное восстановление только на устройство той же модели, с которой были скопированы данные.
Резервное копирование: версия Google
Устройства под управлением Android — это пестрый зоопарк платформ, архитектур, производителей, аппаратных и программных конфигураций. Сложно сделать так, чтобы резервные копии, созданные с телефона одного производителя, не дестабилизировали работу смартфона на совершенно другой архитектуре. Вероятно, это и служит основной причиной того, с какой скоростью Google разрабатывает механизм резервного копирования.
Если не считать существовавших с первой версии Android механизмов синхронизации контактов, календаря и других приложений Google с облаком, то полноценный механизм резервного копирования приложений и настроек появился только в Android 4.3. Он был доступен лишь в режиме разработки и только через Android Debug Bridge. Иными словами, для «обычных» пользователей его не существовало.
В какой-то момент Google начала синхронизировать некоторые данные с облаком. При восстановлении устройства предлагалось восстановить и данные (ярлыки, приложения и настройки) с одного из предыдущих устройств. Эта функциональность, строго говоря, не является частью Android, а реализована в проприетарных сервисах Google.
С Android 6.0 облачное резервное копирование настроек официально стало частью операционной системы. Теперь разработчику приложения достаточно включить в manifest приложения флажок, разрешающий резервное копирование данных, и система будет автоматически копировать их в облако. Разумеется, облако это от Google, а данные привязаны к учетной записи Google Account, так что пользователи AOSP-сборок без сервисов Google остаются в стороне. Что ж, давай рассмотрим эти механизмы подробнее. Нарушив хронологию, начнем с наиболее современного и интересного механизма, представленного в Android 6.0.
Android 6.0: мы сделали это!
Начиная с Android 6.0 система автоматически сохраняет настройки системы и приложений в Google Drive пользователя. Решил обновить устройство? Твой новый смартфон автоматически подхватит настройки из облака, сам установит приложения, которыми ты пользовался на старом устройстве, и автоматически настроит их привычным для тебя образом. Почти как у Apple! И так оно все и работало в предварительных сборках Android M до самого релиза.
А в официальной версии Android 6.0 разработчики резко сменили пластинку. Если в предварительных сборках автоматическое резервное копирование работало для всех приложений, авторы которых не заблокировали эту возможность в явном виде (флаг opt-out в manifest), то в официальной версии системы резервные копии создаются только для приложений, авторы которых в явном виде затребовали сервис (opt-in через manifest) и прописали поддержку Android 6.0 (target API level 23).
Как ты думаешь, много ли разработчиков воспользовались этой возможностью? В замечательной статье Android 6.0 has a great auto backup system that no one is using (yet) журналисты Ars Technica подробно рассмотрели, какие приложения используют, а какие не используют встроенный в Android 6.0 механизм резервного копирования.
Результаты оказались... неожиданными. В первую очередь встроенным механизмом резервного копирования НЕ ПОЛЬЗУЮТСЯ приложения Google. Да-да, разработчик этой великолепной системы решил обойтись без нее. Восстанавливаются базовые настройки системы, будильники, «тихий режим», но данные приложений Google — нет. А вот клиенты социальных сетей, почтовые клиенты, игры и прочие популярные приложения не спешат добавлять поддержку. Разумеется, ситуация будет меняться со временем, но пока вот так. После сброса редакционного Nexus 6 и восстановления из облака произошло следующее:
- восстановились все приложения. При этом они были установлены из Google Play, то есть восстанавливались всегда последние версии;
- восстановилась часть настроек: языки встроенной клавиатуры, настройки «тихого режима», будильники;
- не восстановилась история звонков и СМС;
- не восстановились настройки Facebook;
- не восстановились данные большинства приложений (например, gReader Pro пришлось настраивать заново).
Иными словами, система установила все ранее установленные приложения, но не восстановила данные подавляющего большинства из них. Впрочем, контакты и email подхватились из облака, доступ к фотографиям — тоже. А настроить заново пару десятков приложений — нам не привыкать. Более подробно о работе Android Backup Service можно прочитать в справке Google.
Можно ли извлечь данные из облака?
Если Google может сохранить данные в облако, то мы можем их извлечь, не правда ли? Давай посмотрим, что можно сделать.
Во-первых, точно так же, как и в описанном в предыдущем номере примере скачивания данных из iCloud, нужны логин и пароль пользователя к учетной записи Google. Это не все; если включена двухфакторная аутентификация (а ее активируют все чаще), потребуется и одноразовый код, который будет генерироваться приложением Google Authenticator, Microsoft Authenticator, FreeOTP или любым из множества сторонних (работают они по единому принципу, и различается только криптографический код инициализации, который выдается пользователю в виде цветного QR-кода).
Еще нам потребуется соответствующий софт (можно обойтись и без него — об этом ниже). В качестве софта мы использовали Elcomsoft Cloud eXplorer. Запускаем приложение, авторизуемся в учетной записи Google, выбираем данные для скачивания:
Скачалось? Наслаждаемся:
Количество информации, которую собирает Google, честно говоря, шокирует. Да, абстрактно мы знаем, что за нами следят. Знаем, что тщательно сохраняется каждая страничка, которую мы посещаем, каждая закладка в браузере (разумеется, для нашего же удобства — синхронизация!). Само собой, сохраняется каждый поисковый запрос, адресованный «Корпорации добра» (ты уже понял, что искать в интернете рецепт создания ядреной бондбы — не лучшая идея?):
Доступен список устройств, установленные на них приложения и собственно данные приложений:
Конечно, есть доступ к фотографиям (привет, iCloud!):
Для нашего же удобства сохраняется подробнейшая история перемещений:
Неплохо попутешествовал! А вот то же самое в текстовом виде:
В общем, просто масса всего интересного. Если честно, в учетной записи Google можно найти гораздо больше всего, чем когда-либо осмеливались сохранить решения от Apple.
Откуда и каким образом извлекаются все эти данные? А вот это, пожалуй, самое интересное. «Корпорация добра» придерживается политики максимальной информационной открытости. Ты всегда можешь просмотреть или скачать всю информацию, которую корпорация собрала о тебе. Ты можешь удалить любые данные, и для этого не требуется уничтожать свою учетную запись. Наконец, ты можешь отключить сбор отдельных типов данных (например, настроить свой телефон таким образом, что информация о твоем местоположении не будет отсылаться в Google).
Нас же в этом контексте интересует тот пункт, согласно которому ты вправе скачать всю информацию, собранную о тебе Google. Официальный способ сделать это — через сервис Google Takeout. Здесь можно выбрать, какие типы данных мы хотим скачать:
Выбранные данные будут запакованы в файл и предоставлены в виде архива:
Как видишь, ничего сложного. В чем подвох? Зачем нужен Elcomsoft Cloud eXplorer? Не проще ли скачать данные непосредственно из Google Takeout?
Подвоха как такового, в общем-то, нет. И данные скачать можно. Небольшая проблема возникает с анализом полученной информации. Для хранения и экспорта данных Google использует массу разнообразных форматов (в основном — открытых). К примеру, данные о своих перемещениях ты получишь в виде файла в формате JSON — делай с ним что хочешь, Google тебе не помощник. Не помощник он и спецслужбам: согласно официальной позиции компании, Google подчиняется закону и передает данные в открытом виде и в стандартном формате... что с ними будут делать дальше — ни малейшим образом не забота компании. А вот сам факт выдачи информации спецслужбам Google запишет, сохранит и опубликует.
Еще один момент. При скачивании через сервис Google Takeout пользователю обязательно придет уведомление: такие-то данные были скачаны с такого-то IP. Если тебе это не нужно, обращайся к сторонним инструментам: их использование не вызывает у Google тревоги. И на закуску — самое интересное. Google Takeout по какой-то причине не дает скачать синхронизированные в Chrome пароли. А Elcomsoft Cloud eXplorer извлекает их без особых проблем:
Магия? Нет, Google предоставляет доступ и к этой информации. Все, что для этого нужно, — получить доступ к синхронизированным данным браузера Chrome, после чего они скачаются в виде XML-файла. Веб-интерфейс для просмотра синхронизированных паролей доступен здесь.
Резервное копирование через ADB
Начиная с Android 4.3 в системе появился штатный способ создания резервной копии через интерфейс Android Debug Bridge (ADB). Для создания резервной копии нужно использовать примерно такую команду:
adb backup -apk -shared -system -all -f C:\backup.abПочему «примерно»? Да в силу все того же «зоопарка» устройств. Мы протестировали большое количество устройств от разных производителей, работающих под управлением разных версий Android от 4.4 до 6.0.1 включительно. На каких-то устройствах команда сработала в таком виде, на других указание ключей -system или -shared приводило к созданию пустого файла, а третьи отказывались воспринимать ключ -all. Какой-либо логики в поведении команды adb мы уловить не смогли; точно сказать можно одно: от версии Android ее поведение зависит мало. Скорее зависимость здесь от настроек, заданных конкретным производителем.
Например, на редакционном Nexus 6 под управлением Android 6.0.1 прошла следующая команда:
adb backup -all -f c:\nexus6.abА вот опция -noapk «сломала» бэкап: был создан пустой файл. А еще adb backup может не работать, если включено шифрование раздела данных. Напомним, что шифрование включается по умолчанию на устройствах линейки Nexus, а также (по требованию Google) на всех устройствах, которые выходят с предустановленным Android 6 и оснащены 64-разрядными процессорами.
Еще один момент. Adb backup спроектирован таким образом, чтобы резервную копию, созданную на одном устройстве, можно было без проблем восстановить на другом. И ключевое слово здесь вовсе не «восстановить», а «без проблем»: восстановленное устройство должно работать и не должно глючить. Соответственно, сохраняются и восстанавливаются только те данные и настройки, которые точно не навредят стабильной работе даже тогда, когда данные переносятся с 32-битного смартфона с чипсетом MediaTek на 64-разрядный планшет с Intel Atom.
Восстановить данные из резервной копии будет несложно с помощью команды adb restore.
Что же попадает в такие резервные копии? И снова ответ зависит от производителя устройства. К примеру, в смартфонах Sony контакты, журнал звонков и СМС в резервные копии ADB не попадает, а телефоны Samsung эти данные сохраняют. То же самое относится к настройкам устройства (которые зачастую уникальны для конкретного производителя) и данным системных приложений.
В резервную копию точно попадает список установленных приложений. Извлекаются и сохраняются APK-файлы (если во время создания копии была указана соответствующая опция). А вот данные приложений могут сохраняться, а могут и нет: зависит это от разработчиков, которые разрешают или не разрешают резервное копирование в manifest-файле приложения.
С практической точки зрения нам не удалось извлечь большой пользы из таких резервных копий. При восстановлении через adb restore все равно приходится авторизоваться в Gmail, Facebook и прочих клиентах почты и социальных сетей. Не сохранились настройки FBReader и Nova Launcher (у которого, к слову, есть собственный механизм создания резервных копий). А что сохранилось? С трудом припоминается, что на некоторых аппаратах удалось восстановить журнал звонков и архив СМС.
Встроенным в Android механизмом резервного копирования пользуются и некоторые сторонние приложения. Им несть числа, так что рассматривать все мы не будем. Принцип работы всех подобных программ схож, и различаются они только добавленными возможностями. Самая популярная программа такого типа — Helium AppSync and Backup от известной команды разработчиков ClockworkMod (кастомное рекавери CWM — их разработка).
Что внутри?
Резервные копии, создаваемые через ADB, — вещь достаточно простая. На выходе — архив, содержащий данные приложений (в зависимости от настроек — и собственно .apk). Они сохраняются в том виде, в котором их хранит само приложение. Как правило, приложения используют формат SQLite, реже — XML, еще реже — двоичные данные в собственном формате.
Для анализа SQLite придумано столько инструментов, что для самого краткого обзора потребовалась бы отдельная статья. Скажу лишь, что с помощью таких инструментов можно вытащить удаленные записи. Пример? Пожалуйста. Если тебе повезло и производитель твоего телефона разрешил копировать журнал звонков и СМС, то ты сможешь восстановить сообщения и звонки, которые были удалены пользователем.
Кастомные recovery и бэкапы Nandroid
Рассказывая о системе резервного копирования Android, нельзя не упомянуть такое явление, как резервные копии Nandroid. Термин образовался от слов NAND (тип флеш-памяти) и Android, и используется чаще всего в контексте создания копии всего пользовательского (и, зачастую, системного) раздела целиком с использованием кастомного рекавери (чаще всего CWM или TWRP). Переносимость резервных копий Nandroid ограничена. Их рекомендуется восстанавливать на то же устройство, с которого они были сделаны, и желательно на ту же прошивку.
Что внутри?
Резервные копии Nandroid — штука достаточно абстрактная. У каждого рекавери этот формат свой. Более того, форматы могут отличаться в зависимости от устройства (напомню: кастомное рекавери — это, по сути, отдельная операционная система со своими особенностями для каждой поддерживаемой модели).
Что же мы получаем? Чаще всего на выходе — образ файловой системы (вкупе с оригинальной файловой системой, которая была использована на конкретном устройстве). Анализ простой: монтируем образ (потребуется драйвер соответствующей файловой системы) и бродим по файловой системе.
В некоторых случаях нам выдают набор ZIP-архивов с данными приложений. Тут тоже все просто: заходим в архив и смотрим; формат данных такой же, как в случае с adb backup, но сам набор данных гораздо полнее. Иногда создается один-единственный архив с набором файлов внутри. Нам попадались как простые .zip, так и .tar.gz (расширение может не совпадать).
Общая особенность бэкапов Nandroid в том, что ни одно протестированное нами кастомное рекавери (а мы тестировали десятки вариантов) не создает полный образ раздела с данными. Под «полным» образом мы понимаем образ, который содержит как оригинальную файловую систему, так и незанятые блоки — свободное место. Анализ свободных блоков позволил бы провести сканирование на предмет поиска удаленных файлов. К сожалению, не выйдет. Если требуется именно это, тебе придется использовать другие методы. (В скобках замечу, что образ системного раздела большинством рекавери создается целиком, со всеми «потрохами».)
Titanium Backup
Несколько особняком стоит приложение Titanium Backup — самая популярная программа для создания резервных копий, доступная в Google Play. С ее помощью нам удалось создать резервную копию данных всех установленных приложений (включая .apk), после чего успешно восстановить их на новое устройство. Обрати внимание: Titanium копирует двоичные данные из песочниц приложений, поэтому крайне не рекомендуем с его помощью переносить данные системных приложений Android. При восстановлении их на другое устройство система может работать нестабильно.
Заключение
Сегодня мы изучили часть механизмов резервного копирования, доступных в устройствах под управлением Android. Фрагментация платформы не позволяет рассмотреть все существующие способы и приложения, призванные облегчить резервное копирование и миграцию данных, но даже те, что были описаны, демонстрируют довольно жесткие ограничения как по совместимости, так и по полноте копируемых данных.
В целом наш вывод таков. Пользуешься «стоковым» Android? Включай облачную синхронизацию контактов и фотографий. Облачное резервное копирование может частично восстановить ранее установленные приложения, а если сильно повезет, то в отдельных приложениях могут частично восстановиться и какие-нибудь данные. Если на устройстве, с которого создавалась и на которое была восстановлена резервная копия, стоит Android 6.0 или выше, то из облака восстановится больше данных в сравнении с более старыми версиями Android.
Встроенный механизм adb backup может помочь восстановить часть данных пользователям более старых версий Android. Сторонние приложения эффективны только при наличии прав root. Использование кастомного рекавери и создание Nandroid backup решит большую часть проблем, но доступен этот режим мизерному числу пользователей.
В результате система резервного копирования в Android получает от нас оценку «лучше, чем ничего». Превзойти Android по неудобству не смог никто: даже в старенькой Windows Phone 8 резервное копирование работает гораздо удачнее.
А как обстоят дела с резервным копированием у аутсайдеров рынка — телефонов под управлением мобильной версии Windows и BlackBerry 10? Об этом — в следующем номере!
