Збірка та підписання білдів ігор для Google Play

Підписання білдів ігор для Google Play

APK залит в Play Console, проходить ревю — і через дві години приходить відмова: «Your APK is not signed with the upload key». Або сборка прийнята, але через тиждень користувачі повідомляють, що при оновленні Android просить «видалити стару версію перед установкою» — тому що keystore змінився між релізами, а Play App Signing не був активований вчасно.

Android-сборка для Google Play менш церемоніальна, ніж iOS, але помилки в управлінні ключами підписи можуть обернутися втратою аккаунту або неможливістю оновити вже опубліковане додаток.

Keystore та Play App Signing — в чому різниця

До Play App Signing (обов'язково з серпня 2021 для нових додатків) розробник підписував APK своїм ключем — і цей же ключ бачив користувач. Втрата keystore дорівнює неможливості виводити оновлення назавжди.

З Play App Signing схема двохрівневана: upload key (в руках розробника) підписує APK при завантаженні в Play Console, Google його верифікує та переподписує фінальний APK своїм app signing key перед доставкою користувачам. Втрата upload key вирішуєма — Google дозволяє його змінити по запиту. Втрата app signing key — ні, але він зберігається у Google.

При першій публікації нового додатку Play App Signing включається автоматично. Для існуючих додатків — потрібна явна активація з завантаженням поточного ключа.

Сборка AAB замість APK

З 2021 року Google Play вимагає Android App Bundle (.aab) для нових додатків. Unity генерує AAB через BuildOptions з BuildAppBundle = true. AAB важить менше APK та дозволяє Play Console генерувати оптимізовані APK під конкретний пристрій (ABI split, texture compression split).

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

Play Asset Delivery — обов'язкова тема для ігор з крупними ресурсами. Три режими доставки: install-time (разом з установкою, до 1 ГБ), fast-follow (відразу після установки), on-demand (по запиту під час гри). Інтеграція з Unity через Google.Play.AssetDelivery пакет — вимагає переробки системи завантаження ресурсів, якщо вона не проектувалась під PAD з самого початку.

Автоматизація через Fastlane

supply (Fastlane lane для Google Play) вміє завантажувати AAB в конкретний трек (internal, alpha, beta, production), управляти rollout percentage, оновлювати store listing.

Аутентифікація — через Service Account JSON з роллю «Release Manager» в Play Console. Це надійніше OAuth — токен не істекає та не вимагає інтерактивної авторизації на CI.

Приклад мінімального Fastfile:

• gradle action для сборки AAB з потрібним build type
• sign через jarsigner або zipalign + apksigner з keystore з змінних окруження
• supply для завантаження в internal track

Keystore зберігається в зашифрованому вигляді в CI (GitHub Secrets, GitLab CI Variables, Vault). Ніколи не коммітимо .jks або .keystore файли в репозиторій — навіть в приватний.

Версіонування

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

Терміни

Вартість розраховується після аналізу поточної структури проекту та стану ключів підписи.