How to publish an app on Google Play: the complete 2026 checklist

Publishing on Google Play looks simple: upload a file, write a description, press publish. In practice, first-time publishers regularly lose one to three weeks to account verification, a mandatory testing period they did not know about, or a policy declaration that got the app rejected. This checklist walks through every step in the order you will meet it, so your launch date is one you actually hit.

Google updates Play policies frequently. Treat this as a map, and always confirm the current requirement inside Play Console before you submit.

Step 1: Choose the right developer account type

Google Play offers two kinds of developer account, and the choice affects your launch timeline more than anything else on this list.

Aspect	Personal account	Organisation account
Who it is for	Individual developers and hobbyists	Registered businesses, companies, NGOs
Verification	Government ID and contact details	Business details plus a D-U-N-S number matching your legal entity
Testing before production	New personal accounts must complete a closed test before production access	No mandatory closed-testing period
Developer name shown	Your name, or a chosen developer name with verified details behind it	Your organisation name
Best for a business app	Rarely	Almost always

If you are a company, register as an organisation. Getting a D-U-N-S number can take anything from a few days to a couple of weeks, so apply for it early. Both account types pay a one-time registration fee.

Step 2: Plan for the closed testing requirement

New personal developer accounts must run a closed test with a minimum number of opted-in testers for a continuous period (at the time of writing, 12 testers for 14 days) before they can apply for production access. Google then reviews your answers about the test before granting access.

• Recruit real testers before you start, not after. Friends, family and early customers work well.
• Testers must stay opted in for the whole period; if too many leave, the clock effectively resets.
• Ship at least a couple of updates during testing and act on feedback. Google asks what you learned.

Even with an organisation account, a closed or internal test is good practice. Internal testing lets up to 100 people install builds within minutes.

Step 3: Build the release correctly

Android App Bundle

New apps must be uploaded as an Android App Bundle (AAB), not an APK. Google Play generates optimised APKs for each device from the bundle.

Play App Signing

With Play App Signing, Google holds your app signing key and you sign uploads with a separate upload key. Keep the upload keystore and its passwords in a secure, backed-up location with at least two people who know where it is. Losing the upload key is recoverable through Play Console support; losing an old self-managed signing key was historically not, which is why Play App Signing is the standard.

Target API level

Google Play requires new apps and updates to target a recent Android API level, typically within about a year of the latest major Android release. Check the current requirement in Play Console before you build, because an outdated target blocks the upload entirely. Raising the target can change behaviour (permissions, background limits, notifications), so test properly after bumping it.

Versioning

Every upload needs a higher versionCode than the last. Keep versionName human-readable, such as 1.0.0, and use it consistently in release notes.

Step 4: Complete the App content declarations

The App content section in Play Console is where most rejections originate. Fill each item carefully and truthfully.

• Privacy policy: required for effectively every app. It must be hosted on a public, non-PDF web page, reachable from both the listing and inside the app, and must accurately describe what you collect.
• Data safety form: declare what data your app and every bundled SDK collect or share, why, and whether it is encrypted in transit and deletable. Analytics, crash reporting, ads and login SDKs all count. Mismatches between the form and actual behaviour are a common enforcement reason.
• Account deletion: if users can create an account in your app, you must let them request deletion of the account and associated data from within the app, and also provide a web link where they can request deletion without reinstalling it.
• Content rating: complete the rating questionnaire honestly. It generates regional ratings automatically.
• Target audience and content: declare the age groups you target. Including children brings extra Families policy requirements.
• Ads declaration: state whether the app contains ads, including from SDKs.
• App access: if features sit behind a login, give reviewers working test credentials and instructions. Missing access details is a frequent cause of rejection.
• Sensitive permissions and special categories: SMS, call log, all-files access, background location, accessibility services, and exact alarms need justification or a declaration form. Financial, health, news and government-related apps have additional declarations.

Step 5: Prepare store listing assets

• App name: up to 30 characters. No keyword stuffing, no "Best" or "#1" claims, no emoji.
• Short description: up to 80 characters that say clearly what the app does.
• Full description: up to 4,000 characters. Write for humans; natural keyword use helps search.
• App icon: 512 x 512 PNG.
• Feature graphic: 1024 x 500, shown in several places on Play.
• Screenshots: at least two phone screenshots; add tablet screenshots if you support large screens. Show real app UI with short captions.
• Contact details: a support email is required; a website is strongly recommended.
• Category and tags: choose accurately, since they affect discovery.

Metadata must reflect what the app actually does. Misleading screenshots or descriptions can cause rejection or later suspension.

Step 6: Test before you submit

1. Review the automatic pre-launch report in Play Console, which runs your app on real devices and flags crashes, accessibility and security issues.
2. Test on at least one low-RAM budget phone and one older supported Android version.
3. Check login, payments, notifications and deep links on a release build, not just a debug build.
4. Check the Android vitals thresholds for crash and ANR rates once testers are active; poor vitals reduce visibility on Play.

If you need a structured approach, our QA and testing team runs device-matrix testing for exactly this purpose.

Step 7: Release with a staged rollout

When you promote a release to production, choose a staged rollout rather than 100 percent. Start at a small percentage of users, watch crash rates, ANRs and reviews for a day or two, then increase. If something breaks, you can halt the rollout and ship a fix while most users remain on the previous version.

Review times vary. First submissions and apps in sensitive categories can take several days; routine updates are often faster. Build that buffer into any launch announcement.

After launch

• Reply to reviews, especially negative ones, within a day or two.
• Watch Play Console policy emails closely; deadlines for new requirements are usually given months in advance.
• Plan a yearly target API update as a standard maintenance task. Our maintenance plans include it.
• Consider the App Store next. Apple's review is different in character, so read why apps get rejected by the App Store before you submit there.

Want someone to handle the launch?

Lead Infosoft has published and maintained many Android apps and knows the Play Console process end to end, from account setup to staged rollout. Whether we build your Android app or you only need help getting an existing build through review, get in touch and we will help you launch without the surprises.