In-App Update для Android: принудительное обновление

Ускоренное обновление Android-приложения с In-App Update API

Принудительное обновление для Android — инструмент Google Play, позволяющий доставлять патчи без действий пользователя. Пользователи не обновляются сами. По данным Play Console, среднее время установки — около 3 недель. Критический фикс ждёт пользователя 21 день. Этот API решает проблему напрямую. Принудительное обновление через Immediate-режим снижает долю устаревших версий до 5% уже за 48 часов. Наша команда накопила 7+ лет опыта в интеграции Android-механизмов обновлений. Мы реализовали данный инструмент в 40+ проектах. Стоимость базовой интеграции — от 15 000 рублей. Полный цикл с тестированием и CI/CD — от 35 000 рублей. Свяжитесь с нами для аудита: сократим время доставки критических патчей до нескольких минут.

Какой режим In-App Update выбрать?

Google Play In-App Update API, доступный через com.google.android.play:app-update-ktx, предоставляет два сценария. Минимальный Android SDK — уровень 21. Библиотека весит около 150 КБ и работает на Android 5.0 и выше.

Flexible update — фоновая загрузка, пользователь продолжает работу. Идеально для фичевых релизов. После завершения загрузки показывается снекбар с кнопкой «Перезапустить». Если пользователь его закрыл — нужно отдельно отслеживать InstallStatus.DOWNLOADED и показывать повторный запрос.

Immediate update — полноэкранный блокирующий интерфейс от Google Play. Приложение недоступно до завершения обновления. Используем при критических патчах: смена схемы шифрования, обязательная миграция БД, прекращение поддержки старого API бэкенда. Immediate update быстрее обычного ожидания: установка занимает 2-5 минут, а не 3 недели. Экономия на поддержке устаревших версий достигает 70%. По данным Google I/O 2023, install rate в Immediate-сценарии выше на 60-80%.

Что вызывает проблемы в реализации?

Самая частая ошибка — инициализировать AppUpdateManager без проверки доступности обновления. Метод appUpdateManager.appUpdateInfo возвращает Task<AppUpdateInfo>, и его нужно ждать асинхронно. Попытки вызвать startUpdateFlowForResult без готового AppUpdateInfo дают IllegalStateException в рантайме.

Второй частый баг — пропуск состояния когда обновление недоступно. Это проявляется на сборках из Firebase App Distribution и при работе с FakeAppUpdateManager. В продакшене этот путь недостижим, но в CI падают тесты.

Третья проблема — версионирование. Сравнение идёт по versionCode, не по versionName. Если несколько флейворов делят один versionCode, обновление не предложится. Это правило действует даже когда бинарники разные.

Реализация In-App Update под ключ

Интеграция начинается с аудита текущей схемы версионирования — проверяем, что versionCode монотонно возрастает и нет коллизий между флейворами. Затем добавляем зависимость и пишем UpdateManager-класс в слое domain (чистая архитектура — UI не знает о Play Services напрямую).

val appUpdateManager = AppUpdateManagerFactory.create(context) val appUpdateInfoTask = appUpdateManager.appUpdateInfo appUpdateInfoTask.addOnSuccessListener { info -> if (info.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE && info.isUpdateTypeAllowed(AppUpdateType.FLEXIBLE) ) { appUpdateManager.startUpdateFlowForResult( info, AppUpdateType.FLEXIBLE, activity, REQUEST_CODE_UPDATE ) } } 

Для Immediate-сценария добавляем staleDays — принудительный апдейт включается только если обновление доступно более N дней. Рекомендуемый порог — от 3 до 7 дней для фичевых релизов. Это снижает раздражение пользователей при мелких патчах.

Обработка onResume критична. Если пользователь свернул приложение во время Flexible-загрузки и вернулся — проверяем installStatus и предлагаем рестарт. Без этого приложение работает на старом коде, хотя новый уже лежит на диске.

Обработка отмены принудительного обновления

Immediate update не означает, что пользователь точно обновится. Он может закрыть приложение — onActivityResult вернёт RESULT_CANCELED. Нужно корректно обрабатывать эту ветку: логировать событие и, возможно, показывать диалог с объяснением необходимости обновления. В некоторых случаях можно переключиться на Flexible update, если это допустимо. Получите консультацию по внедрению In-App Update, и мы предложим индивидуальное решение для вашего приложения.

Тестирование In-App Update с FakeAppUpdateManager

FakeAppUpdateManager из play-app-update позволяет эмулировать все состояния без публикации в Play Store. В Espresso-тестах можно прогнать полный цикл: доступность → начало загрузки → завершение → рестарт. Согласно Google Play In-App Update API documentation, без этого покрытия баги уходят в продакшен. Google Play показывает UI поверх приложения. Стандартные UI-тесты его не видят. Тестовый цикл в CI занимает 4-6 минут.

Процесс работы и сроки

1. Аналитика — аудит версионирования, архитектуры и текущих зависимостей (1 день).
2. Проектирование — выбор режимов, определение staleDays, написание интеграционных тестов (1-2 дня).
3. Реализация — код UpdateManager, обработка onResume, логирование (1-2 дня).
4. Тестирование — unit, integration, UI автоматизация (1 день).
5. Деплой — публикация в Internal Testing, проверка на реальных устройствах (1 день).

Ориентировочный срок — от 2 до 5 рабочих дней в зависимости от сложности архитектуры.

Что входит в работу

• Аудит текущей схемы версионирования
• Реализация UpdateManager с обработкой всех состояний
• Юнит-тесты и UI-тесты с FakeAppUpdateManager
• Интеграция с CI/CD
• Документация по эксплуатации
• Поддержка в течение 2 недель после релиза

Свяжитесь с нами для точной оценки вашего проекта — мы предоставим детальный план и гарантируем результат.