You are going to publish a no-code game Play Store build, and you are going to do it in a way that survives Play Console checks (package, signing, versioning) the first time.
Start with this fast pre-flight checklist: export AAB, create the Play Console app, use an internal test track, prepare store listing, set pricing and ratings, then staged rollout. Verify you have a developer account (one-time $25 fee) and that your export uses the Android App Bundle format.
Check these exact values inside your exported Android config before upload so you catch the two common blockers: package name drift and unchanged version codes.
android {
defaultConfig {
applicationId "com.yourstudio.yourgame" // must be globally unique, never change after release
versionCode 2 // must increase every upload
versionName "1.0.1" // human-readable
}
}
In your authoring tool these map to package and version fields; in the console they are the application identity. Mobile constraints matter: target mid-range memory limits, reduce draw calls, minimize overdraw, and avoid background work that kills battery on 60–120Hz screens.
Common beginner mistakes you’ll avoid: building with debug settings, forgetting license keys, changing the package name between builds, re-uploading the same versionCode, and enabling unused services. The same identifier, signing, and version rules hold when you move from no-code into Unity; use Unity’s Android docs as a cross-check.
Pre-build setup in Buildbox so Google Play accepts your first upload
Before you export an Android bundle, verify the app identity and licence key inside your authoring tool so the console accepts the upload.
Retrieve the licence key from the google play developer console: sign in, create the application, then click Get licence key and copy the string under YOUR LICENCE KEY FOR THIS APPLICATION. Paste that exact string into Buildbox → Project Settings → Google Play Store → Licence Key.
Choose Android App Bundle (AAB) for new releases; keep APK only for local device testing. Set a permanent package name in reverse-domain form and never change it after a public release.
Enable Google Play Game Services only if you ship leaderboards. In the left menu, add a new game, upload the 512×512 icon and 1024×500 feature graphic, link the Android app by package name, authorize, then copy the Application ID into Buildbox. Repeat for each leaderboard ID and publish Game Services separately via Ready to test → Publish Game.
Run a quick mobile performance pass: shrink textures, watch memory at loading screens, cut effects that spike draw calls or overdraw smaller screens, and curb battery-draining particle systems. Common first-upload blockers and fixes:
- Wrong package name — set it once and keep it stable.
- Missing licence key — paste before export.
- Debug build settings — export a release build.
- Wrong file type — use AAB for first uploads.
Buildbox to Google Play: upload your AAB and create a test track
This handoff is where your exported AAB becomes a testable build inside the console and you validate installs without risking a wide release.
Create the application and pick a track
In the console click Create application, choose the primary language, and enter your title. Then open the Release section from the menu left and pick Internal testing as your first track.
Upload the Android App Bundle
Click Create release, then in App bundles click Upload and select the AAB file. Wait until the screen lists the bundle before you touch other controls.
Write short “What’s new” notes: crash fixes, input tweaks, and performance gains for testers.
App signing prompt and next steps
When the google play app signing prompt appears click Continue to accept the default signing flow unless you already manage your signing key. Signing choices are sticky.
- Common blockers: package name collision — upload fails; fix by using a unique package and rebuild the AAB.
- Version reuse — console warns you uploaded the same version twice; increment versionCode and export again.
After saving, allow a few hours for propagation. Then install from the test track, check first-run permissions, verify frame pacing on a mid-range screen, and confirm menus don’t spike battery.
Store listing, ratings, and monetization setup that won’t get your game rejected
Treat your store listing as a technical checklist: accurate fields, exact assets, and correct identifiers avoid rejections. Small errors in the listing often block rollout or cause poor first impressions for users. Follow exact field limits and match identifiers in your build.
Store listing fields that matter for search
Title: 30 characters. Use a readable name and one high-intent keyword. Short description: 80 characters — state core gameplay honestly. Full description: front-load the pitch in the first 3–5 lines, then add readable feature bullets. Avoid keyword stuffing; it hurts conversion and reviews.
Required graphics and exact sizes
Lock assets to the console specs: 512×512 hi-res icon (transparency allowed) and 1024×500 feature graphic (no transparency). Upload screenshots by device category so the page renders correctly across screens.
Content rating workflow
Pick GAME, answer the questionnaire honestly, Save, then Calculate rating and Apply Rating. An incorrect rating can trigger policy checks or reduce reach, so be accurate with violence, in-app purchases, and user interactions.
Pricing, distribution, and in-app products
Free vs Paid is permanent for the application. Choose countries intentionally and complete consent checkboxes (content guidelines and US export laws) to avoid compliance stalls.
- IAP types: managed for restoreable items (e.g., Remove Ads), unmanaged for consumables (e.g., coin packs).
- Use lowercase letters, numbers, and periods for product IDs and copy them exactly into your authoring tool.
- Upload an initial build before IAP setup appears in the console.
License testing and launch practice
Add tester Gmail accounts (not the developer login) under license testing, save, and expect up to 24 hours for billing activation. Waiting is a common trap—schedule tests early.
Industry practice: run a “release candidate” checklist (install, first-run, offline mode, billing flow, 30-minute crash-free run, thermal check) and use a staged rollout mindset so you can halt distribution if issues appear. When you move beyond authoring tools, consult the Unity Manual: Android build/publishing pipeline as the canonical reference; the same identity, signing, and version rules apply.
| Asset | Size / Limit | Transparency | Notes |
|---|---|---|---|
| Hi-res icon | 512×512 | Allowed | Use clear branding; avoid tiny text |
| Feature graphic | 1024×500 | Not allowed | No transparency; bold imagery for page header |
| Promo graphic | 180×120 | Depends | Optional; used in some placements |
| Screenshots | Device buckets | N/A | Upload phone, 7-inch, and 10-inch sets |
Conclusion
Lock your app identity, increment the version, then validate via an internal test track. This short checklist prevents the last-minute failures that waste time and block uploads.
Key items: a stable package name, a new version code, the correct AAB file, accepted app signing, internal test validation, and a finished store listing. Follow each step deliberately and treat promotions as release candidates.
Avoid the three biggest time sinks: changing the name or package between builds, reusing a version number, and assuming billing or testing updates appear instantly. When something fails, read the console error, fix package/version/signing, then rebuild.
If you move toward programming or scripting with Unity, keep the same identity and signing discipline and follow Unity’s Android publishing docs. Expect hours for global visibility and plan announcements after propagation.
