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

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