Почему новый Android-смартфон переносит приложения, но теряет их данные: что на самом деле сохраняет резервная копия

Резервная копия Android не является образом памяти смартфона

Фраза «резервная копия телефона» создает неверное ожидание: кажется, что Google сохраняет состояние устройства примерно так же, как программа клонирования сохраняет системный диск компьютера. Android работает иначе. Согласно официальной справке Google, системная резервная копия может включать приложения и их данные, историю звонков, контакты, настройки устройства, SMS и MMS. RCS-сообщения дополнительно сохраняются при использовании Google Messages, фотографии и видео обслуживаются Google Photos. Уже из этого разделения видно, что единого архива, содержащего побайтовую копию внутренней памяти смартфона, не создается.

У приложений существует собственный механизм Auto Backup. Он появился в Android 6.0 и предназначен для сохранения части приватных данных приложения в Google Drive. По умолчанию туда могут попадать SharedPreferences, внутренние файлы, базы данных SQLite и некоторые файлы из каталога приложения на внешнем хранилище. Кеш, code cache и каталог noBackupFilesDir исключаются. Разработчик может дополнительно указать собственные правила включения и исключения файлов либо вообще отказаться от облачного резервного копирования. Поэтому два приложения, установленные на одном смартфоне и использующие одну систему резервирования Android, после восстановления способны вести себя совершенно по-разному.

Есть ограничение, о котором пользователь обычно узнает уже после неудачного переноса. Android Developers устанавливает для Auto Backup квоту 25 МБ на одного пользователя одного приложения. Если объем данных, который приложение пытается передать в облачную копию, превышает эту границу, система вызывает onQuotaExceeded() и не сохраняет эти данные через Auto Backup. Android позднее проверяет объем повторно и может возобновить резервирование, если приложение снова укладывается в лимит. Эта квота не расходует обычное пространство Google Drive пользователя, а сохраненная копия приложения недоступна для просмотра как обычный файл.

Фото: Rohit Sharma

Отсюда появляется первый парадокс при настройке нового телефона. Google Play знает список ранее установленных приложений и может скачать их заново. Это еще не означает, что вместе с APK существует пригодный набор пользовательских данных. После установки Android пытается восстановить доступную копию, но приложение может исключить часть информации, использовать собственное облако, требовать повторную авторизацию или вообще не участвовать в Auto Backup. Внешне все выглядит как частично завершившийся перенос: иконки вернулись, а содержимое нет. Для системы это могут быть две независимые успешно выполненные операции.

Еще одна особенность связана со временем создания копии. Auto Backup не выполняется непрерывно после каждого изменения. Документация Android указывает несколько условий: резервирование должно быть включено, после предыдущего backup должно пройти не менее 24 часов, устройство должно находиться в состоянии простоя и иметь подходящее сетевое соединение. На практике процедура обычно выполняется ночью. Если пользователь изменил данные приложения утром, разбил смартфон днем и вечером восстанавливает новый аппарат, последняя облачная копия конкретного приложения может предшествовать этим изменениям.

Прямой перенос со старого телефона и восстановление из облака — разные процедуры

При первом включении нового Android-смартфона система предлагает перенести данные непосредственно со старого устройства. Это Device-to-Device Transfer, или D2D. Передача может идти по кабелю или беспроводному соединению в зависимости от устройств. Ее не следует считать другим интерфейсом к той же облачной копии: Android рассматривает D2D и cloud backup как отдельные способы миграции, а приложение может задавать для них разные правила.

Это различие закреплено на уровне API. Начиная с Android 12 для приложений, ориентированных на API 31 и выше, используется конфигурация data-extraction-rules, в которой существуют отдельные секции <cloud-backup> и <device-transfer>. Разработчик способен разрешить перенос определенного каталога напрямую между телефонами и одновременно запретить его загрузку в облако. Возможна и обратная логика. В документации Android даже приведен пример, где обычные настройки приложения разрешены для cloud backup, чувствительное локальное состояние исключено из облачной копии, а набор данных для D2D задается отдельно.

Фото: Hal Gatewood

Для владельца телефона из этого следует практическое правило: если старое устройство исправно, сбрасывать его сразу после появления рабочего стола на новом нельзя. Сначала нужно открыть приложения, которыми действительно пользуются, проверить локальные фотографии и документы, мессенджеры, заметки, записи диктофона, банковские приложения, двухфакторную аутентификацию и программы, где хранятся рабочие данные. Сам факт появления приложения на новом смартфоне ничего не говорит о полноте его внутренней базы.

Особенно опасно считать число перенесенных приложений показателем успешности миграции. На старом устройстве программа могла занимать несколько гигабайт, но большая часть этого объема приходится на кеш, скачанные карты, музыку, офлайн-видео или другие данные, которые разработчик намеренно не включает в backup. После переноса Android устанавливает чистое приложение, оно снова получает данные со своего сервера, если такой сервер существует. Для Spotify или карт это обычно лишь потеря времени на повторную загрузку. Для программы, которая хранит единственный экземпляр пользовательского файла локально, последствия могут быть другими.

