Google Play Policy Checklist for 2026: Before You Submit

First, check the account and the release calendar

The awkward Google Play problems rarely begin with a dramatic policy violation. More often, the release is ready, screenshots are approved, and someone notices that the Data safety answer does not match an analytics SDK or that the reviewer cannot pass a one-time code. A small mismatch then sends three teams back to work.

That is why we do not treat Play review as a final form for one developer to complete. Store rules reach into the product itself: account deletion, permissions, digital purchases, moderation and access to restricted areas. If those decisions arrive during upload week, code, legal text and store assets all have to move at once.

This checklist was reviewed on 8 September 2026. Google updates Play policies and deadlines throughout the year, so follow the linked source pages before each release. The practical method is stable even when a date changes: keep one record of the app's real behavior, then make every declaration agree with it.

Before checking screenshots or descriptions, open Play Console and establish whether the account can publish the app at all.

New personal developer accounts created after 13 November 2023 must generally run a closed test with at least 12 testers opted in for 14 continuous days before applying for production access. Installing the app on the last day is not a substitute for an actual test period. Plan a representative group, a feedback channel and a few concrete scenarios so the production-access answers are supported by evidence.

The target API deadline is separate. From 31 August 2026, new apps and updates submitted to Google Play generally need to target Android 16, API level 36 or higher. Wear OS and Android Automotive apps need API 35 or higher; Android TV and Android XR use API 34 or higher. Existing apps have their own discoverability requirement. Check the current target API page rather than copying last year's number into a project plan.

The next Android developer-verification milestone is 30 September 2026, but it is not a universal deadline for every market. The regional rollout starts in Brazil, Indonesia, Singapore and Thailand, for participating stores on certified devices running Android 7 or later. Wider rollout is planned for 2027. Check the package status in Play Console rather than assuming automatic registration has covered your app.

Treat the release as one evidence set

The easiest way to miss a policy issue is to let several people remember the product differently. The mobile developer knows the permissions, marketing writes the listing, someone else publishes the privacy policy and an account owner answers the Play Console declarations. Each contribution can be reasonable on its own while the finished release tells four slightly different stories.

Our preference is one modest release record, owned by a named person and checked against the actual signed build. It does not need to become a heavy compliance project. A shared page with these rows is enough:

Freeze this record against the release candidate. If an analytics, advertising or support SDK changes after the forms are completed, reopen the forms. If a planned feature is removed, remove it from screenshots and description too.

Audit Data safety from the code, not from the privacy page

The Data safety form is a structured account of collection and sharing. The privacy policy is a fuller public explanation. They should agree, but one should not be guessed from the other.

Start with the release build and list every data path. Include registration fields, analytics events, crash reports, device identifiers, support chat, uploaded files, location, payment state and data handled by embedded SDKs. Google makes the developer responsible for SDK behavior as well as first-party code. An analytics library configured without advertising identifiers may produce a different answer from the same library with advertising features enabled.

Record purpose as carefully as data type. An email used for authentication is not automatically the same as an email exported to a marketing platform. Note whether data is sent off the device, whether it is optional, whether it is encrypted in transit and whether the user can ask for deletion. Keep screenshots or configuration exports with the release notes so the next update does not rely on memory.

The mobile app privacy policy guide explains how the public policy, store disclosure and technical behavior fit together. It is not legal advice; products involving health, finance, children or regulated identity checks need appropriate specialist review for the target market.

Make account deletion a complete user journey

If users can create an account in the app, Google Play requires a way to request deletion from inside the app and through a web resource linked in Play Console. A support email hidden in terms is not the same as a clear deletion route.

Test the entire journey with a real account. Can the user find deletion without contacting support? Does the web page identify the app and developer? Does it explain which data is deleted, which may be retained and for how long? Does the backend actually remove or anonymize the right records? What happens to subscriptions, open orders, invoices, marketplace disputes or content that must remain for legitimate reasons?

Deletion often reaches further than the profile table. Authentication, file storage, marketing tools, support systems and backups may all hold related records. The product owner should define the expected result; engineering should document how each system implements it.

Ask for the minimum permission at the moment it is needed

Compare AndroidManifest.xml, runtime prompts and Play Console declarations. Remove permissions left by old libraries or abandoned features. For each sensitive permission, write one sentence that explains which user action would fail without it.

Prefer scoped platform tools. A photo picker is usually more appropriate than broad access to the media library when the user selects one image. A one-time contact selection is different from reading the address book continuously. Background location needs a stronger product reason than showing nearby places once.

Google announced additional contact and precise-location policy changes for late October 2026, together with new pre-review checks. Apps targeting Android 17 should review the Contact Picker and location-button guidance early rather than waiting for a rejection. A delivery tracker may need persistent location; an invitation flow probably does not need the full contact list.

