Пайплайн подписания и сборки игр для 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 решает проблему.

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