Android Game Build & Sign Pipeline: Keys to AAB

Problems with Google Play Signing: How to Avoid Them

You upload your APK to Play Console, it passes review—and two hours later you get a rejection: "Your APK is not signed with the upload key." Or the build is accepted, but a week later users report that Android asks to "remove the old version before installing" because the keystore changed between releases and Play App Signing wasn't activated in time. This error stems from a misconfigured keystore or a missed Play App Signing activation step. We've dealt with both cases on dozens of projects, including migrating major games with millions of installs. We saved up to 30% of bundle size using AAB and PAD. Our team, with 10+ years in gamedev (40+ projects), has developed a clear pipeline that eliminates these errors. We set up build and signing turnkey—get a consultation, we'll assess your project.

Keystore vs. Play App Signing: What's the Difference

Before Play App Signing (now mandatory for new apps), developers signed APKs with their own key—and that's the key users saw. Losing the keystore meant permanent inability to release updates (official Google documentation).

With Play App Signing, the scheme is two-tiered: an upload key (held by the developer) signs the APK when uploading to Play Console; Google verifies it and re-signs the final APK with its own app signing key before delivering to users. Losing the upload key is recoverable—Google allows a reset request. Losing the app signing key is not, but it's stored by Google.

For new apps, Play App Signing is enabled automatically. For existing apps, you must explicitly activate it by uploading the current key. Our guarantee: we help migrate keys without losing backward compatibility.

How to Set Up Play App Signing for an Existing Project

For apps already published without Play App Signing, the process requires caution. Go to Play Console, select the app, navigate to Release > Setup > App Signing. Then upload your current keystore (or just the certificate) for registration. After activation, all new versions will be signed by Google—the old key becomes the upload key. We've completed this transition for 15+ projects; average time is 1–2 days when the keystore is ready.

Building AAB Instead of APK

For some years now, Google Play requires Android App Bundle (.aab) for new apps. Unity generates AAB via BuildSettings with BuildAppBundle = true. AAB is smaller than APK and allows Play Console to generate device-optimized APKs (ABI split, texture compression split). This saves up to 30% on user traffic.

An important nuance for Unity games: when using IL2CPP and AAB, ensure Split Application Binary is enabled in Player Settings—otherwise the AAB may exceed the 150 MB download limit. Additional assets (Addressables, StreamingAssets) should be delivered via Play Asset Delivery (PAD), not bundled directly.

Play Asset Delivery is essential for games with large resources. Three delivery modes:

Integration with Unity via the Google.Play.AssetDelivery package requires reworking the asset loading system if not designed for PAD from the start. This is included in our full setup.

Why Automating with Fastlane Saves Time

The supply action (Fastlane lane for Google Play) can upload AAB to specific tracks (internal, alpha, beta, production), manage rollout percentage, and update store listings. In 2–5 days, we create a pipeline that handles these actions without manual intervention.

Authentication: via Service Account JSON with the "Release Manager" role in Play Console. This is more reliable than OAuth—the token doesn't expire and doesn't require interactive authorization on CI.

Example minimal 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

The keystore is stored encrypted in CI (GitHub Secrets, GitLab CI Variables, Vault). Never commit .jks or .keystore files to a repository—even a private one. For more on supply parameters, see Fastlane documentation.

Versioning

versionCode in Android must increase monotonically. In Unity, it's PlayerSettings.Android.bundleVersionCode. We auto-increment via a pre-build hook script or through Fastlane's increment_version_code. For CI builds, use the pipeline build number as part of the versionCode: baseVersion * 1000 + buildNumber. An error here is a common reason for publication rejection.

What's Included in Our Work

• Audit of current signing scheme and keystore.
• Configuration of Play App Signing (enable, migrate keys).
• AAB build with optimizations (Split Binary, PAD).
• Integration of Fastlane with CI (GitHub Actions, GitLab CI, Jenkins).
• Versioning and automatic increment.
• Documentation of the process and access.
• Support during the first release.

Timelines

Cost is calculated individually after analyzing your project structure and signing key status. Get a consultation—we'll assess your case.

Common Mistakes and How to Avoid Them

• Changing keystore between releases → causes signature mismatch for users. Solution: always use one upload key.
• Exceeding AAB limit → if Split Application Binary is disabled, the bundle can exceed 150 MB. Check Unity settings before building.
• Not using PAD → loading all assets in the AAB slows installation and may cause ANR. On-demand mode solves the problem.

