Google Play Publishing Requirements for New Developers in 2026

Google Play does not give one approval. It holds a release behind a chain of separate gates, and each gate has its own applicability rule - so a good deal of what follows will not apply to you.

Every requirement below carries the same four things: who it applies to, what you do, what proves it is finished, and the official page it comes from. Where Google's own pages contradict each other - on two points here, they do - you get both versions rather than our guess.

Google Play publishing requirements at a glance

Every gate is below, with the rule that decides whether it reaches you and the thing in Play Console that proves it is done. Rows marked conditional are skipped entirely by some publishers.

The order these actually happen in

Eight stages, and the order is not a preference - three of them are hard prerequisites for the one after.

1. Choose and verify your developer account Account type, the fee, identity, and the device check where Console shows it.
2. Create the app and prepare a compliant build App record and application ID, App Bundle and signing, target API, build preflight.
3. Check Android developer registration A status check in Play Console once the app and package exist.
4. Complete the store listing and assets Text limits, required graphics, the icon mask, AI asset declarations.
5. Complete App content and reviewer access Privacy, Data safety, deletion, rating, audience, ads, the two universal declarations, sign-in instructions.
6. Run the qualifying closed test 12 testers opted in for 14 continuous days. Personal accounts created after Nov 13, 2023 only.
7. Apply for production access The three-part questionnaire about your test, app and readiness.
8. Submit and publish the production release Countries, pricing, the bundle, release notes, sending for review, then publication.

1. Choose and verify your developer account

You need a Google account with 2-Step Verification enabled, and you accept the Developer Distribution Agreement and the Play Console Terms of Service at signup. Three things then have to clear before you can publish: the fee, your identity, and - where Console shows it - a device check.

What the US$25 fee is, and what it is not

The fee is paid by credit or debit card only. Accepted card types vary by location, and Google is explicit that prepaid cards are not accepted.

Personal or organization - and when the choice is already made

Ask the category question first, because for some apps there is no choice to make.

If none of those categories reach you, the choice is yours. Both types can publish and monetize, so part of the difference is just what Google verifies about you - but it is not only paperwork. A personal account created after November 13, 2023 also owes a qualifying closed test, which is the longest fixed item in this guide. Fuller comparison: personal vs organization accounts.

What account verification requires, and why timing varies

Google verifies who you are at account level before you can publish. A personal account supplies an official government identity document; an organization supplies organization details alongside one. What is asked for can depend on what your payments profile already verifies, which is why two people following the same guide get asked for different things. Verify your developer identity

Google publishes no guaranteed processing time for Play account-identity review, and the widely quoted "up to 5 days" is not one - that figure comes from Google's payments documentation, not the Play identity page. Complete the tasks Console shows and allow for extra document checks. Payment-method verification is separate again: a merchant check tied to taking payments, not a step every free-app developer has to start. Account information and merchant checks

Done when: Play Console stops showing the identity verification task for your account. Treat submitted and cleared as two different states - a submitted document does not unblock publishing.

Device verification: the gate most guides miss

New personal developer accounts have a separate device task. You verify access to a non-rooted physical Android mobile device running Android 10 or later, using the Play Console mobile app while signed in as the account owner. Device verification requirements

What it is not: the identity check, the qualifying closed test, or a rule about your testers - nothing here says the 12 people in your closed test need that device specification. It is its own item on the Console Home page, and an emulator will not clear it.

Done when: The device verification task disappears from your Play Console Home page.

Changing account type later

You can convert a personal developer account to an organization account through Google's verification workflow: verify the organization's website, create or select and verify its payments profile, then complete the change in the existing account. Google advises waiting at least 72 hours after conversion before submitting new apps. Going the other way - organization to personal - does require a new account. Account type conversion

2. Create your app and prepare a compliant build

Two halves: the app record you create in Play Console, and the artifact you upload into it. One decision here follows the app for its whole life, so it is worth thirty seconds now.

