Pre-Launch Checklist Before Uploading Your First Closed Testing Build

Before you upload your first closed testing build, lock down the things you can't easily change later (package name, signing setup), build a proper release bundle, and make sure a stranger can open your app and get past the first screen. Most wasted closed-test days come from skipping one of these, not from anything exotic.

This checklist is about the build and the app, not the testing track itself. Google Play rules and Play Console screens change, so treat the details below as a guide and check the current target API requirements and Play Console Help before you submit.

Why this matters more for a closed test

If you have a new personal developer account, your closed test has to run with 12 testers opted in for 14 days in a row before you can apply for production. That is a long window to spend on a build that crashes on launch or asks testers for a login they don't have. Fixing it mid-test is possible, but it costs you days of real testing time and your testers' patience.

1. Things you can't undo: identity

Package name (application ID)

Pick the final one now. Once an app is created in Play Console with a package name, you can't change it.
Don't ship with com.example.*. Use a domain or handle you control.
Check that your applicationId in Gradle matches what you expect, not just the namespace in your code.

App name and developer account details

The app name you create in Play Console can be edited later, but it's easier to settle it now so your store listing, screenshots and tester instructions all match.

2. The build itself

Upload an Android App Bundle

New apps are published with an .aab file, not an APK. In Android Studio use Build > Generate Signed App Bundle, or run ./gradlew bundleRelease.

Version code and version name

versionCode must be higher with every upload. Start at 1 and expect to bump it often.
Choose a versionName testers can quote back to you, like 0.1.0.

Target SDK and minimum SDK

Google requires new apps and updates to target a recent API level, and that level moves over time. Look it up on developer.android.com rather than trusting a blog post, including this one.
Set minSdk deliberately. A very low value widens your device pool but also your bug surface. A very high one may leave testers unable to install.

Build the release variant, not debug

Test the exact variant you upload. Release builds with R8 or ProGuard enabled often break things that work fine in debug: reflection, JSON models, serialization libraries. Add keep rules if you need them, and run through the whole app on the release build before uploading.

3. Signing

Enrol in Play App Signing when Play Console prompts you. You sign uploads with an upload key, and Google manages the app signing key.
Back up your upload keystore and its passwords somewhere safe, outside the project repo. Losing it creates a recovery process you don't want to go through.
If you use Google Sign-In, Firebase or any API restricted by SHA-1, add the Play app signing certificate fingerprint from Play Console too. Otherwise sign-in works on your machine and fails for testers.

The Android developer signing docs cover the details.

4. Declarations Play Console will ask for

Play Console has an app content section with several forms. Which ones block a testing release and which only block production can vary, so check the dashboard tasks for your app. Expect to deal with:

Privacy policy: a public URL that actually loads, and that matches what your app does.
Data safety: list every kind of data collected, including what your analytics, crash reporting and ad SDKs collect. Read your dependencies' docs rather than guessing.
Content rating: a questionnaire. Answer it honestly for the app as it exists now.
Ads declaration: say whether the app contains ads.
Target audience: be careful here. Choosing children as an audience brings extra requirements.
App access: see the next section.

Doing these before the test starts means you won't be scrambling when it's time to apply for production.

5. Make the app testable by strangers

This is the item developers forget most. Your testers are not you. They have different phones, no context, and limited time.

No login wall without credentials. If the app needs an account, either allow easy sign-up or provide a test account. Put credentials in the Play Console app access section and in your tester instructions.
No dependency on your setup. Check the app doesn't point to localhost, a staging server that's offline, or API keys that only work on your device.
Backend is up. If your server sleeps on a free tier, a tester's first request may time out. Wake it and keep an eye on it.
Enough to do for about 20 minutes a day. If testers are expected to use the app daily, there should be something worth returning to: content, features, a few flows to try. A one-screen app gives them little to say.

6. A quick quality pass on real hardware

Emulators miss things. Before uploading, if you can, install the release build on at least one physical phone and ideally two with different screen sizes or Android versions.

Fresh install, then first launch. Does it open without a crash?
Walk the main flow from start to finish.
Deny each runtime permission once. Does the app handle it gracefully?
Rotate the screen, switch to another app and come back, kill and reopen.
Turn on airplane mode mid-flow. Is the error understandable?
Check dark mode and a larger system font size.
Look at Logcat for anything repeating or red.

You won't catch everything, and that's the point of the test. You just want to clear the obvious problems so testers spend their time on the interesting ones.

7. Store listing basics

Your listing doesn't need to be polished for a closed test, but Play Console still wants the essentials: short and full description, app icon, feature graphic, and a few screenshots. Prepare them in advance so you aren't blocked. Keep descriptions accurate, since they're also what reviewers will see later when you apply for production.

8. Prepare your tester instructions

Write a short note you can send with the opt-in link:

What the app does, in one sentence.
The version they should be testing.
Login details, if any.
Two or three things you'd like them to try.
How to send feedback, and what a useful report looks like.

If you need testers, a service like TesterMob can supply them: testers use their own Android phones, use the app for about 20 minutes a day, and write feedback. It costs $9.99 per app, paid once in USDT, and the details are on the pricing page. There's also an optional Android SDK (an .aar file) that shows daily tester activity in your dashboard. If you're going that route, read the developer page first. Either way, nobody can guarantee Google will approve production access, so the real goal is a decent app and honest testing.

The one-page checklist

Final package name chosen and set in Gradle
.aab built from the release variant
versionCode higher than any previous upload
Target SDK meets current Play requirement
Upload key backed up; Play App Signing enabled
SHA-1 for the Play signing key added to Firebase or Google APIs, if used
Privacy policy URL live
Data safety, content rating, ads and audience forms complete
App access credentials supplied if login is required
Backend running and reachable
Release build tested on a real device, with no crash on first launch
Store listing assets ready
Tester instructions written

Once these are ticked, go ahead and upload. If you hit questions about the process, the FAQ covers common ones, and Play Console Help is the authority on anything that has changed since this post was written.