How to Launch an Android App on Google Play (2026)

Set Up Your Play Console Account

For a new personal Play Console account, the slow part of launching isn't the build: it's verification and a required test period. Start at least a month before the day you want to announce.

Google's sign-up guide lists a US$25 one-time registration fee, paid by card. You must be at least 18, and you may be asked for a government ID and a credit card, both under your legal name. If that information turns out to be invalid, the fee isn't refunded, so enter your details exactly as they appear on your ID.

Then choose an account type (Google's comparison):

• Personal: Google shows your legal name, country and developer email on Google Play, plus your full address if you monetize. You'll also need to pass the testing requirement below and verify access to an Android device with the Play Console mobile app.
• Organization: you need a D-U-N-S Number, which Google says can take up to 30 days to get. Google shows the organization's legal name, address, developer email and phone number.

Two build rules to check before your first upload. New apps must be published as an Android App Bundle, not an APK. And since August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher, per the target API level requirements; Wear OS, TV, Automotive and XR apps have lower targets.

Testing Tracks and the 12-Tester Rule

Play Console has three testing tracks, described in Google's testing guide:

Testers can't leave public reviews on test versions, so give them a direct way to reach you, such as an email address or a short form.

The testing requirement for new personal accounts

If you created a personal account after November 13, 2023, Google's testing requirements apply: a closed test with at least 12 testers, opted in continuously for 14 days. Anyone who opts out and back in starts a new 14 days. Then you apply for production access from the Dashboard, answering questions about your closed test, your app and its audience, and what you changed before production. Google says that review usually takes seven days or less, and it may ask you to keep testing if you had fewer than 12 opted-in testers or too little engagement.

Treat it as a real beta, not a box to tick:

1. Recruit 15 to 20 people, not 12. Some will never install or will opt out, and falling short means more testing.
2. Use a Google Group for the list. Groups have no size limit; testers join the group, then opt in.
3. Give every tester one task, such as "do [the main job] and tell me where you got stuck". Google asks how testers engaged, not only how many there were.
4. Note what testers reported and what you changed. The production application asks for both.

Our guide to finding beta testers covers where to recruit them. Uploads also get an automatic pre-launch report, device lab capacity permitting, covering stability, compatibility, performance and accessibility. If your app has a login, add a test account in its settings so the crawler gets past the sign-in screen.

Add it up: verification, 14 days of testing and up to a week for production access, all before your release is reviewed. Our 30-day launch plan fits the rest of your preparation around that.

Your Google Play Store Listing

Your store listing is the page every launch post sends people to. Google's store listing help and graphic asset specs set the limits:

Aim for at least four screenshots of at least 1080 pixels (1080 × 1920 portrait or 1920 × 1080 landscape): Google says apps need them to be eligible for its screenshot-based recommendation formats. A preview video is a public or unlisted YouTube link with ads turned off; our guide to making a product demo video covers recording one.

Play's metadata policy is stricter than most launch boards:

• No emojis or repeated special characters in the app name, icon or developer name, and no ALL CAPS unless it's your brand.
• No ranking or promotional claims such as "#1", "Best of Play" or "10% off". Graphics also shouldn't say "free", "new" or "download now".
• No keyword stuffing. Google warns that repetitive or irrelevant keywords can lead to suspension.

A contact email is required too. For writing a pitch people understand at a glance, see writing a launch listing people click.

Data Safety and App Content

Before review, Play Console asks you to complete the App content page, and the Data safety form usually takes longest. According to Google's Data safety guide:

• Every app on a closed, open or production track needs it, even one that collects no data. Only internal testing is exempt, so finish it before your closed test.
• "Collect" means sending data off the device; "share" means transferring it to a third party.
• Your SDKs count. Data collected by analytics, ads or crash-reporting libraries belongs in your declaration.
• Accuracy is on you. Google doesn't verify the form, but apps that misrepresent data and don't fix it face enforcement, such as blocked updates or removal.

A privacy policy is required, linked on your store listing and inside your app. If users can create an account, the account deletion requirement asks for an in-app way to delete it plus a web link for deletion requests, which goes in the Data safety form.

The rest of the App content page is quicker: declare whether the app has ads (it then gets a "Contains ads" label), give reviewers sign-in details for anything behind a login, complete the content rating questionnaire so the app isn't listed as "Unrated", set your target audience, and declare any sensitive permissions, such as SMS or Call Log. The privacy policy generator gives you a draft; check it says the same thing as your Data safety answers.

Review, Release Day and Pre-Registration

With production access, you create a production release and send it for review. Google's publishing status page says some accounts get extended reviews, which may take up to seven days or longer in exceptional cases. Plan for a week.

The detail that catches launch plans out: managed publishing, which holds approved changes until you press publish, can't be used for an app's first release. Version one goes live once it's approved, on Google's schedule rather than yours. So:

1. Send the production release for review one to two weeks before launch day.
2. Let it go live quietly. Open the Play Store link on a phone and in a browser, install it from the store yourself, and watch the first crash data.
3. Announce on your own launch day, once the link works.
4. Turn on managed publishing afterward, so updates go live when you choose.

Pre-registration is the Play Store's waitlist. Per Google's pre-registration guide, people sign up on your listing, get a push notification when you publish, and eligible devices install the app automatically on launch day. A campaign can last 90 days, and new personal accounts must meet the testing requirements first. It's worth it if you have a newsletter or community to send there; with no audience, the page mostly sits unseen.

Where to Launch an Android App

Google Play doesn't hand a new app an audience, so plan where launch-day visitors come from, and give anyone on a laptop a page with screenshots and the Play Store link.

1. Your closed testers and pre-registered users, first. They know the app, and their early ratings come from real use.
2. Product Hunt, if you can bring people with you on a single day.
3. Communities such as r/SideProject, Indie Hackers and subreddits for your app's niche. Answer questions first and follow each community's rules; see how to launch on Reddit.
4. Launch boards with longer windows, such as Peerlist, Fazier and Hauntboard, where a person reviews every launch and its page views and visits are shown in public.
5. X: our guide to announcing your launch on X covers the posts.

Shipping on iPhone too? Our guide to launching an iOS app covers the App Store side. One launch day for both lets a single announcement do double duty, but only if both stores approve you in time.

A message for your closed testers once the app is live:

Launch boards usually show wide images, so portrait screenshots need a background around them. The launch asset resizer pads them, and the launch post generator drafts a post for each community.

Ratings, Vitals and Staged Rollouts

Google's ratings help page says the rating shown on Google Play is weighted toward more recent ratings, so a rough first week can be outgrown. The rules for asking come from the In-App Review API docs:

• Use the In-App Review API, which lets people rate without leaving your app, once they've used enough of it to give useful feedback.
• No questions first, such as "Do you like the app?" or "Would you rate this app 5 stars?"
• No "Rate us" button for it. A time-bound quota means the card may not appear, so a button should open your Play Store page instead.
• Reply to reviews. You get one public reply per review; the reviewer is notified and can update their rating at any time.

Watch Android vitals in launch week. Above a user-perceived crash rate of 1.09% or ANR rate of 0.47% overall, or 8% on a single phone model, Play may reduce your app's visibility and show a warning on your listing (Android vitals). It looks at the last 28 days, so one bad build can follow you for weeks.

Fixes go out as updates, which can use staged rollouts: release to a percentage of users, raise it yourself (it never rises automatically) and halt it if something breaks. Staged rollouts can't be used for a first release, one more reason to let version one go live before you announce.

Then read what to do after launch day, and once your app is live, launch it on Hauntboard for a permanent page that search engines and other makers can find.