The decisions that are permanent

Creating the app in Play Console sets its name, default language, app-or-game type and free-or-paid status. The application ID is a separate thing: it lives in your build configuration, not in that Console form, and the two meet when you upload. So check the application ID in your build before you upload it, rather than assuming an empty Console record has already fixed it. Create and set up your appApplication ID

Android App Bundle and the two signing roles

For an ordinary new public app, Google Play accepts the Android App Bundle (.aab) rather than an APK, and the app uses Play App Signing. That scope is worth stating once rather than as an absolute: eligible legacy apps still have APK workflows, App Bundles have been required for all Android TV apps since June 2023, and enterprise private-app distribution differs again. App BundlesPrivate apps

Play App Signing splits two roles, which is not the same as two physical keys you hold. The app signing key is managed by Google and signs what users install. The upload key signs your bundle before upload, so Google knows it came from you. The two roles can be backed by the same key or by separate ones; a separate upload key is the recommended configuration, because it can be reset if you lose it. Sign your app

Target API level, by form factor

This is the requirement most likely to block an upload outright, and it is not one number - it varies by what you are submitting.

Google documents extension windows running to November 1, 2026 in some circumstances, but eligibility is decided for your specific app inside Play Console. Target API requirements Migration detail is in the target API guide.

Preflight: what can reject an apparently valid bundle

Two checks catch projects that otherwise look finished. Both are conditional - if neither applies to your app, skip this and move on.

Native libraries: 64-bit and 16 KB page size

If your app ships native code - directly, through an SDK, or generated by an app builder - check it for 64-bit support and 16 KB page-size compatibility, and test it on a 16 KB environment. Apps written only in Java or Kotlin, dependencies included, already support the relevant page size. Check the bundle you actually upload: a dependency can reintroduce a 32-bit or 4 KB-aligned library without any change on your side. 16 KB page sizes64-bit

Play Billing Library version

If - and only if - your app integrates Play Billing, new submissions normally need Billing Library version 8 or newer. Version 7's ordinary deadline was August 31, 2026, and an applicable extension can run to November 1, 2026. None of this reaches an app without that integration, and it does not mean older installed apps stop working. Billing deprecation schedule

Done when: A signed .aab uploads with no target-API or format error, the version code is higher than anything you uploaded before, and - if the app ships native code - your compatibility checks and a run on a 16 KB environment both pass. Play Console validating an upload is not the same as your dependencies being tested; resolve blocking issues and read the warnings.

3. Check Android developer registration in Play Console

This comes after the previous stage because it needs the app to exist: registration attaches an app - its package name and signing-key fingerprint - to a verified developer identity, across the Android ecosystem rather than just Google Play. It is a different thing from the account-level identity check in stage 1, which proves who you are so you can hold an account.

For a Play publisher the practical question is narrow: is your app registered? Check its status on Play Console's Android developer verification page. Google attempts automatic registration and reuses the identity verification you already completed, so for most Play publishers this is a status check rather than a task - you do not need a separate Android Developer Console account, and you do not repeat identity verification. Confirm the registration and complete any outstanding Console action it shows. Registering Play package names

Apps that remain unregistered risk removal from Google Play globally from September 30, 2026 - easy to miss, because most coverage of that date describes only the four-country installation phase, a different part of the same programme. Two things you can ignore: the free Limited Distribution account is for hobbyists shipping to a handful of devices and is not a free route onto Google Play; and the device-side verifier's Android floor is documented inconsistently (the Android Developers FAQ says 7 and newer, Android Help says 8 and newer), which is an unresolved conflict between two Google pages rather than a requirement you act on. Android Help

Done when: Play Console's Android developer verification page shows the app registered, with no outstanding action listed against it.

4. Complete your store listing and assets

The listing is what users and reviewers see first, and it has hard limits that will stop a save. The useful line to hold is between what Google requires to publish and what it recommends for featuring; the two are separated below.

Required to publish