The Android security checklist covers secure storage, backend authorization and release secrets. Those are engineering controls; the present checklist focuses on whether the Play submission describes them accurately.

Give reviewers durable access to every restricted feature

If any part of the app sits behind login, membership, location, a paywall or another authentication step, provide working access in Play Console. Credentials must be reusable, available regardless of reviewer location and maintained while the app is distributed. An expiring one-time password, a test account that has already reached its usage limit or a backend restricted to one office IP can block review.

Prepare a review path, not only a username and password. Explain how to reach the main feature, switch roles, see paid content, trigger a booking or test a restricted area. Google asks for sign-in instructions in English; if the interface is localized, describe the labels the reviewer will see. For QR codes or non-alphanumeric access, provide a stable resource according to Play Console instructions.

Test those instructions on a clean device with someone who did not build the app. If that person needs a private message from the developer, the reviewer will probably be stuck too.

Make the store page prove the real product

Metadata policy applies to every translation of the listing. The app name, short description, full description, icon, feature graphic, screenshots and video should represent the current build without keyword stuffing, unverified awards or features that are still on the roadmap.

Use real in-app screens. Marketing composition is acceptable, but the underlying experience must exist. If screenshots contain text, localize the images for the supported store language and check that currency, dates and payment terms are appropriate. The Google Play screenshot requirements page covers sizes and asset planning; the localization checklist covers market-specific copy and images.

Read the listing as a reviewer and as a first-time user. Can each important claim be demonstrated in the build? Is subscription pricing clear before purchase? Does a screenshot imply an automated result that actually requires manual support? Honest metadata reduces both review risk and poor reviews after launch.

Complete the declarations that match the business model

Not every app sees the same forms. Play Console may require answers about ads, target audience, content rating, news, health, financial features, government affiliation or other sensitive categories. Do not choose a safer-looking category to avoid work. The app's audience, claims and functions determine the declaration.

Products with user-generated content need terms, reporting and blocking appropriate to their interactions, plus an operating process for moderation. Apps aimed at children face additional Families requirements. Health and finance products need especially careful claims and declarations. If the app sells digital content or features, review the current Google Play payments policy and any applicable regional or program exception before designing an external checkout route.

This is where a small feature can create large scope. Adding private chat means more than a message screen; it may require reporting, blocking, support visibility and retention rules. Adding subscriptions means entitlement recovery, cancellation state, clear terms and purchase testing. Put those requirements into the estimate rather than calling them store paperwork. The Appfyl estimate brief helps identify such functional dependencies before development.

Test the exact signed bundle that will be submitted

A policy-compliant description cannot rescue a build that crashes, never finishes loading or hides its main value behind a broken login. Test the signed release bundle and production-like backend, not only a debug build.

Run a clean install, update from the previous version, account creation, recovery, deletion, denied permissions, weak network, core purchase or booking, deep links and every role given to the reviewer. Confirm that test payments cannot become accidental real charges. Watch crash reporting and Android vitals during internal or closed testing.

Use Play Console pre-review checks where available, but do not treat a clean automated check as approval. Automated tools only inspect part of the policy surface. The broader Google Play quality checklist and mobile QA checklist cover stability and device behavior in more depth.

A practical 48-hour pre-submission audit

Two days before submission, stop adding optional SDKs and marketing claims. Build the release candidate and repeat the evidence check with named owners.

On the first day, engineering confirms package name, signing, target API, permissions, SDK inventory, deletion behavior and reviewer credentials. Product checks payments, roles, moderation, support and every special declaration. Marketing compares every line and screenshot with the build.

On the second day, someone outside the delivery team follows the review instructions on a clean device. The release owner opens every public URL, verifies the Data safety answers against the SDK list, saves a copy of the declarations and confirms that the business controls the Play Console account. Only then should the bundle be submitted.

Leave time for review in the launch plan. Approval timing is not guaranteed, and changing unrelated listing or app details while a review is in progress can complicate release coordination. The mobile app launch checklist connects store work with analytics, support and first-week monitoring. If a build has already been rejected, use the rejection-fix guide rather than resubmitting the same package with a hopeful note.

A filled release record catches more than a generic tick

For a fictional booking app, record the candidate build, its package name and the date tested. Then write one finding: “Account deletion is available in Settings, but the public deletion link redirects to a login page.” Assign the web owner and keep the release item open until a person without an account can reach the required information. A green checkbox saying “privacy done” would hide the problem.

Use the same method for reviewer access. Record that a fresh installation can reach a paid test class with the supplied demo account, without a one-time code or a real charge. If a server change invalidates that account tomorrow, the evidence is no longer current. Recheck the affected item instead of repeating an entire audit from memory.

A clean checklist supports a release decision; it does not guarantee store approval or continuing compliance. Keep the build identifier and unresolved issues with the evidence, and use Appfyl's project information to discuss who will own this work.

Questions people ask