Пайплайн підписання та збірки ігор для Google Play

Проблеми підписання в 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.

Як забезпечити стабільність збірок?

Використання CI/CD з автоматичним тестуванням та контролем версій знижує ризик людських помилок та гарантує відтворюваність збірок.

Чому 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.

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

Ручний реліз мобільної гри коштує значних коштів (зарплата інженера на 2–3 дні, тестування, переробки). Автоматизація CI/CD окупається в перші два місяці — знижує витрати на реліз на 40–60%. Тобто кожен наступний реліз обходиться значно дешевше.

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

Як автоматизація впливає на якість релізу?

Автоматизація усуває людський фактор, забезпечує послідовність збірок та дозволяє швидше виправляти помилки.

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

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

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

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

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