Google Play Console · real screenshot

Recommended, but not a publish gate

Google's preview-asset guidance also describes what makes a listing eligible for large-format and recommendation surfaces: more screenshots, higher resolutions, sets for the device classes you want featured on. Missing any of it does not block a release. Wear OS, TV and XR listings have their own asset rules on top. Preview assets

The icon corner mask

You upload a full square icon and Google Play applies a dynamic corner mask with a radius equivalent to 30% of the icon size, so anything near a corner is clipped in the rendered result. This is the current specification - not, as is often repeated, a change introduced in 2026. A source page's own modification date is not evidence of when a rule started. Icon design specifications

AI declarations for generated store assets

If you generate or edit listing images, video or promotional material with AI, Play Console now includes per-asset self-declarations in its content-creation flows, with labels applied to assets falling within the applicable regulatory scope. Google's help page states no start date and no exhaustive list of the rules it covers, so we are not inventing either. This is about store assets, separate from the policy governing what a generative app produces for users. Declaring AI-generated content

Metadata rules that get listings rejected

Google's listing guidance is strict about promotional language in the fields that appear in search results and on shelves - the title, icon, developer name and short description.

Done when: The main store listing saves with no missing-asset error, and the graphics you uploaded still read correctly after the corner mask.

5. Complete App content and reviewer access

App content is the part first-time publishers underestimate, because none of it is engineering and all of it blocks. It is a stack of declarations, and an incomplete or inaccurate answer is one of the most common reasons a launch stalls.

Privacy policy: every app, in two places

Every app needs a privacy policy - not only apps aimed at children, which is how this is often described. Provide the link in Play Console and a link or the policy text inside the app. Use an active, public, non-geofenced URL, not a PDF. An app that collects no data still needs one, and "we collect nothing" is not a policy: it still has to identify the app and developer, give a privacy contact, and describe how any data it does touch is handled and retained. User Data policy

Data safety

Every app on the closed, open or production track completes the Data safety form. Apps that only ever run on the internal testing track are exempt - a genuine reason to use internal testing early. An app that collects nothing still completes the form and says so. Data safety

Declare what your app actually collects and shares, including what your SDKs do on your behalf. That is the part most often wrong: an analytics, ads or crash-reporting SDK collects data whether or not you wrote that code, and the declaration is yours. Read each SDK's own documentation rather than assuming a whole vendor behaves one way.

Account and data deletion

If users can create an account in your app, you must let them request deletion from inside the app and from outside it - a publicly reachable web URL - and deleting the account must delete the associated data. Where law or a legitimate business reason requires you to keep something, disclose it.

Everything else in App content

Beyond privacy, Data safety, deletion and App access above, these remain. Two of them catch people out because the names sound conditional: the Health apps and Financial features declarations are required of an ordinary public app on the closed, open or production track even when it has neither kind of feature. Both have a no-features answer, and completing one does not make medical or financial licensing rules apply to you. Health apps declarationFinancial features declaration

Google Play Console · real screenshot

Give reviewers working access

If any part of your app sits behind a sign-in or another gate, fill in App access. Play Console supports up to five sets of instructions - instruction sets, not necessarily five credential sets, which matters if you have one login and several gated paths. Prepare your app for review

Before submitting, check the credentials still work and that every gated feature is reachable by someone who is not you. Expired accounts, one-time codes that arrive on your phone, and features that only unlock for an internal account are the usual failures.

Done when: App content shows no outstanding task, and someone other than you can sign in with exactly what you wrote in App access.

Category-specific declarations

Beyond the forms above, some policies attach to what the app actually does. These are genuinely conditional:

