How to Publish Your First Android App on Google Play: A Complete Checklist

Publishing your first Android app on Google Play involves more moving parts than most first-timers expect. It's not just "upload the APK and wait." Between account setup, verification, policy compliance, closed testing, and the store listing itself, there are dozens of steps — and missing any one of them stalls your launch.

This is the complete checklist, in order, from zero to live on the Play Store.

Phase 1: Developer account setup

• [ ] Decide: individual or organization account. Individual is faster to verify; organization requires D-U-N-S verification but looks more professional and is required if you're publishing as a company. Choose based on your real situation — don't register as an individual and operate as a company.
• [ ] Pay the one-time registration fee ($25 for individual accounts at the time of writing; verify current pricing in Play Console).
• [ ] Complete identity verification. Government ID for individuals; D-U-N-S plus business verification for organizations. Start D-U-N-S acquisition immediately if you need it — it can take weeks.
• [ ] Keep your verification documents consistent. One canonical name, one address format, everywhere.

Phase 2: Build a publishable app

• [ ] Target the required API level. Google mandates a minimum target SDK for new apps, updated annually. Check the current requirement in Play Console — uploading against an old target gets an instant rejection.
• [ ] Build an Android App Bundle (AAB), not an APK. AAB is required for new apps. Configure signing properly and back up your keystore/upload key. Losing your signing key is a launch-ending disaster with a painful recovery process.
• [ ] Minimize permissions. Every permission must be justifiable. Location, SMS, call log, and accessibility permissions face heightened review — if your app doesn't genuinely need them, remove them.
• [ ] Audit all third-party SDKs. Know what each SDK does, what data it touches, and what permissions it pulls in. SDK-driven violations are among the most common first-publication failures.
• [ ] Test on real devices, not just emulators — across a few OS versions and screen sizes.

Phase 3: Policy compliance pre-check

• [ ] Write your privacy policy first, before you need it. It must be hosted at a public URL and linked in Play Console. It must accurately describe data collection, including SDK-driven collection.
• [ ] Complete the Data Safety section honestly. List every data type collected or shared, including by SDKs. Mismatches between the form and reality are treated as deception.
• [ ] Answer the content rating questionnaire (IARC) truthfully.
• [ ] Check the ads declaration. If your app contains ads — including house ads or cross-promotion — declare it.
• [ ] Review category-specific policies. News apps, health apps, financial apps, and apps for children each have additional requirements. Know yours.
• [ ] Confirm you own or license every asset — images, audio, fonts, brand references.

Phase 4: Store listing

• [ ] App icon (512×512 PNG) — distinctive, legible at small sizes.
• [ ] Feature graphic (1024×500) — required.
• [ ] Screenshots — minimum 2, across phone (and tablet/Chromebook if you support them). Show real app UI, not mockups that misrepresent functionality.
• [ ] Short description (80 chars) and full description (up to 4,000 chars). Describe what the app actually does. No keyword stuffing — Google penalizes it, and it reads terribly.
• [ ] App category and tags. Choose accurately; miscategorization triggers review flags.
• [ ] Contact details — a real support email (and website if you have one). "No-reply" addresses erode trust and can draw scrutiny.

Phase 5: Closed testing (new accounts)

• [ ] Upload your AAB to a closed testing track and roll it out.
• [ ] Recruit 12+ testers (aim for 15–20 for buffer) and get them opted in via the Play Console opt-in link. They must install from the testing link — sideloads don't count.
• [ ] Run the test for 14 continuous days immediately before applying for production. Monitor the opted-in count in Play Console; don't assume.
• [ ] Keep testers engaged — real usage, at least one mid-test update, feedback collection. Fix crashes promptly.
• [ ] Apply for production access once the 14-day window with 12+ testers is complete.

Phase 6: Production rollout

• [ ] Don't go 100% on day one. Use staged rollout (start at 10–20%) to catch production-only issues before they reach everyone.
• [ ] Monitor crash reports and ANRs in Play Console and Android Vitals from hour one.
• [ ] Respond to early user reviews — especially bug reports. Early responsiveness shapes your rating trajectory.
• [ ] Keep the closed testing track as your staging environment for future updates.

Phase 7: The first 30 days after launch

Getting approved isn't the finish line. The first month sets your app's trajectory:

• [ ] Watch Android Vitals daily for the first two weeks — crash rate, ANR rate, and excessive wakeups. Google uses vitals thresholds in ranking and can limit visibility for poor-performing apps.
• [ ] Ship a quick follow-up update (1.1) within the first two weeks addressing the most common feedback. It signals an active, maintained app to both users and Google.
• [ ] Answer every early review, especially critical ones. A developer response on a 1-star review complaining about a bug — followed by a fix — converts detractors and demonstrates maintenance to anyone reading reviews.
• [ ] Track your key metrics: install conversion rate from the store listing (impressions → installs), day-1 and day-7 retention, and crash-free users. If listing conversion is low, your screenshots or description need work, not your app.
• [ ] Expand testing tracks: move your trusted testers to an open testing track for broader pre-release feedback on future updates.
• [ ] Calendar Google's annual deadlines: target API level bumps and policy update windows. Put reminders 90 days out — scrambling at the deadline is how compliance mistakes happen.
• [ ] Back up everything: signing keys, Play Console user list, listing assets, privacy policy source. Store them where the business — not just one laptop — can reach them.

The mistakes that delay first launches most

1. Starting verification late. D-U-N-S acquisition and identity review take weeks; developers who start them after finishing the app sit idle.
2. Treating closed testing as a formality. Fake testers and broken builds get production applications rejected — and sometimes the account flagged.
3. Privacy policy as an afterthought. No policy URL, or a generic template that doesn't describe your actual data practices, is one of the most common hard blocks.
4. Permission bloat. Requesting location "just in case" invites review delays or rejection.
5. Signing key loss. Back up the keystore in two places, now.

Launch day is the starting line

Getting approved feels like the finish, but it's really the beginning of the maintenance phase: monitoring vitals, shipping updates through your testing track, responding to reviews, and keeping up with Google's annual target-API and policy changes. The developers who thrive on Google Play build these habits from the first release.

If you'd rather not navigate the account setup, verification, and closed-testing gauntlet alone the first time, Play Console Store helps developers get from signup to a live listing — handling Play Console configuration, verification walkthroughs, and structured closed-testing cohorts so your first launch goes through cleanly. Either way, work the checklist in order: every skipped step is a delay you'll pay for later.