A rejection email from Google Play is short, vaguely worded, and usually arrives after you have told everyone the launch date. It names a policy, links to a page of general guidance, and leaves you to work out which line of your app or listing caused it.

The frustrating part is that most rejections are not about the code. They are about declarations, permissions and listings — paperwork that could have been correct the first time. This guide covers the ones that actually catch people, what each really means, and how to fix it.

Data safety declarations that do not match the app

This is the most common rejection for first-time developers, and it happens because of a genuine misunderstanding rather than carelessness.

The data safety form asks what your app collects and shares. Most developers answer for the code they wrote. But the declaration has to cover everything the app does, including every third-party SDK inside it. Ad networks, analytics libraries, crash reporting tools and social login providers all collect data, and much of it is collected the moment the SDK initialises.

So you declare “no data collected” in good faith, Google’s automated analysis sees an advertising identifier leaving the device, and the submission is rejected for an inaccurate declaration.

• Read your SDK documentation. Most ad and analytics providers publish exactly what their SDK collects specifically so developers can complete this form. Use it rather than guessing.
• Declare more rather than less. Over-declaring is not a policy violation. Under-declaring is.
• Update it when you add anything. Adding an ad network after launch changes what the app collects, and the form has to change with it.

Privacy policy problems

Three distinct failures live under this heading, and they are easy to avoid.

The link is broken. A URL that returns a 404, sits behind a login, or points at a document that has moved. Reviewers open the link. Check it from a browser where you are not logged in, on a device you have never used before.

The policy does not mention the app. A generic template covering a website, when the submission is an Android app that collects location data. The policy has to describe what this app actually does.

The policy contradicts the declaration. Your data safety form says you collect an advertising identifier; your privacy policy says you collect nothing. Reviewers compare them.

Permissions you request but never justify

Every permission needs a visible, understandable reason inside the app. A note-taking app asking for location, a calculator asking for contacts, a torch asking for microphone access — these get flagged because there is no evident purpose.

This often happens accidentally. A library you added requests permissions in its own manifest, and they merge into yours without you noticing. Check your merged manifest rather than the one you wrote.

• Remove any permission the app does not actively use.
• Request sensitive permissions at the moment they are needed, with an explanation, rather than all at once on launch.
• Sensitive permission groups — location in the background, SMS, call logs, storage access — attract particular scrutiny and often require a declared, approved use case.

Listings that promise more than the app delivers

Screenshots showing a feature that is planned rather than built. A description listing capabilities the current version does not have. Mockups presented as real screens.

Reviewers install the app and compare it to the listing. Anything present in one and absent from the other is a misrepresentation issue, and it is one of the easier rejections to trigger without meaning to — particularly when a launch gets cut down and the listing is not updated to match.

The same applies to placeholder content. Empty screens, lorem ipsum, buttons that do nothing, and features labelled “coming soon” all read as an incomplete app.

Content and functionality issues

• Minimum functionality. Apps that are a wrapper around a website, or that duplicate something already on the store without adding anything, get rejected as low value.
• Content rating mismatch. The questionnaire answers have to reflect what is actually in the app, including anything user-generated.
• User-generated content without moderation. If users can post, you need a way to report content and a stated moderation approach.
• Crashes on launch. Reviewers test on real devices. An app that crashes on the reviewer’s hardware fails regardless of whether it works on yours.

Account-level problems

These are less common but far more serious, because they affect everything you publish rather than one submission.

Google operates a one-account-per-person policy. If you have previously had a developer account terminated, creating a new one under the same identity is itself a violation, and the new account is liable to be closed when the connection is found. The registration fee is not refundable.

Related accounts are connected through more than name and email — payment details, device signals and other identifiers all feed into it. If you are in this situation, the route back is an appeal on the original account rather than a new registration.

Policy areas that catch specific app types

Beyond the general causes, certain categories run into rules that do not apply to everyone. If your app touches any of these, read the relevant policy before building rather than after rejection.

Apps handling money or financial data. Lending, payments, cryptocurrency and investment apps face additional requirements that frequently include documentation proving you are licensed to operate in the markets you target. This is one of the few areas where the paperwork can take longer than building the app.

Health and medical apps. Anything offering diagnosis, treatment guidance or symptom assessment attracts close scrutiny, and claims made in the listing are checked against what the app can actually support.

Apps aimed at children. If your target audience includes children, a separate and stricter set of rules applies covering ads, data collection and content. Declaring a child audience without meeting those requirements is a reliable rejection.

Apps using accessibility services. These are powerful and heavily restricted. Using accessibility APIs for anything other than genuinely assisting users with disabilities is a policy violation, and automation tools built this way are routinely removed.

Apps that download or execute code. Loading executable code from a remote source at runtime is restricted, because it means the reviewed app and the running app can differ.

Removal after publication is a different problem

Getting through review does not settle things permanently. Apps are re-evaluated when they update, when policies change, and when user reports accumulate. An app live for two years can be removed for a rule that did not exist when it launched.

The most common cause of post-launch removal is a policy deadline passing — a new target API requirement, a changed permission rule, an updated declaration format. Google announces these in advance through Play Console and developer email, which is a good reason to actually read those messages rather than filtering them.

• Keep the console email address current and monitored. Policy notices and enforcement warnings arrive there first.
• Act on warnings before the deadline. Most enforcement gives a window. Apps get removed because the window closed, not because the warning never came.
• Re-check declarations when you add SDKs. The most common cause of a compliant app quietly becoming non-compliant.

How to respond to a rejection

1. Read the named policy, not just the email. The email is generic; the linked policy page tells you what is actually being enforced.
2. Find the specific cause before changing anything. Guessing and resubmitting repeatedly wastes review cycles and looks careless.
3. Fix it properly rather than superficially. Removing a screenshot when the problem was the underlying claim just moves the issue.
4. Resubmit with a clear note. Where the console allows a comment, say plainly what you changed.
5. Appeal if you believe it is wrong. Rejections are sometimes incorrect. A calm, specific appeal explaining why the app complies is worth filing — but only when you genuinely believe it, since repeated baseless appeals do not help.

A pre-submission checklist

• Privacy policy URL opens in a private browser window and describes this app.
• Data safety form matches every SDK in the build, not just your own code.
• Merged manifest contains no permissions the app does not use.
• Every screenshot shows a feature that exists in the submitted build.
• No placeholder text, empty states or non-functional buttons.
• App installs and runs on a clean device with no developer tools.
• Content rating questionnaire answered honestly, including user-generated content.
• Target API level meets the current requirement.

Frequently asked questions

How many times can I resubmit?

There is no fixed limit, but repeated rejections for the same issue suggest you have not found the real cause. Diagnose properly rather than iterating blindly — repeated violations can escalate to account-level action.

Does a rejection hurt my account?

A single rejection that you fix is routine and carries no lasting penalty. A pattern of repeated violations across submissions is what creates account risk.

How long does review take after resubmitting?

Usually similar to the original review, roughly one to three days, though it varies. First submissions and apps in sensitive categories are generally examined more closely than routine updates.

Can I talk to a person?

The appeal process is the route to human review. Support channels exist in Play Console, but responses to policy questions are often templated. A specific, factual appeal referencing the exact policy tends to get further than a general complaint.

The pattern behind all of it

Nearly every rejection above comes down to a mismatch: between what you declared and what the app does, between what the listing shows and what it delivers, between the permissions requested and the ones used.

Check those three alignments before submitting and most rejections never happen. It is dull work, and it takes an hour, and it is considerably faster than a rejection cycle.

If you have not submitted yet, our Play Store publishing guide covers the testing requirements that come first, and the ASO guide covers making the listing work once you are through.