Есть еще одно ограничение: Google предупреждает, что резервную копию с более новой версии Android нельзя восстановить на устройство с более старой версией системы. Поэтому миграция не всегда симметрична. Перенести данные со старого телефона на более новый обычно проще, чем взять backup аппарата с новой Android и попытаться развернуть его на устройстве, оставшемся на старой версии ОС.

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

Далеко не все, что технически является файлом приложения, разумно переносить на другой смартфон. Токен авторизации, криптографический ключ или идентификатор конкретного устройства может потерять смысл после миграции либо создать уязвимость. Документация Android прямо рекомендует не переносить файлы с device-specific identifiers. В качестве примера приводится регистрационный токен Firebase Cloud Messaging: после установки приложения на новом устройстве должен быть создан новый токен, а восстановление старого способно вызвать неправильную работу уведомлений.

Для учетных данных Android предлагает отдельные механизмы. Credential Manager работает с паролями, passkeys и федеративной авторизацией, а Block Store позволяет разработчику сохранить сведения, необходимые для возвращения пользователя в учетную запись после смены устройства. Это уже не обычное копирование каталога приложения. Разработчик должен реализовать соответствующий сценарий, а сервер приложения должен понимать, что перед ним новое устройство.

Из-за этого повторный запрос логина после переноса сам по себе не говорит о неисправности backup. Для приложения с чувствительными данными повторная проверка личности может быть сознательной частью архитектуры. Банковское приложение, корпоративный VPN, криптографический контейнер или менеджер двухфакторной аутентификации имеют причины не переносить все локальное состояние обычным Auto Backup. Конкретные правила зависят от приложения, поэтому перед сбросом старого телефона нужно пользоваться средствами экспорта и миграции, которые предусмотрел его разработчик.

Фото: не указан

С passkeys ситуация интереснее. Если ключ хранится в синхронизируемом менеджере учетных данных, он может появиться на новом устройстве через соответствующую экосистему. Но сама технология passkey не означает, что любой созданный ключ обязательно существует на всех телефонах пользователя. Ключ может быть привязан к конкретному аппаратному аутентификатору или храниться в другом менеджере. Поэтому до очистки старого смартфона полезно проверить способы входа в критически важные аккаунты: наличие другого passkey, резервных кодов, пароля, аппаратного ключа или подтвержденного номера телефона.

Похожая логика действует для приложений двухфакторной аутентификации. Наличие программы Authenticator в списке восстановленных приложений не доказывает, что внутри появились секреты всех TOTP-аккаунтов. Это два разных уровня данных. Если конкретный аутентификатор поддерживает облачную синхронизацию или экспорт, эту функцию нужно проверить отдельно. Потеря TOTP-секрета становится заметна только при следующем входе в сервис, когда старый телефон уже может быть очищен.

Фотографии, мессенджеры и файлы живут по своим правилам

Медиатека смартфона — хороший пример того, почему системный backup нельзя считать копией внутреннего накопителя. Google отдельно относит фотографии и видео к Google Photos. Если синхронизация Google Photos включена, изображения могут находиться в облачной медиатеке и появиться на новом устройстве независимо от Auto Backup приложений. Если она выключена, наличие системной резервной копии Android не следует воспринимать как доказательство того, что каталог камеры сохранен удаленно.

С обычными файлами ситуация похожая. Документ в Google Drive уже находится в облачном хранилище и не нуждается в копировании через Auto Backup приложения. PDF, сохраненный браузером только в Download, может существовать исключительно во внутренней памяти. Файл в каталоге конкретной программы может попасть под правила ее резервирования. Три визуально одинаковых документа поэтому имеют совершенно разную судьбу при сбросе смартфона в зависимости от места хранения и используемого приложения.

Фото: JESHOOTS.com

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

Поэтому проверка перед сменой смартфона должна идти не по списку приложений, а по типам незаменимых данных. Где находятся оригиналы фотографий? Синхронизированы ли контакты с аккаунтом или записаны локально? Где лежат записи диктофона? Каким способом мессенджер переносит историю? Можно ли войти в менеджер паролей без старого телефона? Есть ли доступ к TOTP и резервным кодам? Скопированы ли файлы из Download и рабочих каталогов? Ответы на эти вопросы намного точнее показывают готовность к миграции, чем надпись «резервное копирование завершено».

Отдельная проверка нужна для карт памяти. microSD может содержать фотографии, музыку и документы, но наличие карты не означает, что все приложения хранили пользовательские данные именно там. Современный Android изолирует приватные каталоги приложений, а часть программ вообще не предлагает выбор места хранения. Перед извлечением карты полезно посмотреть реальные каталоги через файловый менеджер или подключение к компьютеру, а не считать всю память телефона автоматически продублированной на microSD.