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 (2)
Closed testing với game Unity thường trơn tru hơn app tiện ích vì tester thực sự muốn chơi, không chỉ "check tính năng" xong bỏ qua. Một vài điều mình rút ra từ lần submit trước:
Test track setup: Dùng Internal testing trước để team QA nội bộ catch crash ngay (đặc biệt là IL2CPP build), sau đó mới mở Closed testing cho nhóm external. Google Play yêu cầu ít nhất 20 tester trong 14 ngày — đừng vội đẩy lên Production nếu retention D1/D7 chưa ổn.
Build config: Bật
Development Build+Script Debuggingcho bản test đầu tiên để lấy stack trace chi tiết khi crash. Nhớ tắt trước khi lên Production. Với IL2CPP, crash thường ở native layer (JNI, plugin) — logcat + Firebase Crashlytics bắt bắt buộc.Tester management: Tạo Google Group cho tester, dễ add/remove hàng loạt. Ghi chú rõ trong email mời: "Test bản debug, game có thể lag/crash, báo lỗi kèm device + steps reproduce". Filter feedback: bỏ qua "hay/đẹp", chỉ lấy crash log, ANR, soft-lock, IAP fail.
IAP testing: Dùng license testers (Google Play Console → License testing) để mua miễn phí. Test full flow: purchase → consume → restore purchase sau reinstall. Edge case: mua khi offline, mua trùng item, refund.
App Bundle: Build
.aabthay vì.apk— Play Asset Delivery tự tách asset pack, giảm size initial download. Test `bundletool PS: the tool I meant is on labagent .techSorry what?