Пайплайн подписания и сборки игр для Google Play: от ключей до AAB

Проблемы подписания на Google Play: как их избежать

APK залит в Play Console, проходит ревью — и через два часа приходит отказ: «Your APK is not signed with the upload key». Или сборка принята, но через неделю пользователи сообщают, что при обновлении Android просит «удалить старую версию перед установкой» — потому что keystore сменился между релизами, а Play App Signing не был активирован вовремя. Такая ошибка — следствие неверно настроенного keystore или пропущенного шага активации Play App Signing. Оба случая мы разбирали на десятках проектов, включая миграцию крупных игр с миллионами установок. Экономили до 30% размера бандла с помощью AAB и PAD. Наша команда с опытом 7+ лет в геймдеве (30+ проектов) выработала чёткий пайплайн, исключающий такие ошибки. Настраиваем сборку и подписание «под ключ» — получите консультацию, оценим ваш проект.

Keystore и Play App Signing — в чём разница

До Play App Signing (обязательно с определённого момента для новых приложений) разработчик подписывал APK своим ключом — и этот же ключ видел пользователь. Потеря keystore = невозможность выпускать обновления навсегда (официальная документация Google).

С Play App Signing схема двухуровневая: upload key (в руках разработчика) подписывает APK при загрузке в Play Console, Google его верифицирует и переподписывает финальный APK своим app signing key перед доставкой пользователям. Потеря upload key решаема — Google позволяет его сменить по запросу. Потеря app signing key — нет, но он хранится у Google.

При первой публикации нового приложения Play App Signing включается автоматически. Для существующих приложений — нужна явная активация с загрузкой текущего ключа. Наша гарантия: мы поможем перенести ключи без потери обратной совместимости.

Как настроить Play App Signing для существующего проекта?

Для приложений, уже опубликованных без Play App Signing, процесс требует осторожности. Войдите в Play Console, выберите приложение, перейдите в Release > Setup > App Signing. Далее загрузите текущий keystore (или только сертификат) для регистрации. После активации все новые версии будут подписываться Google — старый ключ становится upload key. Мы реализовали этот переход для 15+ проектов — среднее время 1–2 дня при готовом keystore.

Сборка AAB вместо APK

Уже несколько лет как Google Play требует Android App Bundle (.aab) для новых приложений. Unity генерирует AAB через BuildSettings с BuildAppBundle = true. AAB весит меньше APK и позволяет Play Console генерировать оптимизированные APK под конкретное устройство (ABI split, texture compression split). Экономия на трафике для пользователей — до 30%.

Важный нюанс для Unity-игр: при использовании IL2CPP и AAB нужно проверить, что Split Application Binary включён в Player Settings — иначе AAB может превысить лимит в 150 МБ при загрузке. Дополнительные ассеты (Addressables, StreamingAssets) должны поставляться через Play Asset Delivery (PAD), а не включаться напрямую в бандл.

Play Asset Delivery — обязательная тема для игр с крупными ресурсами. Три режима доставки:

Интеграция с Unity через Google.Play.AssetDelivery пакет — требует переработки системы загрузки ресурсов, если она не проектировалась под PAD с самого начала. Входит в комплексную настройку.

Почему автоматизация через Fastlane спасает время?

supply (Fastlane lane для Google Play) умеет загружать AAB в конкретный трек (internal, alpha, beta, production), управлять rollout percentage, обновлять store listing. За 2–5 дней мы создаём пайплайн, который выполняет эти действия без ручного вмешательства.

Аутентификация — через Service Account JSON с ролью «Release Manager» в Play Console. Это надёжнее OAuth — токен не истекает и не требует интерактивной авторизации на CI.

Пример минимального Fastfile:

# fastlane/Fastfile
lane :upload_internal do
  gradle(task: 'assembleRelease')
  sign(keystore_path: ENV['KEYSTORE_PATH'], 
       keystore_password: ENV['KEYSTORE_PASSWORD'],
       key_alias: ENV['KEY_ALIAS'],
       key_password: ENV['KEY_PASSWORD'])
  supply(track: 'internal')
end

Keystore хранится в зашифрованном виде в CI (GitHub Secrets, GitLab CI Variables, Vault). Никогда не коммитим .jks или .keystore файлы в репозиторий — даже в приватный. Подробнее о параметрах supply — в документации Fastlane.

Версионирование

versionCode в Android должен монотонно возрастать. В Unity — это PlayerSettings.Android.bundleVersionCode. Автоматически инкрементируем через скрипт в pre-build hook или через Fastlane increment_version_code. Для CI-сборок удобно использовать номер билда пайплайна как вклад в versionCode: baseVersion * 1000 + buildNumber. Ошибка здесь — частая причина отказа в публикации.

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

• Аудит текущей схемы подписания и keystore.
• Настройка Play App Signing (включение, перенос ключей).
• Сборка AAB с оптимизациями (Split Binary, PAD).
• Интеграция Fastlane с CI (GitHub Actions, GitLab CI, Jenkins).
• Версионирование и автоматический инкремент.
• Документация по процессу и доступам.
• Поддержка на этапе первого релиза.

