Google Play App Rejected? Let’s Find Out What Went Wrong.

Start with Policy status, not the email

The email tells you something happened. The Policy status page in Play Console (under the app’s Policy and programs area) is where Google records the actual issue: the policy name, the affected area (store listing, permissions, Data safety, app content), and frequently the exact element it objects to. Open it before you do anything else and copy the text exactly. Paraphrasing loses the details that identify the root cause.

Check three things there:

• Which policy is named. “User Data”, “Deceptive Behavior”, “Permissions”, “Families”, “Payments”, “Malware” and “Impersonation” each point to a different part of the app.
• Which track and version. A rejected update leaves the live version up; a removal takes the live app down.
• Whether an action is required from you (fix and resubmit, complete a declaration, provide app access) or the notice is informational.

Rejected vs removed vs suspended

Google’s enforcement process names several distinct actions: rejection, removal, suspension, limited visibility, limited regions, a restricted developer account and account termination. They call for different responses, and mixing them up is the most common reason a developer spends days on the wrong fix.

If your notice says suspended or terminated, go straight to the suspension guide or the account termination guide. The rest of this page is about rejections and removals.

Route by problem type

Most Google Play rejections fall into one of these buckets. Match the policy named in your notice to the closest one.

Technical problems

Crashes on the reviewer’s device, an app that does not install, features that do not work, or a target API level below the current requirement. These are engineering issues; no amount of appeal wording fixes them. See reviewer access when the problem is that the reviewer could not reach the functionality at all.

Privacy and user data

The User Data policy, the Data safety section and the account deletion requirement produce a large share of rejections, almost always because the declaration and the app’s real behaviour disagree — usually thanks to an SDK. See Data safety rejection.

Declarations

Content rating questionnaire, target audience, ads declaration, news, financial features, health, government apps, permissions declaration forms. If a declaration does not match what the app does, Google rejects it even when the app itself is fine.

Metadata and submission

Store listing text, screenshots, icon, title, developer name and promotional claims. Impersonation, misleading claims and intellectual property findings live here. Fixable in the listing without a new build in many cases.

Policy issues in the app

Permissions without a qualifying use case, restricted content (gambling, financial services, health), payments outside Play Billing, ad behaviour, Families requirements, deceptive behaviour, malware or non-compliant SDKs. See policy violation.

Reviewer access

If the reviewer could not sign in or reach restricted features, the notice usually asks for app-access instructions. This is the easiest category to fix and the easiest to get wrong twice. See reviewer / app access.

Testing and production access

Personal developer accounts created after Google’s closed-testing requirement must complete a qualifying closed test before applying for production. A denial or a “more testing required” message is not a policy violation, but it blocks publishing. See production access rejected and more testing required.

Fix or appeal?

Google’s enforcement process allows you to appeal decisions you believe are mistaken. A strong appeal names the policy, explains precisely what the app does, points to the exact place the reviewer’s reading diverges from the facts, and attaches evidence. A weak appeal restates that the app is “compliant” without addressing the cited issue. If you are not sure which situation you are in, that is exactly what our initial review is for.

Still in review, or pending publication?

A release that sits in “In review” or “Pending publication” is not a rejection and there is nothing to appeal. Reviews take longer for a first submission from a new account, after a policy-sensitive change (permissions, data safety, target audience), and when managed publishing is switched on — in that case the release waits for you to publish it, which is worth checking before assuming Google is slow. Check Play Console → Publishing overview for a pending change list, make sure no declaration is half-finished, and confirm the app access credentials still work. Contact Play Console support only when the release has been stuck well beyond the timeline shown in the console.

Not a rejection: technical publishing blocks

Some Play Console messages look like rejections but are technical requirements with dates attached — “must target Android 16 (API level 36)”, a deprecated Play Billing Library version, 16 KB page size compatibility, an upload refused over the signing key, or an app that needs registering under Android developer verification. There is nothing to appeal; the build has to change. Those cases are covered on legacy app update, target API level 36, Billing Library 8, 16 KB page sizes, lost keystore / upload key and Android developer verification; the dates are collected on app publishing deadlines. You can also paste a build file into the Android update readiness checker to see which of them apply to your project.

Before the first submission

Most first-submission rejections are predictable: a declaration that does not match the build, a permission that needs a form, a reviewer who cannot sign in. Work through the Google Play submission checklist first, then the two areas that produce the most questions — sensitive permissions and declarations and app content declarations and content rating.

What we can change, not just explain

Because App Rejection Fix is operated by a development company, the recommendation does not stop at “update your Data safety form”. Typical work after a Google Play diagnosis includes:

• Auditing SDKs and permissions against the User Data and Permissions policies and removing what the core feature does not need
• Implementing prominent disclosure and consent flows, in-app and web account deletion, and privacy-policy alignment
• Fixing crashes, install failures and target API level issues on Android, Flutter, React Native and Unity builds
• Rebuilding payment flows on Google Play Billing where the Payments policy requires it
• Making reviewer access work: durable credentials, OTP bypass for review accounts, region handling
• Correcting store listing metadata and declarations so they match the app

What to send us

1. The Policy status text, copied exactly, and the email notice.
2. Screenshots of the notice and, if provided by Google, the screenshots Google attached.
3. The app name, package name, current track and the technology stack.
4. Whether this is a first rejection, a repeat, or a rejection after an appeal.

Frequently asked questions