10 Common Reasons Google Play Rejects Apps (and Fixes)
The policy issues that most often get Android apps rejected on Google Play: metadata, privacy, permissions, broken functionality, impersonation.
Short answer
The most common causes are misleading metadata, a missing or mismatched privacy policy, Data safety answers that don’t match the app, sensitive permissions without an approved use, no login details for reviewers, broken or minimal functionality, and impersonation of other brands. Each rejection email names the policy, so fix that specific issue.
The list
| # | Reason | Typical fix |
|---|---|---|
| 1 | Misleading metadata: keyword stuffing, fake “#1” claims, unrelated screenshots | Rewrite the listing honestly. See writing a description |
| 2 | Privacy policy missing, broken, or generic | Host an accurate policy at a stable URL. See privacy policy |
| 3 | Data safety form doesn’t match SDKs | Re-audit SDKs and update the form. See Data safety |
| 4 | Sensitive permissions (SMS, call log, all files, background location) | Remove them or complete the permission declaration with a qualifying use |
| 5 | Reviewers can’t log in | Provide working demo credentials in App access |
| 6 | Broken functionality: crash on start, placeholder content | Fix, using the pre-launch report |
| 7 | Minimum functionality: a website in a WebView, a single static page | Add real app value. See TWA and Capacitor |
| 8 | Impersonation or IP: other brands’ names or logos | Use your own branding |
| 9 | Families policy issues: kids audience with non-compliant ads | Fix ads SDKs or the target audience. See target audience |
| 10 | Account deletion missing | Add in-app and web deletion. See deletion link |
Release rejection vs production access refusal
A rejected release is a policy issue with your build or listing. A refused production access application is about your closed test evidence. Different problems, different fixes. See closed test release rejected and production access rejected.
How to respond
- Read the email and Inbox message. They name the policy.
- Read that policy in the Policy Center.
- Fix the root cause, not just the example Google quoted.
- Resubmit with a new version code if code changed.
- Appeal only if you’re confident it’s a mistake. See replying to a policy email.
Prevention
Run through the app content checklist before your first upload, and re-check Data safety every time you add an SDK.
Frequently asked questions
How long after resubmitting will I hear back?
Review times vary from hours to days. Fixing the root cause properly avoids a second rejection.
Can repeated rejections hurt my account?
Repeated or serious policy violations can lead to stronger enforcement. Fix issues completely rather than resubmitting quickly.
Where do I see the rejection details?
In the email Google sends and in Play Console’s Inbox and Policy status pages.
Sources and how we keep this accurate
- Google Play Developer Policy Center
- Play Console Help: Provide information for Google Play’s Data safety section
- Play Console Help: Understanding Google Play’s app account deletion requirements
Policy facts are checked against Google's own documentation on the date shown above. Google can change requirements at any time, so confirm in your Play Console. Where we give advice or estimates rather than Google's rules, we say so. TestersZone is independent and not affiliated with Google. Drafts are AI-assisted and reviewed by our team.
Need 12 testers? Get them free.
Test 3 apps, earn 60 credits, and list your app for up to 20 real testers with verified daily check-ins.
Start freeKeep reading
Your Closed Test Release Was Rejected: What It Means
How to Reply to a Google Play Policy Email
The App Content Checklist to Finish Before Closed Testing
The Real Risks of Fake Testers on Google Play
Every Google Play Requirement for New Developers in 2026
The Solo Developer’s Google Play Launch-Day Checklist
Browse all blog, or see the quick answers, guides and comparisons.