Short answer: between a finished build and a live Google Play listing there are about a dozen steps: a verified developer account, a testing phase, a signed app bundle that targets a recent Android version, a store listing, and a set of declarations covering privacy, data safety, content rating, ads and target audience. Allow two to four weeks of calendar time for a first release on a new account. Most of that is waiting for verification, testing periods and review, not work.
Policies change. Google revises Play requirements several times a year. This guide describes the steps and what each one is for, and avoids quoting thresholds that are likely to move. Where a number matters, Play Console and the Play Console Help pages are the source of truth. BBR publishes on Google Play under the developer name BBR Labs; what follows reflects releasing our own apps, Grow.io and Live Gold & Silver Prices.
The checklist at a glance
- Developer account created in the owner's name, identity verified, contact details confirmed
- Account type chosen deliberately: personal or organisation
- Closed testing requirement met, if it applies to your account
- Release build produced as an Android App Bundle, enrolled in Play App Signing, upload key backed up
- Target API level meets the current Play requirement
- Store listing complete: name, descriptions, icon, feature graphic, screenshots, category, contact details
- Privacy policy published at a public URL and linked in the listing and the app
- Account deletion available in the app and at a web URL, if the app has accounts
- Data safety form completed, including what third-party SDKs collect
- Content rating questionnaire, target audience, ads declaration and other app content declarations submitted
- In-app products or subscriptions created, activated and tested with licence testers, if you sell anything
- Reviewer access instructions supplied if the app needs a login
- Pre-launch report checked; production release started as a staged rollout
- Crash and ANR rates, reviews and policy emails watched after launch
1. Developer account and verification
Register at Play Console with a Google account that belongs to the business, not to an individual employee or contractor. There is a one-off $25 registration fee. You then choose between two account types:
| Personal account | Organisation account | |
|---|---|---|
| Who it is for | Individuals and hobby projects | Registered companies and other legal entities |
| Verification | Identity document, contact email and phone | The above plus proof of the organisation, which includes a D-U-N-S number |
| Testing requirement before production | Applies to newly created personal accounts | Does not apply |
| What users see | Developer name and certain contact details | Organisation name and contact details, including address |
If you have a company, open an organisation account. Obtaining a D-U-N-S number is free in most countries but can take days or weeks, so start that first. Verification as a whole is the step most likely to delay a launch, because it is outside your control.
Be aware that some of the contact details you enter are displayed publicly on your store listing. Use a business address and a support mailbox, not personal ones. If you will sell paid apps or in-app products, you also need a payments profile, with bank and tax details, linked to the account.
2. The closed-testing requirement for new personal accounts
Since late 2023, newly created personal developer accounts have to run a closed test before they can apply for production access. In outline: you upload a build to the closed testing track, invite testers by email address or Google Group, a minimum number of them must opt in and stay opted in for a continuous period of roughly two weeks, and you then answer some questions about the test when applying for production. Google has already adjusted the required number of testers once, so check the current figure in Play Console.
Practical advice:
- Recruit more testers than the minimum. People drop out, and a lapse can reset the clock.
- Testers need to opt in through the link and install the app from Play. Agreeing by email is not enough.
- Ship at least one update during the test and respond to feedback. The production application asks what you learned.
- Be wary of services that sell testers. Real users from your own network give you useful feedback and carry no policy risk.
Even when the rule does not apply to you, the testing tracks are worth using. Internal testing delivers a build to a small named list within minutes, which makes it the natural place to check a release on real devices exactly as Play will deliver it. Closed and open testing let a wider group try a version before everyone gets it.
3. Build, app signing and target API level
App bundle and Play App Signing
New apps are uploaded as an Android App Bundle (.aab), not an APK, and use Play App Signing. Google holds the app signing key that devices trust. You sign uploads with a separate upload key. The benefit is that a lost or compromised upload key can be replaced through Play Console support, whereas in the old model losing the key meant never updating the app again.
- Generate the upload keystore once, store it and its passwords in a password manager or secrets vault, and keep a second copy somewhere else.
- If an agency builds the app, make sure the keystore is handed over with the source code. It is part of what you own.
- Third-party services such as Google sign-in, Firebase or Maps identify your app by certificate fingerprint. With Play App Signing, the fingerprint of the app signing key shown in Play Console has to be registered with those services as well as your upload key's. Forgetting this is a classic cause of “login works in testing but not from the store”.
Version codes
Every upload needs a version code higher than any previous one, on any track. Agree a scheme early. This applies equally to React Native and Capacitor projects, where the version lives in the Android project's Gradle file and not in package.json.
Target API level
Google requires new apps and updates to target a recent Android API level, and moves that requirement forward every year. If the target is too old, Play Console refuses the upload. Apps that fall far behind eventually stop being offered to users on newer Android versions. Check the current level in the Play Console Help before release, and treat the annual bump as a fixed item in your app maintenance budget. Raising the target can change behaviour, for instance around notification permission, exact alarms, background work and edge-to-edge display, so test after raising it.
Permissions
Request only what a visible feature needs. Certain permissions, such as background location, SMS and call log access, or broad file access, require a declaration form and sometimes a video showing the feature. Remove permissions that a library added and you do not use. They will otherwise have to be explained in review and in the data safety form.
4. Store listing assets
| Asset | Specification | Advice |
|---|---|---|
| App name | Up to 30 characters | Brand plus a plain descriptor. Avoid claims such as “best” or “#1”, and avoid emoji; listing policy prohibits them |
| Short description | Up to 80 characters | One sentence saying what the app does. It is the text most people read |
| Full description | Up to 4,000 characters | Features in plain language. No keyword lists, no references to other apps |
| App icon | 512 × 512 PNG | Must match the icon inside the app |
| Feature graphic | 1,024 × 500 | Shown in promotional placements; keep text minimal and away from the edges |
| Phone screenshots | At least two | Real screens from the app. Add tablet screenshots if you support tablets |
| Category, tags, contact email | Required | The contact email is public. A website is optional but expected |
If you serve more than one language, add translated listings. Play shows users the listing in their language when one exists. Grow.io's interface is available in four languages, and localised listing text is a small extra task next to localising the app itself.
5. Privacy policy and account deletion
A privacy policy URL is required in the listing, and should also be reachable inside the app. It has to be a public web page, not a PDF and not behind a login, and it has to name the app or developer, describe what data is collected and shared, including by SDKs such as ad and analytics libraries, and give a contact point. A generic template that does not mention advertising identifiers will contradict your data safety form if the app shows ads.
If users can create an account in the app, Google requires two things: a way to request deletion of the account and its data from inside the app, and a web URL where the same request can be made without reinstalling the app. That URL is entered in the data safety section. The page should name the app, explain the steps, and say what is deleted and what is retained and for how long. Build this during development. Discovering it at submission time means an unplanned backend task.
6. The data safety form
The form produces the “Data safety” section users see on your listing. Every app must complete it, including apps that collect nothing. You declare, by data type, what is collected, what is shared with third parties, whether each use is required or optional, the purposes, whether data is encrypted in transit and whether users can request deletion.
The part that catches people out: you are responsible for what the SDKs in your app do. An app with no accounts and no backend still collects data, in Google's terms, if it includes an advertising SDK, analytics or crash reporting. The major SDK vendors, including Google for AdMob and Firebase, publish guidance on what to declare. Work through it with the developer who knows which libraries are in the build. Declarations that do not match observed behaviour are a common cause of policy warnings.
7. Content rating, target audience, ads and other declarations
These live under the app content section of Play Console. None takes long, all are mandatory.
- Content rating. A questionnaire about violence, sexual content, language, gambling, user interaction and similar themes. It produces ratings from the regional rating authorities automatically. Answer accurately: an unrated app can be removed, and a misrated one can be re-rated or taken down. Apps with user-generated content or chat should say so.
- Target audience and content. The age groups the app is aimed at. Including children brings the Families policy into play, with strict limits on ads, SDKs and data collection. Do not select young age groups unless the app is really for them, and make sure the listing does not look child-directed by accident.
- Ads declaration. State whether the app contains ads. If it does, a “Contains ads” label appears on the listing. This includes ads served by third-party SDKs and house ads for your other products.
- App access. If any part of the app is behind a login, provide working test credentials and instructions for the reviewer. A reviewer who cannot get in will reject the app.
- Other declarations. Play Console asks whether the app is a news app, a government app, or offers financial or health features, and may ask for more detail depending on the answers. The list grows over time, so go through every item shown for your app.
If the app shows ads
Beyond the declaration, follow the ad placement rules: no ads that appear unexpectedly over the interface or interrupt at moments the user cannot anticipate, and no ads that imitate system dialogs. If you have users in the EEA or UK, Google's advertising products require consent to be collected through a certified consent management platform; AdMob's own consent SDK is the simplest route. AdMob also recommends publishing an app-ads.txt file on the developer website named in your listing, which is quick to do and protects your ad revenue from spoofing.
8. In-app products and subscriptions
Digital goods sold in the app, such as premium features, virtual currency or subscriptions, generally have to go through Play Billing. The business side of that is covered in our guide to monetizing an app. For release, the sequence is:
- Set up the payments profile for the account.
- Upload a build that includes the Play Billing library to any track. Product creation is not available until Play Console has seen one.
- Create products or subscriptions with their IDs, names, descriptions and prices. Choose IDs carefully, because a product ID cannot be changed or reused later. Activate each product.
- Add licence testers under the account settings, so that test purchases are not charged.
- Test the whole lifecycle from a Play-installed build: purchase, cancellation, refund, restoring purchases on a new device, a pending payment, and what the app shows when the network fails mid-purchase.
- Acknowledge every purchase in code. Unacknowledged purchases are refunded automatically after a few days.
Google also requires apps to use a reasonably recent version of the Billing library, and retires old versions on a schedule. It is another item for the annual maintenance list.
9. Review, pre-launch report and staged rollout
Review. Every new app and update is reviewed. Timing is not guaranteed. Established apps often pass within a day or two, first releases and new accounts can take longer. If you need to go live on a particular date, submit early and use managed publishing, which holds an approved release until you press the button.
Pre-launch report. When you upload to a testing track, Play runs the build on a set of real devices and reports crashes, accessibility problems and security warnings, with screenshots. It costs nothing and regularly finds device-specific layout problems. Read it before promoting a build to production.
Staged rollout. Release to a percentage of users first, then increase it over several days while watching crash reports. If something is wrong, you can halt the rollout so no more users receive that version. Note what halting does not do: it does not downgrade people who already updated. There is no true rollback on Play. The fix is a new build with a higher version code, which is a good reason to keep the first percentage small.
Countries and pricing. Choose the countries where the app is available. If you sell products, review the generated local prices, since automatic conversion sometimes produces awkward figures.
10. After launch: vitals, reviews and policy mail
- Android vitals. Play Console reports crash rate and ANR (“app not responding”) rate, overall and per device model. Google publishes bad-behaviour thresholds, and apps that exceed them can be shown less prominently or carry a warning on their listing. Check vitals daily in the first week and after every release. A separate crash reporting tool gives you stack traces quickly enough to act on.
- Ratings and reviews. Reply to reviews, especially negative ones that describe a fixable problem. Users are notified of replies and can change their rating.
- Asking for ratings. Use the in-app review API and ask sparingly. In Live Gold & Silver Prices the prompt waits until the user has had several sessions across more than one day, and backs off for a week if they decline. Google limits how often the dialog can appear anyway, so never make an interface element depend on it showing.
- Policy emails. Warnings go to the account owner's address with a deadline. Make sure that mailbox is read. Missed deadlines are how healthy apps get removed.
- Keeping it current. Target API level, Billing library, ad SDK and consent requirements all move yearly. An app that is never updated eventually loses visibility.
A realistic timeline
| Step | Hands-on work | Waiting |
|---|---|---|
| Account registration and verification | An hour or two | Days; longer if a D-U-N-S number has to be obtained |
| Closed test, where required | A few hours recruiting and supporting testers | About two weeks, continuous |
| Signing setup and release build | Half a day the first time | None |
| Listing text and graphics | One to three days | None |
| Privacy policy, deletion page, data safety and other declarations | One to two days | None |
| In-app products and purchase testing | One to three days | None |
| Review | None | Hours to more than a week |
| Staged rollout to 100% | Monitoring | Several days, by choice |
The waiting steps can overlap with development. Open the account and start verification when the project starts, not when the build is finished. Our guide to how long an app takes to build shows where release preparation sits in the overall schedule.
This article covers Google Play only. Apple's process has the same themes with different forms: App Store Connect, privacy nutrition labels, review guidelines and TestFlight. If you are still deciding whether you need a store app at all, read when a progressive web app is enough. And if you would rather hand the whole release to someone who has done it before, it is part of BBR's mobile app development service.