Publishing on Google Play in 2026 involves far more than uploading a build. The account has to be verified, the app has to meet this year's technical requirements, the listing has to follow metadata rules, a dozen content declarations have to be completed accurately, and new personal accounts must run a two-week closed test before they may release at all. This is the full sequence, in the order that avoids rework.
1. Choose the right developer account
A Google Play developer account costs a one-time US$25 registration fee and comes in two types, and the choice has consequences for years:
| Question | Personal account | Organisation account |
|---|---|---|
| Who it is for | An individual developer | A registered business |
| Identity verification | Government identification | D-U-N-S number and organisation details |
| Name shown on the listing | The verified personal name | The organisation's name |
| Closed testing before first release | Required for accounts created after 13 November 2023: at least 12 testers for 14 continuous days | Not required |
For a business app, open an organisation account in the business's own name. An app in a founder's personal account or an agency's account is an ownership problem waiting to happen, and since September 2026 every app is also registered to the verified identity of the account that holds it: see Android developer verification. A D-U-N-S number can take weeks to obtain, so request it at the start of the project, not at the end.
2. Technical requirements in 2026
- Android App Bundle and Play App Signing. New apps are uploaded as app bundles and signed through Play App Signing. Keep the upload key backed up and its owner documented.
- Target API level. From 31 August 2026, new apps and app updates must target Android 16 (API level 36). Wear OS and Android Automotive OS apps must target API 35, and Android TV and Android XR apps API 34. An extension to 1 November 2026 can be requested in Play Console. Existing apps must target at least API 35 to stay available to new users on devices running newer Android versions.
- 16 KB memory pages. Since 1 November 2025, with the last extensions having expired on 31 May 2026, new apps and updates that target Android 15 or higher must support 16 KB page sizes on 64-bit devices. This matters when the app or any of its libraries contains native code: rebuild with current tooling and check every third-party native library.
- Developer verification. Every app must be registered to a verified developer; apps published through Play Console are normally registered automatically.
3. The store listing
| Element | Requirement |
|---|---|
| App name | Up to 30 characters |
| Short description | Up to 80 characters |
| Full description | Up to 4,000 characters |
| App icon | 512 × 512 PNG, 32-bit with alpha, up to 1 MB |
| Feature graphic | 1024 × 500, JPEG or 24-bit PNG |
| Screenshots | At least two; up to eight per device type; JPEG or 24-bit PNG; each side between 320 and 3,840 pixels, the long side no more than twice the short side |
The metadata policy is where many first listings fail. The app name, icon and developer name must not contain words or badges about ranking, price or promotion ("best", "#1", "free", "sale"), and descriptions must not stuff keywords, quote anonymous testimonials or promise features the app does not have. Screenshots must show the actual app.
4. App content declarations
In Play Console, the App content section collects declarations that reviewers check against the app. Which ones appear depends on what the app does; the ones almost every app completes:
- Privacy policy: a live URL, also reachable inside the app, that describes what the app actually collects.
- Data safety: what data is collected and shared, for what purposes, and how it is protected. It must include data collected by the libraries inside the app, not only your own code.
- Ads: whether the app shows advertising.
- Target audience and content: the age groups the app targets. Including children brings the Families policy requirements into play.
- Content rating: the rating questionnaire. Unrated apps are not allowed on Google Play.
- Account deletion: if users can create an account in the app, they must be able to request deletion of the account and its data both inside the app and through a web link.
- Sensitive permissions: declarations and justifications for permissions such as SMS and call log, background location, all-files access and exact alarms, and for foreground service types.
- Other declarations where relevant: financial features, health features, news, government apps and more.
Answer these from a written inventory of what the app and its libraries do, not from memory. Inconsistency between declarations and behaviour is one of the most reliable ways to be rejected.
5. Testing tracks
| Track | Use |
|---|---|
| Internal testing | Up to 100 testers, fast availability; for your own team |
| Closed testing | Invited testers; the track used for the 12-tester requirement on new personal accounts |
| Open testing | Anyone can join from the listing; useful for larger betas |
| Production | Everyone, with optional staged rollout by percentage |
Every build on a testing track also gets a pre-launch report from automated runs on real devices. Read it before promoting a build: crashes, accessibility issues and security warnings found there are cheaper to fix than a production rejection.
6. Review and release
Review times vary. First submissions and new accounts often take longer than routine updates, sometimes several days, and apps in sensitive categories take longer still. Two controls remove most of the timing risk:
- Managed publishing lets an approved release wait until you choose to publish it, so a marketing date does not depend on the reviewer's queue.
- Staged rollout releases a new version to a percentage of users first, so a problem reaches a few users rather than all of them.
If the app is rejected, the reason is shown in the Policy status section of Play Console with the relevant policy. Fix the cause, reply or resubmit, and keep the evidence of the change. The rejection reasons we see most, and how to avoid them, are general enough to apply to both stores: the predictable rejections.
7. The full checklist
- Organisation account in the business's own name; D-U-N-S requested early
- Upload key backed up; owner documented
- Target API 36 for new apps and updates; 16 KB support for native code
- Listing text within limits and free of ranking, price and promotional claims
- Icon, feature graphic and screenshots at the required sizes, showing the real app
- Privacy policy live and linked in the app
- Data safety answers taken from a written data inventory, including libraries
- Account deletion available in the app and on the web, if accounts exist
- Content rating, target audience, ads and permission declarations completed
- Closed test completed where the account type requires it
- Pre-launch report reviewed; managed publishing on for the first release
Related Manboo Services
- Android App Development, including Play Console set-up, release tracks and policy declarations.
- iOS App Development, including App Store Connect, TestFlight and App Review preparation.
- Flutter App Development when one codebase must pass both stores' reviews.
- Software Maintenance for existing apps that need target API, SDK or policy updates.
- Request a scope review and estimate for a store launch or a rejected submission.