A pre-launch checklist for your first Android release

Everything to verify before your first Google Play production release — store listing, build config, policies, testing, and launch-day monitoring.

Your closed test is done, production access is approved, and the rollout button is right there. Before you press it, run this checklist. Every item is something that has delayed or damaged a real first launch.

Build and release configuration

• Release build is signed with Play App Signing enrolled — and your upload key is backed up somewhere safer than the laptop that made it.
• versionCode is incremented past your closed-testing builds.
• ProGuard/R8 shrinking is tested on the release build, not just debug — obfuscation breaks reflection-based code in ways debug builds never show.
• targetSdkVersion meets Google Play's current minimum requirement (Google raises it every year; check the deadline).
• App size is sane: verify the AAB download size in Play Console, not your local APK size.

Store listing

• Title, short description, and full description are keyword-considered but human-readable — Play Store ranking weighs the title and short description heavily.
• Screenshots are current, show real UI, and the first two make sense as a pair (most visitors never swipe further).
• Feature graphic and icon look right at small sizes on a real phone.
• Category and tags match what the app actually does.
• Contact email is one you actually monitor.

Policy and compliance

• Privacy policy is live at a stable URL and linked both in Play Console and inside the app.
• Data safety form matches your real data collection, including every third-party SDK.
• Content rating questionnaire is answered accurately.
• All permissions in the manifest are ones the app genuinely uses.
• If the app targets children or handles sensitive categories (health, finance), the extra policy requirements for those categories are reviewed.

Quality gates

• Every crash reported during closed testing is fixed or consciously deferred.
• The app is tested on a low-end device and on the oldest Android version you support — not just your flagship.
• First-run experience works on a completely fresh install with no cached state.
• Offline behavior fails gracefully instead of crashing.
• Crash reporting (Crashlytics, Sentry, or Play Vitals) is confirmed to be receiving events from the release build.

Launch day and the week after

1. Use a staged rollout — start at 10–20% so a bad crash affects a fraction of users and you can halt the rollout.
2. Watch Android Vitals daily: crash rate and ANR rate above threshold suppresses your visibility in Play search.
3. Reply to early reviews quickly — response rate and rating trajectory in the first weeks influence long-term ranking.
4. Keep your closed testing track alive and push the next release there first. You already have the tester habit; keep using it.

A first launch is never perfect, but nearly every launch-day disaster is on this list. Work through it once, seriously, and your production rollout becomes an anticlimax — which is exactly what you want it to be.