Unity
Google Play closed testing for Unity games
Games are more likely than utility apps to trip Google's engagement quality checks, because a real player's usage pattern looks nothing like someone ticking off a testing obligation. That makes who your 12 testers are matter more for a game than for anything else.
Getting your build onto Play
- 1
Export an Android App Bundle
In Build Settings, switch the platform to Android and enable Build App Bundle (Google Play) so Unity produces an AAB rather than an APK.
- 2
Check your player settings before building
Confirm the package name, version code and minimum API level in Player Settings match what you intend to distribute in Play Console.
- 3
Keep the download inside Play's size limits
Games are usually far larger than utility apps. If your build exceeds the base limit, move large assets to Play Asset Delivery rather than trying to shrink the base bundle.
- 4
Upload and add the tester group
Create the closed testing track, upload the bundle, and add TestSlot's single tester group email to the tester list. One entry covers every TestSlot tester.
What breaks a Unity closed test
- Flat engagement patterns that look suspicious
A real player opens a game repeatedly, plays multiple sessions and progresses through content. A tester fulfilling an obligation opens it once and leaves it backgrounded. Google can tell the difference, and games get looked at harder.
- Oversized builds that never finish installing
If your base bundle is too large, testers on constrained connections or storage silently fail to install - and they still count against your tester total. Play Asset Delivery exists for this.
- Skipping release notes because it is a game
If testers report an unbalanced boss, a confusing UI element, or a difficulty spike, ship the fix and say so in your release notes. That is the record the production access questionnaire is asking you to describe.
The part most Unity developers get stuck on
Shipping the build is the easy half. Google still requires 12 real testers who keep your app installed for 14 consecutive days before it will grant production access.
- TestSlot's pool is real everyday Android users, not developer-swap credit earners - which matters more for a game than for anything else.
- People who actually play mobile games produce authentic session patterns rather than a flat background signal.
- Each tester's phone confirms roughly hourly that your game is still installed, and reports the time actually spent in it.
- Streaks are counted server-side, so a changed device clock does nothing to the count.
Questions
- Does closed testing apply to games as well as apps?
- Yes. Personal developer accounts must complete the same closed test - at least 12 opted-in testers for 14 consecutive days - before Google grants production access, whether the title is a game or a utility.
- Why are games scrutinised more closely?
- Because genuine game usage has a distinctive shape: multiple sessions a day, varying session lengths, engagement that grows as players progress. A tester who installs and ignores the game produces a flat pattern that stands out against that baseline.
- My game is large. Will that cause problems?
- It can. Builds that exceed Play's base size limit should serve their large assets through Play Asset Delivery. Otherwise some testers never complete the install, and a tester who cannot install still counts against your total.
- Do testers actually play the game, or just install it?
- TestSlot measures time actually spent in the app, not just whether it is installed, and the pool is made up of real Android users rather than people trading testing credits. For a game that distinction is the whole point.