• Health apps, beyond the declaration. If the app really does have health features, the Health Content and Services policy adds medical-device labelling and a disclaimer requirement for non-regulated health apps, and health apps of the specified kinds require an organization account. Health Content and Services
• Generative AI apps. Prevent prohibited output, and give users an in-app way to report or flag it. This is about what the app produces - separate from the store-asset declarations above, and not a rule that every AI-assisted app carries a label. AI-Generated Content policy
• Photo and video permissions. Request broad access only where a core feature needs it; otherwise use the system photo picker.
• Location and contacts. Both have upcoming minimum-scope requirements with real dates and a narrow scope - see deadlines and conditional changes.
• Other categories. News and magazines, financial services, government apps and others each have a policy page linked from App content.

6. Complete the required closed test, if applicable

Applies to: personal developer accounts created after November 13, 2023. Organization accounts, and personal accounts created before that date, do not have this requirement at all - if that is you, skip to submitting the release.

The rule is short: run a closed test with at least 12 testers opted in across the 14 continuous days preceding your production-access application. The reduction from 20 testers to 12 took effect on December 11, 2024 and kept the same 14 days. Testing requirementsThe 20-to-12 change

Google Play Console · real screenshot

Three tracks, and only one of them counts

Internal testing looks like the obvious shortcut and is genuinely useful - just not for this.

Google evaluates two things: your tester count and your tester engagement. Its own examples of why it asks for more testing include testers who were not engaged with the app during the test, so 12 names on a list is not the requirement. What Google does not publish is any rule about minutes per day or sessions - if you have read a specific daily figure, it is not from Google, and your test should not be planned around it.

How to actually satisfy it

Every other requirement here is paperwork or engineering you control. This one needs 12 real people, on real Android devices, who opt in and stay opted in for 14 unbroken days.

Done when: Play Console shows 12 or more testers opted in and the closed test running for at least 14 continuous days, and the Apply for production action becomes available on the Dashboard.

7. Apply for production access, if required

Applies to: the same accounts as the closed test - personal accounts created after November 13, 2023. Everyone else goes straight to the release.

Meeting the closed-testing criteria does not move you to production by itself. You apply on the Play Console dashboard and answer a questionnaire. It is often described as a fixed ten-question form; Google changes the wording over time, so hold it in your head as three subjects instead.

Write it from the test you actually ran. No phrasing guarantees approval; concrete detail about real testing and real changes is what helps. Generic answers are a known route to being asked for more testing. Worked examples are there to show you how to describe your own test, not to give you a script.

Google says this review usually takes seven days or less, but may occasionally take longer - plan for seven, do not treat it as a ceiling. Production access review timing If access is refused, the usual outcome is a request for more testing rather than a rejection, and your closed test need not stop while you prepare to reapply. What to do after "more testing required".

Done when: Play Console shows production access granted. Nothing before that point - not a complete checklist, not a full 14 days - is the grant itself; the decision is Google's.

8. Submit and publish the production release

Production access, where it applies, unlocks the track - it does not publish anything. The release is its own sequence, and it is where people arrive with everything complete and nothing live. Prepare and roll out a release

1. Countries and regions Start narrow and widen later if you want to.
2. Pricing Set before the first release. A free app cannot later become paid under the same package name.
3. Add the release bundle Select an eligible bundle you already uploaded for testing, or upload a new build with a higher version code. Moving a tested artifact into the production release does not itself require rebuilding it.
4. Release name and release notes The name is internal; the notes are what users see for this version.
5. Read the errors and warnings Console blocks on errors and lets warnings through. Read both - the warning is often what matters later.
6. Send the changes for review Nothing is submitted until you do. A finished release page with unsent changes is one of the quietest ways a launch stalls.
7. Follow it through review and publication In review, ready to publish and live are three different states. If managed publishing is available and enabled, approved changes wait until you select Publish changes - approval alone is not publication. The listing can then take time to appear.

Done when: The publishing overview shows no unsent changes, and the production release reads live - not merely approved. Where managed publishing applies, that last step is yours to trigger. Managed publishing and publication states

How long publishing takes and what can overlap

