How to Publish a Unity Game on Google Play: Build Settings, Keystores, and AAB Export

Unity developers live in the editor, but the path to publish a Unity game on Google Play runs through Android build tooling that Unity mostly hides from you. This guide covers the Unity-specific steps: build settings for Android, keystore management, AAB export, the 64-bit requirement, store listing considerations for games, and the Unity-specific rejection causes that catch teams off guard.

1. Configure Build Settings for Android

Open File > Build Settings, switch the platform to Android, and check Build App Bundle (Google Play) — Google Play requires the AAB format for new apps, and Unity's "Google Play" build target produces it. Then open Player Settings and audit the critical fields:

• Package Name (com.YourStudio.YourGame): permanent once the app is created in Play Console. Use reverse-domain notation and never leave the default com.Company.ProductName.
• Version / Bundle Version Code: increment the bundle version code with every upload. Play Console rejects duplicate or lower version codes, so bake a scheme into your release process (e.g. major * 100 + minor or a CI build number).
• Minimum API Level: keep it as low as your game tolerates for reach, but note that the Target API Level must meet Google's current requirement (it advances yearly — check the Play Console for the active minimum).
• Scripting Backend: IL2CPP for release builds. Mono is fine for iteration, but IL2CPP is required for 64-bit support.
• Api Compatibility Level: .NET Standard 2.1 is the modern default; only change it if a plugin demands otherwise.

Under Publishing Settings, Unity exposes the keystore UI — which brings us to the most mishandled part of the process.

2. Keystore Management in Unity

Unity can generate a keystore for you (Publishing Settings > Keystore Manager > Create New), and for solo developers that is fine — but treat that file like production credentials:

1. Generate one keystore per studio, not per game, and reuse its key across your titles. This simplifies updates and key management.
2. Store the .keystore file outside the project directory and back it up (encrypted cloud storage, password manager attachment). If it lives only in Assets/, one bad .gitignore or machine loss can strand your game.
3. Never commit the keystore or its passwords to version control. For CI, inject them as secrets.

Enroll in Play App Signing when you create the app in the Console: Google manages the final app-signing key and your Unity keystore becomes the upload key. Enroll first — losing an unenrolled signing key historically meant losing the ability to update the app.

For automated builds, pass signing via command line or environment rather than the editor UI:

# Example CI step (Unity 2021+)
Unity -quit -batchmode -nographics \
  -projectPath "$CI_PROJECT_DIR" \
  -executeMethod BuildScript.BuildAndroid \
  -keystorePass "$KEYSTORE_PASS" \
  -keyaliasPass "$KEYALIAS_PASS"

// BuildScript.cs — read credentials from env, never hardcode
PlayerSettings.Android.keystorePass = Environment.GetEnvironmentVariable("KEYSTORE_PASS");
PlayerSettings.Android.keyaliasPass = Environment.GetEnvironmentVariable("KEYALIAS_PASS");

3. Export the AAB

With settings in place, Build And Run is for testing; Build produces the artifact. Verify the output is an .aab (not .apk) and inspect it before upload. Unity's default texture and architecture settings are the usual suspects for bloated or non-compliant bundles:

• Target Architectures: enable ARM64 (required — see below) and ARMv7 if you need older device coverage. Disable x86/x86_64 unless you specifically need Chromebooks or the emulator.
• Texture compression: use ASTC or ETC2 rather than uncompressed fallbacks; a 300 MB bundle with uncompressed textures is a common first-build surprise.
• Strip engine code (Player Settings > Optimization > Strip Engine Code) and use Medium/High managed stripping once you've verified the game runs — reflection-heavy plugins may need link.xml preservation files:

<!-- Assets/link.xml — preserve reflectively used types from stripping -->
<linker>
  <assembly fullname="MyGame.Assembly">
    <type fullname="MyGame.SaveSystem" preserve="all"/>
  </assembly>
</linker>

Test the release-configured build on a physical device via adb install of a universal APK extracted with bundletool — editor play mode and development builds hide stripping and compression bugs.

4. The 64-Bit Requirement

Google Play requires native code to include 64-bit support. For Unity this is straightforward but frequently missed: IL2CPP scripting backend + ARM64 target architecture enabled. If either is off, Play Console rejects the upload with an architecture error. Check the built AAB for lib/arm64-v8a entries; if only armeabi-v7a is present, your build will be refused. Mono scripting backend cannot satisfy this requirement for release.

5. Store Listing for Games

Games compete on visuals, so the listing assets matter more than for utility apps:

• Icon (512×512): legible at tiny sizes — your game's key character or symbol, not a busy scene.
• Feature graphic (1024×500): the banner users see at the top of your listing. No critical text near the edges; it gets cropped on some surfaces.
• Screenshots: lead with actual gameplay, not menus or logos. Show the fantasy of playing in the first two frames.
• Short description (80 chars): the hook — genre + differentiator ("Fast-paced roguelike deck-builder with real-time combat").
• Categorization: pick the most accurate game category and tags; miscategorization hurts discovery more than it helps.

Localize at least the short description and screenshots for your top target markets — English-only listings leave downloads on the table in large non-English markets.

6. Common Unity-Specific Rejection Causes

These come up repeatedly in Unity-published games:

1. Missing 64-bit binaries — the IL2CPP/ARM64 miss described above.
2. SDK declarations: third-party ad/analytics SDKs (Unity Ads, ironSource, Firebase) collect data. Your Data Safety form must declare everything they collect — undeclared SDK behavior is one of the most common policy flags on games.
3. WebView gambling lookalikes: casino-style mechanics with real-money-adjacent monetization get extra scrutiny; know the gambling policy before you build.
4. Deceptive ads in ad-supported games: if your game shows ads, misleading ad content attributed to your app can trigger removals.
5. Target API lag: Unity LTS versions eventually fall behind the required target API level. Keep Unity updated or use a recent LTS — an outdated target SDK is an automatic rejection.
6. Login walls without demo credentials: if reviewers can't get past your login or tutorial gate, provide test credentials in the Console's app-access instructions.

Pre-Upload Checklist

• [ ] Package name final, version code incremented
• [ ] IL2CPP + ARM64 enabled; AAB (not APK) produced
• [ ] Keystore backed up outside the project; Play App Signing enrolled
• [ ] Release build tested on a physical device (stripping verified)
• [ ] Store graphics: icon, feature graphic, gameplay-first screenshots
• [ ] Data Safety form reflects every SDK in the build
• [ ] For new developer accounts: 14-day closed testing track completed

Unity handles the game; the Console handles the business. Respect both halves and publishing becomes routine. If the Console side — account setup, testing coordination, or policy remediation — is eating your development time, Play Console Store is an independent marketplace for Google Play publishing services built for exactly that.

---

The author is a Unity developer who has shipped mobile titles to Google Play. This article was contributed on behalf of Play Console Store, an independent marketplace for Google Play publishing services — not affiliated with or endorsed by Google LLC. Learn more at playconsolestore.com.