Category: Game Development

Unity Android Release Checklist for Google Play in 2026

A reliable Android release is a chain of evidence, not a final click on Build. The Unity project, Android manifest, native plug-ins, signing arrangement, Play Console declarations and device tests all need to agree. This checklist is written for Unity 6 and Google Play as reviewed on 28 August 2026; store rules and SDK support move, so re-check the linked first-party sources for every release.

1. Choose a supported editor and freeze the release baseline

Use a supported Unity release that can install the Android SDK, NDK and OpenJDK versions needed by the project and current Play requirement. Record the exact Unity editor version, package-lock file, Android toolchain versions, build profile and source commit. Make a clean release build in continuous integration or on a controlled build machine rather than relying on an unrecorded local setup.

In Unity 6, Android builds are configured through File → Build Profiles. Unity's manual describes Android build profiles and the ability either to build directly or export a Gradle project for Android Studio (Unity: build Android applications). Export only when a plug-in, manifest or native integration genuinely needs that control; every custom Gradle or manifest override becomes release surface that must be reviewed after upgrades.

2. Separate the package identity, minimum SDK and target SDK

Set the application identifier deliberately, normally in reverse-domain form such as info.ozlin.gamename. Confirm ownership and naming before the first production release because updates must retain the same package identity and signing relationship.

Do not confuse these two settings:

• Minimum API level controls which Android versions can install the game. Choose it from Unity support, plug-in requirements and the devices you intend to support—not from an old generic recommendation. Unity 6.0's published player requirements start at Android 6.0/API 23, but the specific Unity patch and packages in the project remain authoritative (Unity 6 system requirements).
• Target API level tells Android which platform behaviour set the app targets and is governed by Google Play submission policy.

Google states that starting 31 August 2026, new apps and app updates must target Android 16/API level 36 or higher. The listed exceptions use different levels for Wear OS, Android Automotive OS, Android TV and Android XR. Existing phone/tablet apps must target API 35 or higher to remain available to new users on devices running a newer Android version (Google Play target API requirements). Because this draft was reviewed three days before that deadline, a release being prepared now should target API 36 and test Android 16 behaviour changes rather than plan around last year's threshold.

After raising the target, test permission requests, background work, notifications, edge-to-edge layout, storage access and every Android plug-in. A successful compile does not demonstrate correct runtime behaviour.

3. Configure the release player intentionally

Review Player Settings and the active build profile together:

• increment versionCode for every uploaded build and set a user-facing version string;
• use IL2CPP when required by the selected architecture and release plan;
• include ARM64 for Google Play device coverage and verify every native .so plug-in supplies a compatible binary;
• remove development-only permissions, test endpoints and debug certificates;
• use HTTPS for network traffic unless a documented exception is essential; and
• review graphics APIs, texture formats, orientation, cut-outs and memory behaviour against the actual device matrix.

Unity's Android Player Settings reference confirms that ARM64 is a target architecture available with the IL2CPP scripting backend and exposes minimum/target API, keystore and architecture settings (Unity: Android Player Settings). Do not enable GPU skinning, Vulkan, ASTC or an “adaptive performance” package as blanket checklist items. Each can be valuable for a suitable game and device set, but each needs compatibility and performance evidence.

4. Build the artifact Google Play expects

For Google Play, create an Android App Bundle (.aab). Unity 6 exposes Build App Bundle (Google Play) in the Android build profile; its documentation distinguishes this from the default APK output and explains the corresponding option when exporting a Gradle project (Unity: Android build settings). Google Play uses an uploaded bundle to generate device-optimised APKs (Play Console: create and set up an app).

Use APKs for direct device testing when appropriate, but do not enable “Split APKs by target architecture” as an AAB size optimisation. Unity documents that its per-architecture APK setting is ignored when building an app bundle. For a large game, review Play's current compressed-download limits and assess Play Asset Delivery rather than discovering an artifact-size problem during submission.

Generate native debug symbols for the IL2CPP release in the form expected by Play Console, store the mapping/symbol artifacts with the build, and confirm crash reporting can resolve the test build before launch.

5. Treat signing as an operational system

The old warning that losing one local keystore always makes future Play updates impossible is too broad. With Play App Signing, Google protects the app-signing key, while the developer uses an upload key to authenticate uploaded bundles. Google recommends separating those keys and documents a reset path for a lost or compromised upload key (Google Play: Play App Signing).

Protect the upload keystore and password in approved secret storage; restrict Play Console roles; require multi-factor authentication; record certificate fingerprints needed by APIs; and document key recovery and release authority. Never commit a keystore or password to the Unity repository. Confirm a release is signed with the expected upload certificate before submission.

6. Test what users will receive

Test a release candidate on representative low-, mid- and high-tier physical devices, including the oldest supported Android version and Android 16. Cover first install, upgrade from the live version, offline start, save migration, sign-in, purchases, notification permission, background/resume, low storage, interrupted downloads and account deletion where applicable.

Profile on the target device. Unity's guidance describes connecting the Unity Profiler to an Android player and collecting data from the running build (Unity: profile a target device). Record frame-time distributions, memory peaks, thermal behaviour, loading time and crash/ANR signals for the devices that define acceptance; an editor frame rate is not mobile evidence.

Upload the signed AAB to internal testing first. Google recommends an internal test before wider tracks and supports up to 100 internal testers (Play Console testing tracks). Use the app-bundle explorer or internal app sharing to test generated, device-specific delivery rather than only a locally installed APK.

7. Complete policy and launch evidence

Finish the store listing, content rating, target-audience declarations, ads and monetisation disclosures, privacy policy, app-access instructions and the Data safety form. Google requires published apps—including closed, open and production tracks—to declare their collection and handling of user data; an internal-only test is the stated exception (Google Play Data safety). Inventory SDK behaviour rather than copying a declaration from a previous version.

Keep a release record containing the commit, Unity version, signed artifact hash, version code, symbols, test results, known issues, policy answers, approval and rollback decision. Stage the rollout, watch crashes and ANRs, and define who can halt it. Store approval is a distribution decision, not proof that a game is defect-free, secure or suitable for every device.

AI-assistance disclosure

AI tools assisted with outlining and copy editing. A human editor checked this draft on 28 August 2026 against the linked Unity 6 documentation and current Google Play requirements, including the API 36 deadline. Rules can change after review; the release owner must re-check official documentation and the project's actual dependencies before submission.