App Store rejections come back as guideline letters; Google Play works differently. Play evaluates apps against the Developer Program Policies, and enforcement runs from a single blocked submission to a live app being removed and, in more serious cases, to the developer account itself — with a formal Managing Policy Violations and Appeals process for developers to contest decisions. Two dates make compliance urgent right now: Google announced its policy update on July 15, 2026 and gave developers "at least 30 days" to comply — that window has now closed — and the next target API level requirement lands on August 31, 2026. Here are the eight violations behind most rejections and removals this year, and the fix for each.
1. Deceptive behavior and misrepresentation
Under Privacy, Deception and Device Abuse, Play's Deceptive Behavior and Misrepresentation policies are the enforcement backbone for dishonest apps. Deceptive behavior typically shows up as manipulated ratings or reviews, store-listing claims that the app does not deliver, or an app that impersonates another product or brand.
- The fix: audit every sentence in your store listing against what the build actually does.
- Never buy reviews or incentivize ratings — rating manipulation is a classic account-level trigger.
- Do not use another app's name, icon, or branding to borrow its recognition.
2. Outdated target API level
Google requires all apps to meet the latest target API level requirements by August 31, 2026. This is the regular yearly update, and a stale targetSdkVersion is one of the most common reasons new submissions are rejected outright.
- The fix: check
targetSdkVersionin your Gradle config now, update it to the required level, and test on the current Android release before the deadline. - Upload the fresh AAB as a new release — do not wait for a rejection to act.
3. Unregistered apps and Play Console requirements
Under the current developer verification rules, you must register your Play apps in Play Console. Google warns that apps which stay unregistered risk global removal from Google Play, and registration also matters for apps distributed outside Play that should still install on certified Android devices.
- The fix: open Play Console Home and register every app you intend to keep distributing — the check takes minutes and unregisters are fully avoidable.
4. Sensitive permissions — SMS and call logs
The SMS and Call Log Permissions policy no longer permits account verification via phone call as a use case for the READ_CALL_LOG permission. Apps still requesting it for that purpose are now policy violations on renewal and review.
- The fix: migrate verification to the
Digital Credentials APIor theSMS Retriever API, which Google recommends as secure alternatives. - If you do not have a still-permitted use case, remove the permission entirely.
5. Anonymous chat apps and child safety
The July update tightened the rules for minors: Age-Restricted Content and Functionality and Child Safety Standards now have new requirements and restrictions for anonymous chat and random chat apps, and the Families Policy now prohibits anonymous chat apps from targeting children.
- The fix: for any chat app, either remove anonymous/random matching or add meaningful age gating, moderation, and reporting.
- If your app targets children, anonymous chat is not an option at all — redesign around it.
6. Missing or incorrect content ratings
Google clarified in the July 2026 update that it does not allow unrated apps on Google Play. An app without a completed rating questionnaire can be rejected or removed.
- The fix: complete the content rating questionnaire for every app, and re-run it whenever you add content that could change the rating.
7. Spam, functionality, and Mobile Unwanted Software
Play's Spam, Functionality and User Experience, Malware, and Mobile Unwanted Software (MUwS) policies target apps with minimal or misleading functionality, repetitive content, and bundled unwanted behavior.
- The fix: ship an app with real, working functionality — do not pad a store with near-identical shells.
- Audit every SDK in your binary for MUwS-class behavior: hidden downloaders, misleading install prompts, or background ad injection.
8. Deceptive and disruptive ads
Ads are treated as part of the app. Per the Ads policy, ads must follow the Restricted Content policies, must not simulate or impersonate the user interface of any app feature (such as system notifications), and must not be displayed in ways that cause inadvertent clicks or interfere with device functions.
- The fix: review each ad network and creative before launch; no ad UI that mimics system elements, no full-screen interstitials that hijack taps.
- Keep every ad appropriate for the app's content rating — a mature ad in an Everyone app is itself a violation.
The one-line takeaway: on Google Play, a rejection usually means a policy violation — so fix the behavior, not the wording. Honest listings, a current target API level, registered apps, clean permissions, age-safe chat, rated content, real functionality, and compliant ads keep you off the enforcement path entirely; the appeal process is for when enforcement got it wrong.