Games have one advantage in closed testing that utility apps don't: people actually want to open them. The catch is everything before that. A Unity project that runs fine in the editor can still be rejected at upload, crash on a cheap phone, or show live ads to your own testers.
This guide covers the Unity build settings first, then how to get a game through the 12 testers and 14 days that new personal accounts need.
Set up the Android build in Unity
Open Build Settings (called Build Profiles in Unity 6), select Android and switch the platform. Then go to Player Settings and set the Package Name. It becomes your app's ID on Google Play and can't be changed after the first upload, so pick it carefully.
Under Other Settings, set the Scripting Backend to IL2CPP and tick ARM64 under Target Architectures. Google Play requires 64-bit support, and a Mono build only produces 32-bit ARM code, which is a common reason for an upload being rejected.
Set the Target API Level to the highest one your Unity version offers, or check what Google Play currently requires. Play raises the minimum target API level every year, and older Unity versions may need an updated Android SDK to reach it.
Build a signed App Bundle
Google Play wants an Android App Bundle (.aab) for new apps. In Build Settings, tick Build App Bundle (Google Play) before you build, otherwise you'll get an APK.
In Player Settings, under Publishing Settings, create a new keystore with the Keystore Manager and use it for the release build. Don't upload a build signed with the debug key. Keep the keystore file and its passwords somewhere safe, because every future update has to be signed with the same upload key. With Play App Signing, Google holds the final signing key, which makes a lost upload key recoverable.
Bump the Bundle Version Code in Player Settings for every new upload. Play Console rejects a bundle whose version code it has already seen, and you'll probably upload several builds during the test.
Game-specific things to check before testers arrive
If your game shows ads, switch to test ads for the closed test. Ad networks treat clicks from people close to the developer as invalid traffic, and your testers are exactly that group. AdMob, for example, provides test ad units for this.
Large games can hit the size limit for the base download. Unity supports Play Asset Delivery for moving big asset packs out of the base module; check the current limits in Play Console Help before you assume you're under them.
Test on at least one older or low-memory phone yourself. Shader compile stutters, texture memory crashes and missing permissions show up there first, and a crash on day one is the fastest way to lose a tester.
Running the 14-day closed test
Upload the .aab to a closed testing track, add testers through an email list or a Google Group, and share the opt-in link. If your personal developer account is new, you need at least 12 testers who stay opted in for 14 days in a row before you can apply for production. Organization accounts currently aren't subject to this, but check Play Console Help for your own account.
Recruit a few more than 12, because the days only count while you have enough opted-in testers. Give players something concrete to do, like reaching level 3 or trying the shop, rather than asking them to just play.
If you don't have 12 people, PeerPlay is built for this. Developers test each other's apps in tracked 14-day rounds, PeerPlay checks that a tester opened your game for a real session rather than just installing it, and testers who go quiet are removed from the round.
Turn the test into your production application
When you apply for production, Play Console asks how you tested, what feedback you got and what you changed. For a game that's easy to answer well: crashes on specific devices, levels that were too hard, controls that confused people. Write those down during the test, ship fixes as new builds, and you'll have real answers instead of a vague paragraph.
Top comments (0)