В прошлом месяце мы рассмотрели отличную реализацию резервного копирования данных на примере устройств Apple iOS. А как обстоят дела на других платформах? Сегодня мы рассмотрим главного антагониста iOS – платформу Google Android. Как сохранить данные с root-доступом и без? Каким образом восстановить данные из резервной копии, можно ли, а главное – нужно ли это делать?

Резервные копии: Google Android

Определимся с терминологией. В этой статье мы будем писать исключительно про ту разновидность Android, которая поставляется с сервисами Google. Открытый исходный код, AOSP, сторонние прошивки нас сейчас не интересуют: количество их пользователей минимально, при этом создавать и восстанавливать резервные копии данных при прошивке очередного «кастома» эти пользователи отлично умеют. Тема сегодняшней беседы касается остальных 99% пользователей, которые хотят открыть коробку, ввести логин и пароль от учётной записи и получить что-то работоспособное.

В данном исследовании мы использовали порядка десятка устройств от ASUS, Google Nexus и Pixel, LG, Motorola, Sony. Тестировалось как восстановление данных на то же устройство после сброса к заводским настройкам, так и миграция данных на другое устройство.

Итак, какие же механизмы резервного копирования доступны в Android? От пестроты доступных решений просто глаза разбегаются. Начнём, пожалуй, с приложений, которые поставляются производителями устройств.

Решения от производителя

Производители устройств часто предлагают фирменные утилиты для резервного копирования данных. Некоторые (например, SONY) предлагают установить приложение на компьютер, другие (ASUS, LG, Xiaomi) встраивают соответствующий функционал в прошивку. Samsung предлагает создавать резервные копии в собственном «облаке».

Объединяет решения от производителей две вещи. Во-первых, создаваемая резервная копия будет достаточно полной, что позволяет полноценно восстановить данные после сброса устройства, обновления прошивки или апгрейда. Во-вторых, восстановить бэкап от телефона SONY на планшет от ASUS (и наоборот) не удастся: восстанавливать нужно тем же софтом на модель того же производителя. А вот резервные копии Xiaomi будут совместимы с большинством устройств, работающих под управлением семейства прошивок MIUI. Обратная сторона медали – полное отсутствие даже в международных версиях MIUI стандартного «облачного» резервного копирования в Google Drive, которое предлагает Google в Android 6.0, 7.x и 8.0.

Впрочем, если устройство планируется использовать долгое время, почему бы и не создать резервную копию? Да, это не всегда удобно, и да, это никак не автоматизируется, но ведь возможность-то есть? А если с телефоном что-то случится, и если пользователь решит заменить его на устройство от того же производителя, то его, возможно, получится восстановить из резервной копии. Гарантии, разумеется, никакой: производитель гарантирует успешное восстановление только на устройство то самой модели, с которой были скопированы данные.

Резервное копирование: версия Google

Устройства под управлением Android – это разнообразие платформ, архитектур, производителей, аппаратных и программных конфигураций. Сложно сделать так, чтобы резервные копии, созданные с телефона одного производителя, не дестабилизировали работу смартфона, работающего на совершенно другой архитектуре. Вероятно, это и является основной причиной того, с какой скоростью Google внедряет механизмы резервного копирования.

Исторически механизм резервного копирования появилось в Android 4.3. Он был доступен только в режиме разработки и только через adb — Android Debug Bridge. Иными словами, для «обычных» пользователей его не существовало.

В какой-то момент Google начал синхронизировать некоторые данные с «облаком». Теперь при восстановлении устройства предлагалось восстановить и данные (ярлыки, приложения и настройки) с одного из предыдущих устройств. Этот функционал, строго говоря, не является частью Android, а реализован в проприетарных сервисах Google.

Начиная с Android 6.0 «облачное» резервное копирование официально стало частью операционной системы. Теперь достаточно разработчику включить в manifest приложения флажок, разрешающий резервное копирование данных, и система будет автоматически копировать их в «облако». Разумеется, «облако» это от Google, а данные привязаны к учётной записи Google Account, так что пользователи AOSP-сборок без сервисов Google остаются в стороне.

Рассмотрим эти механизмы подробнее. Нарушив хронологию, начнём с наиболее современного и интересного механизма, представленного в Android 6.0 и получившего логическое развитие в версиях Android 7 и 8.

Android 6.0: мы сделали это!

Среди нововведений в Android 6.0 числится возможность автоматического резервного копирования данных приложений на уровне системы. Теперь приложениям нет необходимости создавать собственные резервные копии. Для автоматического создания резервных копий данных в Google Drive разработчику приложения достаточно указать соответствующий флажок в manifest.