We guarantee your pipeline will run smoothly and publications will proceed without rejections. Contact us to discuss details.

Manual pre-release preparation as a source of delays

We automate the entire pre-release pipeline for mobile and XR games. A studio is about to release a game — a week before the date, the manager remembers they need to build an AAB, sign it, and upload to Google Play. The build engineer manually starts the build, waits an hour, forgets to enable IL2CPP, the build crashes on Android 12. Rebuilding takes another hour. Simultaneously, the icon needs to be redesigned to meet new Google requirements. As a result, the release is delayed by three days. Experience shows: manual pre-release preparation is the primary source of delays and bugs that do not manifest on the developer's machine.

How to set up CI/CD for mobile game builds?

Pipeline tools

GameCI — open-source Docker images for Unity builds, running on GitHub Actions, GitLab CI, or any other CI provider. Key components: unity-builder (builds for the target platform), unity-test-runner (runs Unity Test Framework before build), unity-return-license (returns the license — critical for Pro). Unity Cloud Build is simpler but less flexible and expensive for frequent builds. Fastlane is the standard for final steps: signing, uploading to stores, metadata.

Typical pipeline

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, not variables — all keys in CI secrets. AAB instead of APK has been mandatory for several years. Tracks: internal → closed → open → production. Promotion — manual or Fastlane supply promote.

iOS specifics

Unity builds an Xcode project, then xcodebuild. Need Distribution Certificate and Provisioning Profile (App Store). Fastlane Match solves the problem of certificate synchronization within the team:

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 replaces login/password, does not break with 2FA.

Step-by-step pipeline setup

1. Audit Unity PlayerSettings (Graphics APIs, Scripting Backend, stripping).
2. Create CI configuration with GameCI — define test, build, and deploy jobs.
3. Integrate Fastlane for code signing and store uploads.
4. Store all secrets (keystore, certificates, API keys) in encrypted CI variables.
5. Run a test release on internal track, verify end‑to‑end.

Each step includes validation: build must pass on a clean runner, not just a local machine.

Why does App Store reject about a third of first submissions?

Apple rejects 30–40% of first submissions from new studios. Common reasons:

Practice: before submission, go through the App Store Review Guidelines from start to finish — 2–3 hours, saving 2–3 weeks of resubmission loops.

Google Play is more lenient: typical reasons — outdated targetSdkVersion, excessive permissions, incorrect Data Safety Form.

Deliverables of pre-release preparation

We deliver the following for your game release:

• CI/CD pipeline configured (GameCI + Fastlane, Unity Cloud Build — turnkey)
• Metadata and marketing assets (screenshots, icons, feature graphics)
• Store submission guidance with documentation of all accesses and credentials
• 72‑hour post‑release monitoring (Crashlytics, ANR rate, user reviews)
• Pipeline documentation and team training session (hands‑on)
• Age rating configuration (IARC, ESRB, PEGI, CERO) and localization of store metadata

Pipeline automation replaces the manual work of an entire department. For example, setting up Continuous Integration via GameCI and Fastlane reduces pre‑release preparation time threefold — from 8 working hours to 2.5.

Our pre-release workflow: from audit to store submission

Impact of pipeline automation on timelines and budget

Manual game release incurs significant engineering and testing costs. CI/CD automation pays for itself within the first two months, reducing release costs by 40–60%.

Result: we reduce the commit‑to‑publish cycle by 6–8 times. For projects with frequent hotfixes, this is the difference between a week‑long user wait and a one‑day fix. We guarantee the pipeline works reliably after setup. Our engineers hold Unity Certified Professional credentials.

Typical savings: $2,500–$5,000 per month on engineering time eliminated by automation — $30,000–$60,000 annually on a mid‑size project.

Post‑release: monitoring and updates

Crash rate < 1% (Firebase Crashlytics), ANR rate < 0.47% (Play Console) — otherwise visibility restrictions. Phased rollout is mandatory: first 10%, then 50%, then 100% of users.

Our track record: 30+ mobile game releases, 5+ years on the market. CI/CD automation pays for itself within the first two months, reducing release costs by 40–60%.

Timeline

Setup takes from 2 days (simple mobile game with existing Unity project) to 2 weeks (complex multi‑platform project with custom CI runners). We calculate exact hours during a free pipeline audit.

Contact our engineers for a free pipeline audit and a timeline estimate. Submit a request — we will analyze your pipeline and offer a solution within 2 days. Get a consultation from an engineer who has shipped 30+ titles.