Two reviews sit near the finish line and they are separate: the production-access review after your questionnaire, and the review of the release itself. Google says access review usually takes seven days or less but may take longer, and that app review can also run beyond seven days in exceptional cases. Neither is capped at a week. Review and publishing timing Stage-by-stage figures: the review time guide.

What genuinely blocks what

Most of this can be worked in any order. Four things cannot, and knowing which four is the difference between a three-week launch and a six-week one.

A planning estimate, clearly labelled as one

Three to five weeks or more is a reasonable plan for a new personal account. That is our planning estimate, not a Google service level, and it assumes an app that is already substantially built, testers who opt in promptly, and no major rework. Building the app is not inside the number, and one round of rework adds to it.

What Console is telling you, and where to fix it

Almost every stall shows up as one of six messages. Read which one you have rather than resubmitting and hoping.

Your stage-specific readiness checklist

Tell it which account you have and what you are working towards. It separates three things the usual checklist blurs together: what you need now, what is required later, and what does not apply to you at all. It is a tracker for your own use - it cannot see your Play Console, and finishing it is not an approval.

Current deadlines and conditional policy changes

These are the dated items that can change what you build or when you ship. Most of them will not reach your app - read the third column before you act on any of them.

Standing requirements with no deadline attached

In force now, and not in any "what changed" list - which is why they catch people who learned this process a year or two ago.

• Closed testing: 12 testers, 14 continuous days, for personal accounts created after November 13, 2023. The number dropped from 20 to 12 on December 11, 2024.
• Account ownership transfers go through Play Console's transfer flow. Direct owner transfer covers organizations and non-monetizing personal accounts; a monetizing personal account uses a different new-account and app-transfer route. Buying, leasing or selling accounts through third parties is prohibited. Transferring ownership
• Organization accounts are mandatory for specified financial services, health, approved VpnService and government apps.
• Photo and video permissions are enforced now. Broad access only where a core feature needs it; otherwise the system photo picker.

PolicyBytes: April 2026 policy updates

Google's Developer Experience team on the contacts and account-transfer policies and the location and age-restricted-content updates above. Optional; the table has the actionable version.

YouTube

How PrimeTestLab helps with closed testing

Seven of the eight stages are paperwork and engineering you control. One needs 12 real people, on real Android devices, opted in and genuinely active across 14 unbroken days - the step solo developers stall on, and the only part we do.

You share your closed testing opt-in link. We handle invitation, opt-in confirmation, daily engagement monitoring and full 14-day retention, replacing anyone who drops out. Any app language, flexible country targeting.

Current packages

Money-back guarantee · Testing typically starts in 4-6 hours · No subscription

Frequently asked questions

What to do next

Where each requirement comes from

Every consequential claim above links its source where it is made; this is the directory version. Google's help pages are largely undated, so a page's modification date is not evidence of when a policy took effect.

What changed in this revision

September 11, 2026

Rebuilt against Google's documentation checked September 8, then revised again after a re-audit of that rebuild. Corrected: the target API requirement (now a per-form-factor matrix); the closed-testing prerequisite order; personal-to-organization conversion; D-U-N-S timing; the scope of the September 30, 2026 registration deadline, and its route, which is a Play Console status check after the app exists; contacts and location to January 27, 2027 at API 37+, with implementation and declaration cumulative; icon, screenshot and preview-video specifications; reviewer access as five instruction sets; the application ID as a property of the build, not the Console record; and release mechanics - an eligible tested bundle can be reused, and approval is not publication where managed publishing applies. Added: device verification, the create-app and release stages, native and Play Billing preflight, AI store-asset declarations, the Health apps and Financial features declarations (required even with no such features), a blocker table, and a source beside each consequential claim. Removed as unsupported: the January 28, 2026 health-migration date, the "five-day" identity myth, the April 2025 Android ID explanation, the feature-graphic 1 MB cap, and the "#1 avoidable rejection" ranking. The readiness checklist was rebuilt twice: it now separates "required later" from "does not apply", and no longer reads submitted work as complete.

June 24, 2026

First published.