В теории всё выглядит более чем интересно. После сброса к заводским настройкам или покупки нового устройства, смартфон автоматически подхватит настройки из «облака», сам установит приложения, которые работали на старом устройстве, и автоматически настроит их, восстановив сохранённые данные. Почти как в Apple! Именно так работала система в предварительных сборках Android M до самого релиза.

В официальной версии Android 6.0 разработчики Google решили проявить осторожность. Если в предварительных сборках автоматическое резервное копирование работало для всех приложений, авторы которых не заблокировали эту возможность в явном виде (флаг opt-out в manifest), то в официальной версии системы резервные копии создаются только для приложений, авторы которых в явном виде затребовали сервис (opt-in через manifest) и прописали поддержку Android 6.0 (targeting API level 23).

Много ли разработчиков воспользовались этой возможностью? На момент выхода Android 6.0 – ожидаемо немного. Да и через полгода после – тоже. В статье Android 6.0 has a great auto backup system that no one is using (yet) журналисты подробно рассмотрели, какие приложения используют, а какие – не используют встроенный в Android 6.0 механизм резервного копирования.

Результаты оказались неожиданными. В первую очередь встроенным механизмом резервного копирования НЕ ПОЛЬЗУЮТСЯ приложения Google. Сам разработчик новой системы резервного копирования решил обойтись без неё. Восстанавливаются базовые настройки системы, будильники, «тихий режим», но данные приложений Google – не восстанавливаются; их приходится настраивать заново. И крупные приложения социальных сетей, почтовые клиенты, игры и прочие популярные приложения не спешат добавлять поддержку. Разумеется, ситуация медленно меняется со временем. После сброса Nexus 5x и восстановления из «облака» произошло следующее:

— восстановились все приложения. При этом они были установлены из Google Play, т.е. восстанавливались всегда последние версии

— восстановилась часть настроек: языки встроенной клавиатуры, настройки «тихого режима», будильники.

— не восстановилась история звонков и SMS. (Об этом – чуть ниже).

— не восстановились настройки Facebook.

— данные части приложений были восстановлены, другой части — нет.

Более подробно о работе Android Backup Service можно прочитать на странице Google

Android 8.0

Пропустим Android 7.x, который мало отличался с точки зрения резервного копирования от 6-й версии системы, и рассмотрим нововведения в Android 8.

В восьмой версии «зелёного робота» добавилось резервное копирование текстовых сообщений SMS. Более того; резервное копирование SMS в «облако» Google Drive было реализовано значительно раньше, ещё в Android 7.x, но – исключительно для устройств Google Pixel. А начиная с Android 8.0 резервное копирование SMS стало доступно всем пользователям системы.

Резервное копирование журнала звонков

В некоторых устройствах доступно резервное копирование журнала звонков. Похоже, Google тестирует эту систему начиная с ранних версий Android – нам удалось пронаблюдать резервное копирование и восстановление журнала звонков даже на смартфонах с установленным Android 6.0. Несмотря на это, резервное копирование журнала звонков долгое время работало нестабильно. Похоже, окончательно отладить механизм разработчикам Google удалось лишь с выходом Android 8, причём заработал он одновременно на всех устройствах, включая смартфоны с Android 7 и 6 на борту.

Извлечение данных из «облака»

Если Google может сохранить данные в «облако», то их можно попробовать извлечь.

Прежде всего, точно так же, как и для скачивания данных из iCloud, нам потребуются логин и пароль пользователя к учётной записи Google. Если в учётной записи включена двухфакторная аутентификация (а её активируют всё чаще), то потребуется и одноразовый код, который будет генерироваться приложением Google Authenticator, Microsoft Authenticator или любым из множества сторонних (работают они по единому принципу, и различается только криптографический код инициализации, который выдаётся пользователю в виде цветного QR-кода).

Для извлечения данных используется Elcomsoft Cloud Explorer

Запускаем продукт, авторизуемся в учётной записи Google, выбираем категории данных для скачивания:

После завершения процесса получаем доступ к информации из учётной записи пользователя:

Количество информации, которую собирает Google, подавляет и шокирует. Да, абстрактно нам известно, что Google собирает данные с устройств под управлением Android. Знаем, что сохраняется каждая открытая веб-страница, каждая закладка в браузере и каждый поисковый запрос, адресованный Корпорации Добра (искать рецепт изготовления ядерной бомбы в домашних условиях – не лучшая идея.)

Доступен список устройств, установленные на них приложения и собственно данные приложений:

Разумеется, есть доступ к фотографиям (привет, iCloud!):

Сохраняется подробнейшая история перемещений:

А вот то же самое в текстовом виде:

Доступна масса интереснейших данных. В учётной записи Google можно найти гораздо больше всего, чем когда-либо осмеливались сохранить решения от Apple.

Откуда и каким образом извлекаются все эти данные? А вот это, пожалуй, самое интересное. Google придерживается политики максимальной информационной открытости. Пользователь в любой момент может просмотреть или скачать всю информацию, которую о нём корпорация собрала. Любые данные можно удалить, и для этого не требуется уничтожать свою учётную запись. Наконец, можно отключить сбор отдельных типов данных (например, можно настроить телефон таким образом, что информация о его местоположении не будет отсылаться в Google).

Скачать информацию из учётной записи можно через сервис Google Takeout: https://takeout.google.com/

Здесь можно выбрать, какие типы данных мы хотим скачать:

Выбранные данные будут запакованы в файл и предоставлены в виде архива:

В чём подвох? Зачем нужен Elcomsoft Cloud Explorer, если есть Google Takeout?

Помимо того, что Google Takeout выдаёт не все данные (к примеру, невозможно скачать сообщения SMS), проблема возникает и с анализом полученной информации. Для хранения и экспорта данных Google использует массу разнообразных форматов (в основном – открытых). К примеру, данные о перемещениях выдаются в виде файла в формате JSON, а в его анализе Google не помощник. Не помощник он и спецслужбам: согласно официальной позиции компании, Google подчиняется закону и передаёт данные в открытом виде и в стандартном формате… что с ними будут делать дальше – компанию не беспокоит. А вот сам факт выдачи информации спецслужбам Google запишет, сохранит и опубликует.

Ещё один момент. При скачивании через сервис Google Takeout пользователю обязательно придёт уведомление, которое предупредит, что такие-то данные были скачаны с такого-то IP. Использование Elcomsoft Cloud Explorer значительно уменьшает вероятность такого уведомления.

И последнее. Google Takeout по какой-то причине не разрешает скачивать синхронизированные в Chrome пароли. А Elcomsoft Cloud Explorer извлекает их без особых проблем:

Вообще говоря, Google предоставляет доступ и к этой информации, но пользоваться штатными средствами чрезвычайно неудобно. С помощью самого Google пароли доступны по одному через сайт https://passwords.google.com/

В заключение отметим, что использование сторонних инструментов для скачивания и анализа данных из учётной записи Google – это не только удобство, но и полнота извлечённых данных, и более «чистое» извлечение, оставляющее меньше следов в учётной записи пользователя.

Резервное копирование через ADB

Начиная с Android 4.3 в системе появился штатный способ создания резервной копии через интерфейс Android Debug Bridge (ADB). Для этого потребуется скачать набор «minimal ADB», состоящий из файлов adb.exe, fastboot.exe и требуемых библиотек (установка не требуется). Кроме того, нужно будет скачать и установить драйверы ADB для устройства. Как правило, драйверы одни и те же для устройств, работающих под управлением определённых наборов системной логики. К примеру, драйверы ADB от Qualcomm универсальны и подходят ко всем устройствам на чипсетах Snapdragon. Будем считать, что режим USB debugging уже активирован, а компьютер – авторизован.

Итак, для создания резервной копии нужно использовать приблизительно такую команду:

adb backup -apk -shared -system -all -f C:\fullpath\backup.ab

Почему «приблизительно»? В силу всё того же разнообразия устройств и прошивок. Мы протестировали большое количество устройств от разных производителей, работающих под управлением разных версий Android от 4.4 до 8.0 включительно. На каких-то устройствах команда сработала в указанном виде, на каких-то указание ключей -system или -shared приводило к созданию пустого файла, а какие-то отказывались воспринимать ключ -all. Какой-либо логики в поведении команды adb мы уловить не смогли; точно сказать можно одно: от версии Android её поведение зависит мало. Скорее, зависимость здесь от настроек, заданных конкретным производителем.

Например, на Nexus 5x под управлением Android 7.1.1 прошла следующая команда:

adb backup –all –f c:\temp\nexus.ab

А вот опция -noapk «сломала» резервное копирование: был создан пустой файл.

А ещё ADB backup может не работать, если включено шифрование раздела данных. Напомним, что шифрование включается по умолчанию на устройствах линейки Nexus, а также (по требованию Google) на всех устройствах, которые выходят с предустановленным Android 6 и оснащены 64-разрядными процессорами.