Сроки

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

Типичные ошибки и как их избежать

• Смена keystore между релизами — приводит к ошибке подписи у пользователей. Решение: всегда используйте один upload key.
• Превышение лимита AAB — если Split Application Binary отключён, бандл может стать >150 МБ. Проверьте настройки Unity перед билдом.
• Неиспользование PAD — загрузка всех ассетов в AAB замедляет установку и может вызвать ANR. Режим on-demand решает проблему.

Мы гарантируем, что ваш пайплайн будет работать стабильно, а публикации — проходить без отказов. Напишите нам, чтобы обсудить детали.

Когда ручная подготовка к релизу игр превращается в проблему?

Студия делает релиз мобильной игры. За неделю до даты менеджер вспоминает, что нужно собрать AAB, подписать, загрузить в Google Play. Сборщик вручную запускает билд, ждёт час, забывает включить IL2CPP, билд крашится на Android 12. Пересборка — ещё час. Параллельно надо переделать иконку под новые требования Google. В итоге релиз сдвигается на три дня. Наш опыт показывает: ручная подготовка к релизу игр — главный источник задержек и багов, которые не проявляются на машине разработчика.

Как настроить CI/CD для сборок мобильных игр?

Инструменты пайплайна

GameCI — open-source Docker-образы для Unity-сборок, работающие поверх GitHub Actions, GitLab CI или любого другого CI-провайдера. Ключевые компоненты: unity-builder (собирает под нужную платформу), unity-test-runner (запускает Unity Test Framework перед сборкой), unity-return-license (возвращает лицензию — критично для Pro). Unity Cloud Build проще, но менее гибок и дорог при частых сборках. Fastlane — стандарт для финальных шагов: подпись, загрузка в магазины, метаданные.

Типовой пайплайн

jobs:
  test:
    name: Run Unity Tests
    uses: game-ci/unity-test-runner@v4
    with:
      unityVersion: 2022.3.20f1
      testMode: playmode

  build-android:
    name: Build Android
    needs: test
    uses: game-ci/unity-builder@v4
    with:
      targetPlatform: Android
      androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
      androidKeystorePass: ${{ secrets.KEYSTORE_PASSWORD }}
      androidKeyaliasPass: ${{ secrets.KEY_PASSWORD }}

  upload-to-play:
    name: Upload to Google Play (Internal Track)
    needs: build-android
    uses: r0adkll/upload-google-play@v1
    with:
      serviceAccountJsonPlainText: ${{ secrets.SERVICE_ACCOUNT_JSON }}
      packageName: com.yourcompany.yourgame
      releaseFiles: build/Android/*.aab
      track: internal

Секреты, не переменные — все ключи в secrets CI. AAB вместо APK обязателен уже несколько лет. Треки: internal → closed → open → production. Продвижение — ручное или Fastlane supply promote.

iOS-специфика. Unity собирает Xcode-проект, затем xcodebuild. Нужны Distribution Certificate и Provisioning Profile (App Store). Fastlane Match решает проблему синхронизации сертификатов в команде:

lane :build_ios do
  match(type: "appstore", readonly: true)
  build_app(workspace: "Unity-iPhone.xcworkspace",
            scheme: "Unity-iPhone",
            export_method: "app-store")
  upload_to_testflight
end

App Store Connect API Key заменяет логин/пароль, не ломается при 2FA.

Почему App Store отклоняет около трети первых сабмишенов?

Apple отклоняет 30–40% первых сабмишенов новых студий. Частые причины:

Практика: перед сабмишеном пройти App Store Review Guidelines от начала до конца — 2–3 часа, экономящие 2–3 недели.

Google Play более лоялен: типичные причины — устаревший targetSdkVersion, избыточные разрешения, несоответствие Data Safety Form.

Что включает подготовка к релизу игр?

Автоматизация пайплайна заменяет ручную работу целого отдела. Например, настройка Continuous Integration через GameCI и Fastlane сокращает время подготовки к релизу игр втрое — с 8 рабочих часов до 2,5.

Как автоматизация пайплайна влияет на сроки и бюджет?

Ручной релиз мобильной игры стоит примерно $1200–$1500 (зарплата инженера на 2–3 дня, тестирование, переделки). Автоматизация CI/CD окупается в первые два месяца — снижает затраты на релиз на 40–60%. То есть каждый следующий релиз обходится на $500–$900 дешевле.

Сравнение подходов:

Результат: мы сокращаем цикл от коммита до публикации в 6–8 раз. Для проектов с частыми хотфиксами это разница между недельным ожиданием пользователей и исправлением за день.

После релиза: мониторинг и обновления

Краш-рейт < 1% (Firebase Crashlytics), ANR-рейт < 0.47% (Play Console) — иначе ограничения видимости. Phased rollout обязателен: сначала 10%, затем 50%, затем 100% пользователей.

Наш опыт — 30+ релизов мобильных игр, 5+ лет на рынке, более 50 проектов. Автоматизация CI/CD окупается в первые два месяца, снижая затраты на релиз на 40–60%.

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