Пошаговый чеклист для релиза Android‑приложения

Короткий ответ: настройте версии (versionCode/versionName), соберите подписанный release (предпочтительно AAB), удалите debug‑артефакты, заполните Store Listing в Play Console и загрузите сборку; для обновлений увеличивайте versionCode и используйте staged rollout.

Управление версиями

versionCode — целое число, обязателен и должен увеличиваться при каждом релизе. versionName — человекочитаемая строка (семантическое версиионирование MAJOR.MINOR.PATCH). Пример в module:app/build.gradle:

android {
  defaultConfig {
    versionCode 12
    versionName "1.2.0"
  }
}

Автоматизируйте инкремент через gradle.properties или CI (например, счётчик в pipeline) и отмечайте релизы Git‑тегом (git tag v1.2.0) для откатов и traceability.

Храните читаемый changelog в release notes и Git‑теге — это упрощает анализ проблем после отката.

Подготовка к сборке release

  1. Отключите debug‑логи и флаги: используйте BuildConfig.DEBUG и отделяйте ключи через buildConfigField.
  2. Включите обфускацию (R8/ProGuard) и проверьте proguard-rules.pro.
  3. Сгенерируйте keystore и защитите его:
keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-key-alias
  1. Пример signingConfigs в build.gradle:
signingConfigs {
  release {
    storeFile file("my-release-key.jks")
    storePassword "REPLACE_ME"
    keyAlias "my-key-alias"
    keyPassword "REPLACE_ME"
  }
}
buildTypes {
  release {
    signingConfig signingConfigs.release
    minifyEnabled true
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
  }
}

Храните пароли в защищённых переменных CI, а keystore — в защищённом хранилище (vault).

Потеря keystore без включённого Play App Signing делает невозможным выпуск обновлений для уже опубликованного приложения.

Сборка release и проверка

  • В Android Studio: Build > Generate Signed Bundle / APK — выбирайте Android App Bundle (AAB).
  • В CLI: ./gradlew bundleRelease (AAB) или ./gradlew assembleRelease (APK).
  • Проверки перед загрузкой: отсутствие debug‑символов, корректные разрешения в манифесте, оптимизация размеров (apkanalyzer), тест на реальном устройстве. AAB рекомендуется для Play — он уменьшает размер и даёт Dynamic Delivery.

Публикация в Google Play (первый релиз)

  1. Создайте аккаунт в Play Console и заполните данные магазина (иконка, скриншоты, описание, страны, цена).
  2. В разделе Release > Production загрузите AAB, добавьте release notes и заполните Data Safety, Content Rating и обязательные поля.
  3. Отправьте на проверку — время проверки первого релиза обычно 1–7 дней.

В Internal Testing можно быстро раздавать сборки до 100 тестировщиков для раннего фидбека.

Публикация обновлений и rollout

  • Перед загрузкой обязательно увеличьте versionCode.
  • Создайте новый релиз в Play Console, загрузите AAB и заполните "What's new".
  • Используйте staged rollout (5–50%) для минимизации рисков: сначала небольшой процент, затем расширяйте.
  • Автоматизируйте выкладку: Play App Signing + Fastlane (fastlane android release) в CI для стабильных релизов.

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

  • Не увеличили versionCode — обновление отклонят.
  • Использование debug‑ключа для релиза или потеря keystore.
  • Оставленные API‑ключи/логи в release‑сборке.
  • Смена package name после публикации — приложение считается новым.
  • Неполное заполнение Data Safety/permission‑политик — возможен риджект.

FAQ

  • В: Нужен ли AAB или можно выкладывать APK?
    О: Для Play рекомендуется AAB; APK можно для sideload и enterprise‑дистрибуции.

  • В: Как ускорить ревью?
    О: Полные скриншоты, корректные метаданные и отсутствие запрещённого контента снижают шанс ручной проверки.

  • В: Что делать при креше после релиза?
    О: Быстро собрать логи через Firebase Crashlytics, оценить распространённость ошибки по метрикам и откатить или выпустить фикс через staged rollout.

  • В: Как безопасно хранить keystore в CI?
    О: Загружайте файл в зашифрованное хранилище CI, используйте секреты для паролей и ограничивайте доступ.

Этот чеклист даёт практическую последовательность действий для безопасного и предсказуемого релиза Android‑приложения. Следуйте автоматизации, защищайте ключи и используйте staged rollout для минимизации рисков.