How to Publish an App on Google Play (Step-by-Step 2026)
Everything after your Play Console account: the August 31 target API 36 deadline, app bundles, signing, data safety, the 12-tester rule and production release.
To publish an app on Google Play you need a Play Console account (a one-time $25 fee), an Android App Bundle targeting Android 16 (API level 36), a complete store listing, a content rating, a data safety declaration, and a privacy policy. New personal accounts must also run a closed test with 12 testers for 14 continuous days before they can release to production. Here is the whole sequence, including the deadlines that land in 2026.
Updated July 2026.
At a glance| What | Detail |
|---|---|
| Cost | US$25, one-time registration fee — not annual |
| Build format | Android App Bundle (AAB). Required for all new apps since August 2021 |
| Target API level | Android 16 (API 36) for new apps and updates from August 31, 2026 |
| Extra build requirement | 16 KB page size support, required for anything targeting API 35+ |
| Closed testing | Personal accounts created after November 13, 2023: 12 testers, opted in for 14 continuous days |
| Review time | No published turnaround. Google says some accounts take up to seven days or longer |
| Organization accounts | Need a D-U-N-S number, which can take up to 30 days to obtain |
This guide begins once your Play Console account exists and is verified. If it does not yet, start there, because the waiting is front-loaded: organizations need a D-U-N-S number, which Dun & Bradstreet can take up to 30 days to issue, and payment-method verification alone can take up to five days.
Two things worth knowing before you choose an account type. Organization accounts display your developer phone number and developer email publicly on your Play listing. And the closed-testing requirement in step 9 is scoped to personal accounts created after November 13, 2023 — which is one of the strongest practical arguments for registering as an organization if you are a registered business.
1. Target Android 16 (API level 36) — the August 31, 2026 deadline
This is the requirement most likely to block you this year, and it is not negotiable. From August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher. Wear OS and Android Automotive apps need API 35 or higher; Android TV and Android XR need API 34 or higher. Existing apps must target at least API 35 to stay available to new users on newer devices.
If you cannot make the date, Play Console has a form to request an extension to November 1, 2026. Apps distributed only privately inside an organization are exempt. Everyone else should treat this as the first thing to check, because it decides whether the rest of the process is even worth starting this month.
There is a second build requirement that is easy to miss: anything targeting API 35 or higher must support 16 KB memory page sizes. Since API 36 is now the floor, this applies to essentially every new upload. If your app includes native code or third-party native libraries, test this explicitly — it is a runtime failure, not a warning.
Target API levels are a build concern, not a decision you have to make. Choicely builds against current Android SDKs, so the 31 August requirement — and the 16 KB page-size rule that arrives with it — is handled rather than something you chase. You keep your own Play Console account, because Google requires the app's owner to publish it. Build your app free →
2. Build an Android App Bundle
Google Play takes an Android App Bundle (.aab), not an APK. Play generates the optimized APKs each device needs from your bundle, which is why app sizes dropped when the format became mandatory for new apps in August 2021.
APKs are not entirely dead, which causes confusion worth clearing up: apps created before August 2021 can still ship APK updates, and private enterprise apps distributed through Managed Play still support them. But for any new app, the bundle is the only route. Increment your version code with every upload — Play rejects a version code it has already seen.
Size limits, if you are shipping something large: the base module can be up to 500 MB, asset packs up to 1.5 GB, and cumulative install-time downloads up to 4 GB. Note that Google's own app bundle FAQ still quotes an older 200 MB base-module figure; the 500 MB limit in the Play Console help is the current one. Staying under 200 MB is still worth aiming for, because above it users on mobile data get a warning before installing.
3. Let Play manage your signing keys
Every Android app must be signed. Play App Signing splits this into two keys: an upload key you hold and use for uploads, and an app signing key Google holds and uses to sign what users actually install. New apps are enrolled automatically.
The practical benefit is recovery. If you lose your upload key you can generate a new one and request a reset — annoying, not fatal. Losing an app signing key you managed yourself, by contrast, historically meant you could never update your app again. Play App Signing exists to remove that failure mode.
Heads up if you are following an older tutorial or video: the Play Console interface moved in May 2026. App signing now lives under Protected with Play, on the Play Store protection page, which replaced the previous App integrity page. Google's own documentation still contains some older paths, so expect labels to vary. As of 2026 new apps are also enrolled in quantum-ready hybrid signing, which combines classical RSA with a post-quantum algorithm for Android 17 and later — nothing you configure, but you may see it referenced.
4. Create your app in Play Console
In Play Console, go to All apps and choose Create app. You will set the app name, default language, whether it is an app or a game, whether it is free or paid, and confirm a few declarations. The free-or-paid choice matters more than it looks: you can move a paid app to free later, but you cannot make a free app paid.
5. Build the store listing
Your main store listing lives under Grow, then Store presence. The text limits are tight and worth drafting before you open the form: the app title is 30 characters or less, and the short description is 80 characters. Both do heavy lifting in search results.
| Asset | Spec |
|---|---|
| App icon | 512 × 512 px, 32-bit PNG with alpha, maximum 1024 KB |
| Feature graphic | 1024 × 500 px, JPEG or 24-bit PNG, no alpha channel |
| Screenshots (minimum to publish) | At least 2. Minimum dimension 320 px, maximum 3840 px |
| Phone screenshots (recommended) | At least 4, at 1080 px — 9:16 portrait (1080 × 1920) or 16:9 landscape (1920 × 1080) |
| Tablet screenshots | At least 4, 1080–7680 px, 16:9 or 9:16 |
| Screenshot format | JPEG or 24-bit PNG, no alpha |
| Preview video | One YouTube URL, public or unlisted (never private), with ads disabled |
Play's metadata policy also restricts what these assets may contain, and this catches a lot of first listings. Keep promotional and price text out of your graphics — no "50% off", no "free for a limited time". Do not claim rankings or awards, so no "#1 app" and no "Best of Play" badges. Avoid keyword stuffing, all-caps and decorative characters aimed at search, and do not use testimonials you cannot attribute.
Every one of these is a place a listing stalls. Wrong feature-graphic dimensions, an alpha channel Play rejects, a title three characters too long. Choicely's Publish Assistant generates your listing text and graphics to each store's spec, so the sizes are right the first time. Start free →
6. Get your content rating
Under Policy, then App content, open Content rating and complete the questionnaire. It is run by the IARC and generates the age ratings shown in each region. This is mandatory — Google states that unrated apps may be removed from Google Play. Answer it honestly rather than optimistically; a rating that does not match your app is a policy problem, not a marketing choice.
7. Complete the data safety declaration
Data safety, also under Policy then App content, is where more submissions come unstuck than anywhere else. You declare what data your app collects and shares across 13 categories, why, whether it is encrypted in transit, and whether users can request deletion. Both of those last two answers are required.
The single most important rule: your declaration must cover data collected by third-party code in your app, not just code you wrote. Analytics, crash reporting, advertising, attribution and push SDKs all count. An ad SDK that shares a device identifier is your disclosure to make, and "it is just infrastructure" is not a category Google recognises.
A privacy policy is mandatory. You need a link in the designated Play Console field, and Play's user data policy also requires a privacy policy link or text inside the app itself. The two must describe the same practices as your data safety form — Google compares them, and it now runs pre-submission checks that flag broken privacy-policy links. Google is explicit that where your app's behaviour and your declaration disagree, the outcome can be blocked updates or removal from Play, and that you alone are responsible for the accuracy of what you declare.
Declaring what you don't control is the hard part. Most data safety rejections come from third-party SDK behaviour a developer never knew about. Choicely apps are built on a known stack, so the Publish Assistant fills your privacy details from what the app actually does rather than from guesswork. See how publishing works →
8. Declare your target audience
Still under App content, complete Target audience and content. If you select any child age group, your app must meet the Families policy requirements, which include serving ads only through Google's self-certified ads SDKs. This is a much larger compliance surface than the form suggests, so do not tick a child age group casually to widen your audience.
9. Test your app — and the 12-tester gate
Play gives you three pre-production tracks under Test and release. Internal testing takes up to 100 testers by email and has no review, so it is your fast loop. Closed testing scales much further — up to 2,000 users per list — using email lists or Google Groups. Open testing is unlimited by default, or capped at a minimum of 1,000.
Now the requirement that surprises solo developers. If you have a personal account created after November 13, 2023, you cannot release to production until at least 12 testers have been opted in to your closed test for the last 14 continuous days. Continuous is the operative word: testers who opt in, test for a week, drop out and come back later do not satisfy it. Until you meet the requirement, Play Console keeps Production and Pre-registration disabled.
Google scopes this requirement to personal accounts and does not describe it as applying to organization accounts. Plan around the 14 days either way — it is calendar time you cannot compress, so start the closed test while you are still writing your listing.
10. Apply for production access
Personal accounts subject to the closed-testing rule apply for production from the Play Console dashboard, via Apply for production. You will answer questions about how your closed test went, what your app does, and whether it is ready for production. Treat these as real questions — this is a human-reviewed gate, not a checkbox.
11. Release, and roll out gradually
Create a release on the Production track, upload your bundle, add release notes, and submit. Then use a staged rollout rather than going straight to everyone: start at a small percentage, watch your crash rate and reviews, and increase from there. A bad release caught at 5% is an inconvenience; the same release at 100% is a one-star problem you cannot undo.
Google publishes no review-time commitment. The only figure it gives is that for certain developer accounts review may take up to seven days or longer in exceptional cases. Plan for a week rather than a day, especially on a first release, and note that editing your store listing after submitting can restart the review.
Which of these steps you still do yourselfIf you build your app on Choicely, most of the sequence above stops being your problem. Not all of it, and the exceptions are the interesting part.
| Step | With Choicely |
|---|---|
| Play Console account + identity verification | Yours — $25 one-time, in your own name. Google requires an app to be published by whoever owns it |
| Targeting Android 16 (API 36) and 16 KB pages | Handled — built against current SDKs |
| Producing a signed app bundle | Handled |
| Play App Signing and upload keys | Handled — registered as part of publishing |
| Creating the app in Play Console | Guided — walked through, step by step |
| Store listing, screenshots, feature graphic | Handled — generated to Play's current specs |
| Content rating questionnaire | Prepared, you answer — honestly, about your own app |
| Data safety declaration | Prepared, you confirm — drawn from what the app actually does |
| Target audience and Families requirements | Yours — it depends on who your app is for |
| The 12-tester, 14-day closed test | Yours, and nothing shortens it — 14 continuous days is calendar time. Everything else can be ready before it ends |
| Applying for production access | Yours — Google asks what you learned from your test |
| Google's review time | Nobody's to control — no published target |
| Staged rollout percentage | Yours |
The pattern: Choicely removes the toolchain — SDK targets, bundles, signing keys, asset specs — and leaves you the things that are genuinely yours. Your developer account, your honest answers about your own app, and the fourteen days Google makes every new solo developer serve.
Why "website in an app" gets rejected here tooPlay's Spam and Minimum Functionality policy is the Android counterpart to the rule that most often blocks iOS submissions. It targets apps with no substantive purpose, and it explicitly covers webview wrappers — an app that is a website in a shell — along with text-only or PDF-only apps and single-wallpaper apps. Google also names apps that fail to install, install but do not load, or load but are not responsive.
If you are choosing how to build, this is the decision that carries the most risk. Both stores independently reject wrapped websites, so a tool that produces one puts your submission at risk twice. Building a genuinely native app avoids the entire category of problem, and it is worth resolving before you spend the $25 and the fourteen days.
Why submissions get rejectedGoogle does not publish a rejection rate, so treat any percentage you see with suspicion. What it does publish is enforcement scale: in 2025 Google says it prevented over 1.75 million policy-violating apps from being published, banned more than 80,000 developer accounts, stopped over 255,000 apps from getting excessive access to sensitive user data, and runs over 10,000 safety checks on every app it publishes.
In practice, the recurring causes cluster into four areas.
| Area | What actually goes wrong |
|---|---|
| Data safety | Third-party SDK collection left undeclared; the privacy policy and the form describing different practices; the form going stale after adding an SDK |
| Minimum functionality | Webview wrappers and thin apps; apps that crash, fail to load, or are unresponsive on review |
| Restricted permissions | Requesting broad permissions without a qualifying use case — see below |
| Misleading metadata | Promotional or ranking claims in assets, keyword stuffing, descriptions that oversell what the app does |
Restricted permissions deserve specifics, because each has a narrow approved use. Querying all installed packages is limited to a small set of app types and is explicitly not valid for advertising or analytics. SMS and call log access generally requires being the device's default handler, and using SMS for account verification is not an accepted reason. Photo and video permissions now expect you to use the system photo picker unless it genuinely cannot serve your use case. And accessibility services may not be used to have an app autonomously plan and execute actions — worth knowing if you are building anything agentic.
One reassuring structural point: a rejection is not a strike. Google's enforcement escalates from rejection, which carries no standing penalty, through removal, then suspension, then account termination. Fixing a rejection and resubmitting is the normal path, not a mark against you. If an account is ever terminated, note that appeals must be filed within 180 days.
Pre-submission checklist- Targets Android 16 (API 36) — or an extension is requested before August 31, 2026
- 16 KB page size support verified, especially if the app contains native libraries
- Uploading an .aab, with a version code you have never used before
- No crashes on a real device; app loads and responds on first launch
- Icon 512 × 512, feature graphic 1024 × 500 with no alpha, at least 2 screenshots
- No price, promotional, ranking or award claims in any graphic asset
- Content rating questionnaire completed
- Data safety form completed, covering every third-party SDK
- Privacy policy linked in Play Console and reachable inside the app, and consistent with the form
- Target audience declared, with Families requirements met if any child age group is selected
- If a personal account created after November 13, 2023: 12 testers opted in for 14 continuous days
- Staged rollout percentage set, rather than releasing to 100% immediately
If you have an Android developer and a working build pipeline, none of the above is a problem you need help with. Keep your setup.
If your app already exists in native code or on another platform, you need your own Play Console account and your own submission, not a builder. And if your product's core is complex custom backend logic, a development team will serve you better than any no-code tool.
Choicely is worth a look if you want to build the app and ship it in one place: you build a real native Android and iOS app free — 300 credits every month, no credit card — and the Publish Assistant pre-checks it against the policies above, generates your store listing, and walks the submission. Because Choicely builds real native apps rather than webview wrappers, the minimum functionality trap above is not one you have to design around. The $25 Play registration fee is still paid directly to Google, under your own account.
What API level do I need to target in 2026?
From August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher. Wear OS and Android Automotive need API 35 or higher, and Android TV and Android XR need API 34 or higher. If you cannot meet the date, Play Console offers an extension request to November 1, 2026. Apps targeting API 35 or above must also support 16 KB memory page sizes.
Can I still upload an APK instead of an app bundle?
Not for a new app. Android App Bundles have been required for new apps since August 2021. Apps created before August 2021 can still ship APK updates, and private enterprise apps distributed through Managed Play still support APKs, but anything new must be a bundle.
How long does Google Play review take?
Google publishes no turnaround commitment. The one figure it gives is that for certain developer accounts review can take up to seven days or longer in exceptional cases. Plan for about a week on a first release, and remember that editing your store listing after submitting can restart the review.
Why do Google Play submissions get rejected?
Most commonly: a data safety declaration that misses what third-party SDKs collect, a privacy policy that does not match that declaration, an app that crashes or does not load during review, restricted permissions requested without a qualifying use case, or misleading store listing metadata. Google does not publish a rejection rate, so treat any percentage you see as unsourced.
What is a staged rollout, and should I use one?
A staged rollout releases your update to a percentage of users rather than all of them, so you can watch crash rates and reviews before going wider. Use one. Catching a bad build at 5% of users is recoverable; discovering it at 100% is not.
Do I need a privacy policy to publish on Google Play?
Yes, and in two places. You need a privacy policy link in the designated Play Console field — it is required to complete the data safety form — and Play's user data policy also requires a privacy policy link or text inside the app itself. Both must describe the same practices you declared.
Do I need to register my app for Android developer verification?
All apps distributed on Google Play must be registered in Play Console, and Google says roughly 99% are registered automatically — check your Play Console home for status. Enforcement begins September 30, 2026 in Brazil, Indonesia, Singapore and Thailand, expanding from 2027. Apps that are not registered face removal from Google Play.
Building your app as well as publishing it? Choicely builds real native Android and iOS apps free — 300 credits every month, no credit card — and the Publish Assistant pre-checks your app against the policies above, generates your store listing, and walks the submission into both stores.
Sources & disclosure: the registration fee, build and target-API requirements, asset specs, data safety and content rating rules, testing requirements and enforcement figures were verified against Google's official Play Console and Android developer documentation on July 28, 2026. Choicely publishes this guide and sells an app-publishing product, so we have a commercial interest in it — the section above on when you do not need a builder is there for that reason. Play policies change often, and several 2026 deadlines fall within months of this update; we re-verify quarterly.
Required footer addition
Google Play and the Google Play logo are trademarks of Google LLC. Choicely is not affiliated with, sponsored by, or endorsed by Google.