Публикация приложения за 6 минут

Вопросы про релиз задают middle и senior: как приложение попадает к пользователю, как не выкатить баг на всех и как обновлять targetSdk. В российских компаниях к Google Play часто добавляются RuStore и AppGallery, поэтому полезно понимать и общую схему.

Формат: AAB и APK

Google Play принимает новые приложения только в формате Android App Bundle (.aab). Это не устанавливаемый файл, а пакет со всем кодом и ресурсами. Play генерирует из него оптимизированные APK под конкретное устройство (split APK по ABI, плотности экрана, языку). Пользователь скачивает меньше. Для локальной проверки AAB используют bundletool.

APK по-прежнему нужен для установки напрямую и некоторых магазинов (RuStore принимает и APK, и AAB).

Подпись

Каждое приложение подписано. Обновление установится, только если подпись совпадает с установленной версией.

Play App Signing: ключ подписи приложения хранит Google, а разработчик подписывает загрузку ключом загрузки (upload key). Если ключ загрузки потерян или скомпрометирован, его можно сбросить через поддержку; ключ подписи при этом остаётся у Google. Для новых приложений Play App Signing обязателен вместе с AAB.

Ключи не хранят в репозитории. В CI их передают через секреты.

Версии и targetSdk

• versionCode должен расти с каждой загрузкой.
• Google Play требует, чтобы новые приложения и обновления были нацелены на свежую версию API: обычно в течение года после выхода новой версии Android. Если не обновлять targetSdk, обновления не опубликовать, а новые пользователи на свежих устройствах могут не увидеть приложение.
• Повышение targetSdk включает новые изменения поведения: разрешения, ограничения фона, обязательные типы foreground-сервисов, edge-to-edge в Android 15, ограничения на поворот и размер окна на больших экранах в Android 16. Поэтому это отдельная задача с тестированием, а не смена одной цифры.

Треки и поэтапный выпуск

Треки Play Console:

• Internal testing: до 100 тестировщиков, сборка доступна почти сразу.
• Closed testing: группы по email или Google Groups. Для новых личных аккаунтов разработчика Google требует закрытое тестирование с минимальным числом тестировщиков в течение установленного срока перед выходом в прод.
• Open testing: публичная бета.
• Production.

Поэтапный выпуск (staged rollout): обновление получает сначала, например, 1%, потом 5%, 20%, 50%, 100%. Между этапами смотрят на краши и ANR в Android Vitals и Crashlytics. Если что-то сломалось, выпуск останавливают (halt). Откатить версию нельзя: вернуть старый versionCode невозможно, выпускают исправление с большим versionCode.

Отсюда практика: опасные функции прячут за feature flags (Firebase Remote Config, свой сервер), чтобы выключить без релиза.

Перед отправкой

• Release-сборка с R8 протестирована (не только debug).
• Загружен mapping.txt для расшифровки стектрейсов (Play Console принимает его вместе с AAB).
• Заполнены разделы Play Console: Data safety (какие данные собираются), рейтинг контента, целевая аудитория, политика конфиденциальности.
• Разрешения: только нужные. Опасные разрешения запрашиваются в рантайме, а для чувствительных (SMS, звонки, геолокация в фоне, QUERY_ALL_PACKAGES, полный доступ к файлам) Play требует декларацию и обоснование.
• Проверка на Android Vitals: пороги «плохого поведения» по крашам и ANR влияют на видимость в магазине.

Обновления у пользователей

In-App Updates API (Play Core) позволяет предложить обновление прямо в приложении: гибкое (скачивание в фоне) или немедленное (полноэкранное, для критичных). Для принудительного обновления старых версий обычно используют свой эндпоинт с минимальной поддерживаемой версией.

CI/CD

Сборку и выкладку автоматизируют: GitHub Actions, GitLab CI, Jenkins, плюс fastlane или Gradle Play Publisher для загрузки в Play. Типичный пайплайн: проверки и тесты на PR, сборка AAB и загрузка во внутренний трек на мерж в main, перевод в прод вручную после проверки.

Частые ошибки

• Потеря ключа подписи без Play App Signing: обновления невозможны.
• Повышение targetSdk без тестирования изменений поведения.
• Выкатка сразу на 100% без staged rollout и feature flags.
• Ожидание, что можно «откатить» релиз в Play.
• Не загруженный mapping.txt и нечитаемые краши.
• Лишние разрешения и отказ в публикации.

Что спросят на собесе

• Чем AAB отличается от APK?
• Как работает Play App Signing и чем upload key отличается от ключа подписи?
• Что такое треки и staged rollout? Как откатить плохой релиз?
• Что меняется при повышении targetSdk?
• Как организовать CI/CD мобильного приложения?