Ещё один момент. Adb backup спроектирован таким образом, чтобы резервную копию, созданную на одном устройстве, можно было бы без проблем восстановить на другом. И ключевое слово здесь вовсе не «восстановить», а «без проблем»: устройство должно работать абсолютно корректно после восстановления. Соответственно, сохраняются и восстанавливаются только те данные и настройки, которые точно не навредят стабильной работе даже тогда, когда данные переносятся с 32-битного смартфона с чипсетом MediaTek (архитектура ARMv7) на 64-разрядный планшет с Intel Atom (архитектура x86-64).

У команды ADB backup следующий синтаксис:

adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all][-system|-nosystem] [<packages…>]

— write an archive of the device’s data to <file>.

If no -f option is supplied then the data is written

to «backup.ab» in the current directory.

(-apk|-noapk enable/disable backup of the .apks

themselves in the archive; the default is noapk.)

(-shared|-noshared enable/disable backup of the device’s

shared storage / SD card contents; the default is

noshared.)

(-all means to back up all installed applications)

(-system|-nosystem toggles whether -all automatically

includes system applications; the default is to

include system apps)

(<packages…> is the list of applications to be backed

1. If the -all or -shared flags are passed, then the

package list is optional. Applications explicitly

given on the command line will be included even if

-nosystem would ordinarily cause them to be omitted.)

Восстановить данные из резервной копии будет несложно с помощью команды adb restore.

Что же попадает в такие резервные копии? И снова ответ зависит от производителя устройства. К примеру, в смартфонах SONY контакты, журнал звонков и SMS в резервные копии ADB не попадает, а телефоны Samsung эти данные сохраняют. То же самое относится к настройкам устройства (которые зачастую уникальны для конкретного производителя) и данным системных приложений.

В резервную копию точно попадает список установленных приложений. Извлекаются и сохраняются .apk-файлы (если во время создания копии была указана соответствующая опция). А вот данные приложений могут сохраняться, а могут и нет: зависит это от разработчиков, которые могут разрешить или не разрешить резервное копирование в файле manifest приложения.  При этом восстановление из резервной копии adb – лотерея: на большинстве современных устройств приложения (.apk) из резервной копии на устройство установлены не будут. Таким образом, в современных условиях резервное копирование через adb невозможно рекомендовать обычному пользователю, но оно может оказаться полезным для проведения экспертного анализа содержимого устройства.

С практической точки зрения нам не удалось извлечь большой пользы из таких резервных копий. При работе с adb backup всё равно приходится авторизоваться в Gmail, Facebook и прочих клиентов почты и социальных сетей. Не сохранились настройки FBReader и Nova Launcher (у которого, к слову, есть собственный механизм создания резервных копий). А что сохранилось? С трудом припоминается, что на некоторых аппаратах удалось восстановить журнал звонков и архив SMS сообщений.

Резервные копии ADB: что внутри?

Резервные копии, создаваемые через adb — вещь достаточно простая. На выходе – архив, содержащий данные приложений (в зависимости от настроек – и собственно .apk). Данные приложений сохраняются в том виде, в котором их хранит само приложение. Как правило, приложения используют формат SQLite, реже — XML, ещё реже двоичные данные в собственном формате. Для анализа SQLite придумано столько инструментов, что для самого краткого обзора потребовалась бы отдельная статья. Скажем лишь, что с помощью таких инструментов можно вытащить удалённые записи. Пример? Пожалуйста. Если нам повезло, и производитель твоего телефона разрешил копировать журнал звонков и SMS, то получится восстановить сообщения и звонки, которые были удалены пользователем.

Заключение

Сегодня мы рассмотрели часть механизмов резервного копирования, доступных в устройствах под управлением Android. Фрагментация платформы не позволяет рассмотреть все существующие способы и приложения, призванные облегчить резервное копирование и миграцию данных, но даже те, что были рассмотрены, демонстрируют довольно жёсткие ограничения как по совместимости, так и по полноте копируемых данных. В целом наш вывод таков. При использовании Android 6.0 и более новых версий имеет смысл активировать как «облачную» синхронизацию контактов и фотографий, так и «облачное» резервное копирование в Google Drive.

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

В результате система резервного копирования в Андроид получает оценку «лучше, чем ничего». Сделать хуже, чем в Android, не смог никто: даже в старенькой Windows Phone 8 резервное копирование (и восстановление!) работает гораздо лучше.

А как обстоят дела с резервным копированием у аутсайдеров рынка, телефонов под управлением мобильной версии Windows и BlackBerry 10? Об этом – в следующем выпуске!