The build is rarely what slows down a Google Play launch. You register a Play Console developer account (US$25, paid once), upload a signed Android App Bundle, fill in the store listing and the policy declarations, and then wait for review.
The waiting is the long part. Personal accounts created after November 13, 2023 must run a 14-day closed test with 12 testers before they get production access, and review takes from a few hours to seven days, longer in exceptional cases.
There is one hard deadline on the build side. Since August 31, 2026, Google Play Console Help requires new apps and updates to target Android 16 (API level 36), with lower floors for Wear OS, Android Automotive OS, Android TV and Android XR.
What are the steps to publish an app on Google Play?
Everything starts with the developer account, and the order after that mostly holds.
- Register a Play Console developer account and pay the one-time US$25 fee.
- Create the app in Play Console with its name, package name, default language, free or paid status and contact email.
- Build a signed release Android App Bundle (.aab) that meets the current target API level.
- Fill in the store listing: name, descriptions, icon, feature graphic and screenshots.
- Complete the App content page: privacy policy, ads declaration, Data safety form, content rating and target audience.
- Upload the bundle to a testing track. Personal accounts created after November 13, 2023 also run a closed test here.
- Create the production release, set a rollout percentage and send it for review.
- Fix anything the review flags, then resubmit.
The build itself is the quick part. The D-U-N-S lookup (companies) and the closed test (new personal accounts) are where the calendar goes, and review comes after both.
One choice in step 2 cannot be undone, so don’t rush it. Package names are unique and permanent, and Google Play does not let developers delete or reuse them (Play Console Help).
Personal or organization: which developer account should you register?
A registered business should use an organization account. Individuals get a personal one, and that’s about the only decision here. Both pay the same one-time US$25 fee, so the real difference is time.
Organization accounts skip the closed test and wait on a D-U-N-S number instead. Personal accounts created after November 13, 2023 have to pass the closed test before they get production access, which honestly makes them the slower route.
| Attribute | Personal account | Organization account |
|---|---|---|
| Registration fee | US$25, one time | US$25, one time |
| Identity proof | Government ID and credit card under your legal name | D-U-N-S number and organization details |
| Device verification | Required, through the Play Console mobile app | Not listed as required |
| Closed test before production | 12 testers for 14 days | Not required |
| Main delay | 14-day closed test | D-U-N-S lookup |
The table follows Play Console Help for account setup and for testing requirements. Neither path is instant, since the closed test alone needs 14 continuous days.
If you can’t find enough reliable testers, a closed testing service such as PrimeTestLab can supply 12 to 25 real testers who stay opted in for the full 14 days.
What do identity and organization verification involve?
Personal accounts need a valid government ID and a credit card, both under your legal name. If that information turns out to be invalid, Google does not refund the registration fee. The account owner also confirms access to an Android device through the Play Console mobile app before publishing.
Organizations need a D-U-N-S number from Dun & Bradstreet, plus organization details that match that record. The request is free, but the lookup runs on Dun & Bradstreet’s schedule, so I’d start it before registering anything else.
Payment goes through Mastercard, Visa, American Express, Discover (US only) or Visa Electron (outside the US only). Prepaid cards are not accepted.
What does Android developer verification add for Play developers?
Over 99% of apps on Google Play were registered automatically under Android developer verification, according to the Android Developers Blog (June 2026, updated July 15, 2026).
Play registers apps from the package name and signing key already shared with Google. An app that misses automatic registration shows up on the Play Console Home page, where you register it by hand.
Google’s July 2026 update set September 30, 2026 as the date to finish this, and warned that unregistered apps risk removal from Google Play. That date has passed, so check the Home page now.
Registration is required from September 30, 2026 in Brazil, Indonesia, Singapore and Thailand, with a global rollout planned for 2027.
Which build format, signing setup and target API level does Google Play require?
Google Play takes new apps only as a signed Android App Bundle, and as of November 2026 the app has to target Android 16 (API level 36) or higher, for new apps and updates alike.
API level 36 has been required since August 31, 2026 (Play Console Help). Wear OS and Android Automotive OS get a lower floor of API 35, and Android TV and Android XR get API 34. Existing apps need API level 35 to stay available to new users on newer Android versions.
The bundle requirement is older. New apps have had to publish as Android App Bundles since August 2021 (Android Developers documentation).
An app bundle hands APK generation and signing over to Google Play. You build and sign the .aab in Android Studio (Build, then Generate Signed App Bundle) or with Gradle and a keystore. At the first release you set up Play App Signing, with either a Google-generated key or a key you supply.
bundletool builds device-specific APKs from the bundle, so you can test an install before uploading anything.
The versionCode must rise with every update and stay under 2,100,000,000, the highest value Play Console accepts, or the upload gets blocked.
Existing apps that target API 34 or lower do not vanish. They stop being offered to new users on devices running a newer Android version than the app targets, and installed copies keep working (Play Console Help).
The extension Google offered closed on November 1, 2026. Apps built permanently for a single organization are exempt, and everything else needs the higher target before the next submission.
What does the store listing require?
The text side is an app name of up to 30 characters, a short description of up to 80 and a full description of up to 4,000. The graphics are a 512 x 512 px icon, a 1024 x 500 px feature graphic and at least two screenshots.
The app name allows one localized version per language, and the short description is the first text users see on the listing.
Some guides still list a 50-character app name. Both the Play Console Help article on creating an app and its store listing guidelines say 30, so design around 30.
The icon and the feature graphic disagree on transparency. The icon must be a 32-bit PNG with alpha, 512 x 512 px and no larger than 1024 KB, while the feature graphic must be a JPEG or 24-bit PNG with no alpha at 1024 x 500 px.
Screenshots follow the feature graphic’s rule: JPEG or 24-bit PNG without alpha, between 320 and 3840 px per side. Google requires at least two across device types and accepts up to 8 per device type.
For the large-format recommendation placements, apps need at least four screenshots at 1080 px or more, in 16:9 landscape or 9:16 portrait. A contact email is mandatory in store settings, and the preview video is optional (a YouTube URL with ads turned off).
A listing gets flagged for keyword lists in the name or descriptions, rankings or awards such as “#1” or “Best of”, price or promotion text such as “Free” or “10% off”, and anonymous user testimonials. Emojis, ALL CAPS and special character sequences in the title count too.
Repetitive or irrelevant keywords in the name or descriptions can lead to app suspension, according to Play Console Help.
Which declarations must be complete before release?
Play Console collects its policy declarations on the App content page. That covers the privacy policy, ads, sign-in details, target audience, content rating and the Data safety form, and review checks the answers against what the app actually does.
The failure to design against is a declaration that contradicts real behavior. Data collected by third-party SDKs counts as well, and Google treats that as the developer’s responsibility.
Data safety form
Every developer completes it, for every app, except apps active only on the internal testing track, system services and private apps. The form declares which user data the app collects or shares and which security practices protect it, such as encryption. A privacy policy has to be on file before you can finish it.
Google reviews the answers during app review, but says it cannot determine on a developer’s behalf how an app handles user data. Accuracy stays with the developer.
Content rating and target audience
Unrated apps may be removed from Google Play (Play Console Help).
Google does not assign the rating itself. Regional authorities in the International Age Rating Coalition (IARC) derive it from the questionnaire you submit on the App content page.
Any change to content or features that affects the answers requires a new questionnaire, and misrepresenting content can lead to removal or suspension.
The target audience declaration is a separate form. Including children in the age group brings the Families policy requirements, and a listing with youthful animation can attract children by accident, which Google suggests fixing by declaring child age groups or removing those elements.
Privacy policy and ads declaration
The privacy policy must be linked in the store listing and inside the app, even when the app collects no personal data.
- It sits on an active public URL with a valid SSL certificate
- Anyone worldwide can reach it, with no login or geofencing
- It’s a standard web page, not a PDF
- It speaks to this specific app and covers collection, use and sharing, including the types of parties that receive data
The ads declaration is a yes or no on whether the app contains ads, including ads served by third-party SDKs. A yes adds a “Contains ads” label to the listing, and misstating it can lead to suspension.
A few declarations only apply to some apps. Anything behind a login wall must supply working credentials for reviewers (up to five sets of instructions), and apps that request high-risk permissions such as SMS or Call Log need an approved Permissions Declaration Form.
How do the release tracks work, and which one should you use first?
Upload the first build to internal testing. It takes up to 100 testers, needs no finished app setup, and reaches them within minutes (Play Console Help).
| Track | Who can join | What you need first |
|---|---|---|
| Internal | Up to 100 testers added by email | Nothing, even before app setup is complete |
| Closed | Testers you invite by email list or Google Group | Completed app setup |
| Open | Anyone with the link or the Google Play listing | Production access, on new personal accounts |
| Production | All Google Play users in your chosen countries | A passed closed test, on new personal accounts |
Internal testing does not mean unreviewed. If the first rollout of a fully configured app goes out on the internal track, that submission is reviewed before it can be published, and apps that are not fully configured skip the review.
The pre-launch report runs automatically when you upload a bundle or save a production release, subject to device lab capacity. It installs the build on lab devices running Android 9 and above, crawls it for several minutes, and reports stability, Android compatibility, performance and accessibility issues. Usually it finishes within an hour, sometimes several hours.
The crawler needs test-account credentials to get past a sign-in screen, cannot buy anything, and fails on apps that check for root access. Test devices sit in the United States, so an app with country restrictions shows only what that region sees.
Version codes decide which build a tester gets. A device receives the highest version code across every track its user is eligible for, so a production build with a higher code quietly overrides your test build.
One more trap: a user who opts into the internal test is no longer eligible for open or closed tests until they opt out of it.
The package name locks when the first artifact is uploaded, not when the app is published. An internal upload counts.
Does the 12-tester closed test rule apply to your account?
Only personal accounts created after the November 2023 cutoff are covered. Everyone else skips the closed test.
Personal accounts created before the cutoff are exempt, and Play Console Help names them explicitly. Organization accounts are exempt too, because the rule is written for personal accounts.
For covered accounts, Production and Pre-registration stay disabled in Play Console until the criteria are met. The count is checked when you apply, and it needs at least 12 testers opted in continuously for the preceding 14 days.
“Continuous” is read strictly. A tester who opts in, tests for fewer than 14 days and then opts out does not count, and a tester who leaves and comes back counts only if the 14 days are consecutive.
Google’s documentation does not say whether pausing the track or uploading a new build resets the clock. Keep the track active and keep the builds quiet during the window.
The production access application asks about the closed test itself first: how easy recruiting was, whether testers used every feature, whether their usage matched real production behavior, and a summary of the feedback you collected. It then asks about the app, covering target audience, value proposition and an estimated first-year install range (those answers stay private and do not affect visibility).
The last section covers production readiness, meaning what you changed after testing and how you decided the app was ready.
Google emails the account owner when the review of the application completes. It sends the app back to testing when fewer than 12 testers were opted in or when engagement was thin, which is why the form asks about feature usage.
Google’s own recruiting advice is personal and professional networks plus communities where your target users already gather. Friends fill the count, but testers close to the intended audience are the ones who write feedback worth summarizing.
Testers cannot leave public reviews on test versions. Give them an email address, a website or a message group for feedback, and they can also send private feedback through Google Play.
How do you release to production with a staged rollout?
Create the production release under Test and release, add the bundle, write release notes and start the rollout. A first release goes to everyone in the selected countries, because percentage-based staged rollout works only on updates (Play Console Help).
Add the tested bundle from the library, or upload a new one. The release name shows only inside Play Console and defaults to the version name. Release notes go in per language, up to 500 Unicode characters each, wrapped in language tags such as <en-US>.
Everything under Errors summary has to be cleared. Warnings and minor issues do not block publishing.
Since the first release cannot be staged, the brake has to come earlier. Choose the launch countries before the first release, and let the closed test do the rest.
Raising the percentage is manual. It never increases on its own, so open Manage rollout, choose Update rollout and confirm. Users are picked at random and receive no notification.
Halting stops new users from receiving the version, but anyone who already has it keeps it. Fix the bundle and ship a new release.
Countries cannot be removed once a staged rollout has started. A new release is also blocked while another is outstanding, so roll the staged one to 100% or remove its changes first.
Managed publishing separates approval from go-live. After review approves the changes, you press Publish changes and the update goes live within a few minutes, though it is unavailable for an app’s first publication.
Several changes slip past managed publishing and go out immediately, including raising a staged rollout to 100% and editing release notes. Changes to device exclusion rules, tester list membership, in-app products and prices, and unpublishing the app are not held back either (Play Console Help).
Watch crash reports and feedback while the rollout runs, since users in the rollout can post public reviews. If the update also changes the store listing, Google recommends updating the listing after the release reaches 100%.
How long does Google Play review take, and what causes rejections?
Review takes anywhere from a few hours to seven days, and longer in exceptional cases, according to Play Console Help. New developer accounts are the usual example of extended review.
Google itself recommends a buffer of at least a week between submitting and going live.
The review clock counts from your last submitted change. Submit another change while an earlier one is in review and the app can drop to the back of the queue, with Review and publish disabled until the review finishes.
Submission activity shows where things stand. In review means Google is evaluating the changes, Ready to publish means approved and waiting for you to publish manually, and Published means live on Google Play. Rejected means the changes were not published and the last approved version stays live. Cancelled means the submission was withdrawn, superseded by a newer one, or blocked.
Pre-review checks run automatically whenever you change the app and finish within 15 minutes. They flag missing mandatory declarations and high crash rates on specific devices or Android versions.
Critical issues must be fixed before you proceed, and other issues can be deferred with Proceed anyway. Passing every check does not guarantee passing review.
Google’s publishing tips point to the same rejection causes again and again.
- Listing text that is misleading, non-descriptive or excessive (Metadata policy)
- Features the listing promises that the app does not have
- No working demo account for an app behind a login
- Crashes or broken screens (Broken Functionality policy)
Repeated rejections can lead to suspension. Google also says review is not a troubleshooting step, and that submitting a non-compliant app in the hope reviewers will find the problems means rejections and longer appeals.
After a rejection, fix the issue and send the changes again, or file an appeal. Play Console does not resubmit automatically, so go to Publishing overview and click Send for review.
Android vitals flags apps above a 1.09% user-perceived crash rate or a 0.47% user-perceived ANR rate, averaged across devices, with a per-phone-model limit of 8% for each (Play Console Help, technical quality requirements).
Exceeding those thresholds can reduce the app’s discoverability on Google Play, so the staged rollout is the cheapest moment to catch a crash spike.
FAQ About Publishing an App on Google Play
Can you convert a personal developer account to an organization account?
Yes, but only in that direction. The account owner sets up an organizational payments profile, verifies the organization website under Developer account, then About you, and clicks Change account type.
Play Console Help states that converting an organization account back to personal is not possible.
What happens if you lose your upload key?
Nothing permanent. Google holds the app signing key, so you generate a new upload key in Android Studio, export its certificate as a PEM file and submit Request upload key reset on the Play app signing page.
A self-managed app signing key that you lose cannot be reset.
Is there a size limit for an app on Google Play?
Yes, measured on compressed download size. The base module and each feature module cap at 500 MB, and each asset pack at 1.5 GB.
Some guides cite 200 MB as the base module limit. Play Console Help uses that figure only for the warning dialog shown to users on mobile data.
How do you push an update to an app that is already live?
Create a new release with the same package name, a higher version code and the same signing certificate as the live version. Compare certificates on both bundles with the jarsigner tool before uploading.
After review, delivery to existing users can take some time.
Does unpublishing an app remove it from users’ devices?
No. Existing users keep the app and still receive updates, while new users can no longer find or download it.
Unpublishing is blocked while managed publishing is active or while the app has unresolved errors. The Unpublish option sits on the App availability tab under Advanced settings.
Deadlines That Keep a Published App Live
An app on Google Play stays eligible only while it meets Google’s dated technical requirements, and the next enforcement window opens in February 2027.
From then, uploads with more than 10 MB of DEX code (50 MB for games) need at least 25% obfuscation, optimization and shrinking. Memory also joins Android vitals, judged at the 90th percentile per RAM tier (Play Console Help).
Zero-tap sign-in restoration follows in April 2027 for apps that offer accounts.
Work in the order that blocks an upload first. Turn on R8 shrinking and obfuscation in the release build, then profile memory against your RAM tier thresholds. Restore Credentials sign-in support goes last.
The DEX check covers every upload on every form factor, while restoration gates only apps with sign-in, so build changes come first.
Google lists all of these as mandatory, and an unmet requirement can reduce visibility and publishing capabilities (verified November 5, 2026).
- Go Cheat Sheet - November 9, 2026
- Build or White-Label Software? How Software Teams Decide What to Resell in 2026 - November 9, 2026
- Notepad++ Column Mode: Edit 100 Lines at the Same Time - November 7, 2026
