On this page (8 sections)
Read the Policy status entry, then the policy itself
Open the app’s Policy status page in Play Console. Note the policy name, the issue description, the affected area (app content, store listing, permissions, Data safety) and any screenshot Google attached. Then read the actual policy in the Developer Program Policies. The notice is usually a summary; the policy text tells you what compliant looks like.
Enforcement types you may see
| Action | Meaning | Severity |
|---|---|---|
| Rejection | The submission was not accepted; fix and resubmit. | Low–medium |
| Warning | Published app must be fixed by a deadline. | Medium |
| Removal | Published app taken down until a compliant update is approved. | High |
| Suspension | App removed; may count as a strike on the account. | Critical |
| Limited visibility / restricted distribution | App stays live but is not discoverable or is limited to some regions. | Medium |
The usual categories, and where the trigger hides
Privacy and user data
Missing or inaccessible privacy policy, data collected before a prominent disclosure, personal or sensitive data shared with third parties, Data safety declarations that do not match behaviour, missing account deletion. The trigger is very often an SDK: analytics, crash reporting, advertising and authentication libraries collect identifiers and device data whether or not you use that data. See Data safety rejection.
Permissions and sensitive APIs
SMS and Call Log, background location, accessibility services, all-files access, package visibility, exact alarms, photo and video permissions. Google requires a qualifying core use case and, for some, a declaration form. Libraries frequently add permissions to your manifest through manifest merging; check the merged manifest, not just your own.
Payments
Digital goods and services sold inside the app must generally use Google Play’s billing system, with defined exceptions for physical goods, certain services and specific regional alternative-billing programmes. Selling digital features through an external checkout or a “buy on our website” link is a common trigger.
App behaviour
Deceptive behaviour (functionality that differs from the description, hidden behaviour, manipulated reviews), disruptive ads, malware and unwanted software findings, and Families requirements for apps that appeal to children.
Metadata and store listing
Misleading titles and icons, impersonation of other brands, unverifiable claims, keyword-stuffed descriptions, inappropriate screenshots. Often fixable in the listing without a new build.
Restricted and harmful content
Gambling, real-money games, financial services and loans, health and medical claims, sexual content, hate, violence and dangerous products. These areas require eligibility, licences, disclosures or are not allowed in some countries.
You are responsible for your SDKs
Third-party code is your code, as far as the policy is concerned
If an advertising, analytics or monetisation SDK collects data, requests permissions or behaves in a way the policy prohibits, the violation is charged to your app. “The library did it” is not a defence. Audit every SDK’s data collection and permissions, keep them updated, and remove the ones you do not need.
Repeated enforcement escalates
Google’s enforcement process considers history. Resubmitting the same build after a rejection, or fixing the cited symptom while leaving the same class of issue elsewhere, tends to produce a removal next, then a suspension. Each step raises the account-level risk. It is worth doing a full review of the app against the policy once rather than a narrow fix three times.
Fix vs appeal
- Fix when the reviewer is right, even partially: change the app, SDK, declaration or listing and resubmit with a short note describing the change.
- Appeal when the finding is factually wrong and you can show it: for example, the reviewer cites a permission the app no longer requests, or a claim the listing does not make. Attach evidence.
- Do not resubmit unchanged, split the app into a second listing, or move it to a new account. All three make the next decision worse.
Before you resubmit
- You can name the exact element (SDK, permission, screen, listing text) that triggered the cited policy
- That element is changed or removed — not hidden behind a flag
- Merged manifest reviewed for permissions added by libraries
- Data safety, privacy policy, content rating and declarations updated to match the new behaviour
- Release notes or the appeal describe the change specifically
What we can implement
After diagnosis we can remove or replace non-compliant SDKs, strip unnecessary permissions and rework features to use privacy-friendly alternatives, implement disclosure and consent flows, move purchases to Play Billing, adjust ad implementations, and correct listings and declarations — across Android native, Flutter, React Native and Unity projects.