A Google Play rejection always comes down to one of about ten reasons, and every one of them has a known fix. The rejection email names a policy but rarely explains what you actually did, so here is the full list in plain language: what each rejection means, how to fix it, and how to resubmit without triggering the next one.
First: which kind of rejection is this?
Two very different things get called “rejected”, and the fix depends on which one you have.
- App or update rejected in review. Google reviewed your submission and refused it for a policy or quality reason. This list is for you.
- Production access refused. You finished closed testing, applied, and Google said your app “requires more testing”. That is not a policy problem, it is a testing-engagement problem, and it has its own guide: more testing required, how to fix it.
The rejection reasons, most common first
1. Broken functionality
Crashes on launch, buttons that do nothing, placeholder screens, features that require accounts nobody can create. Google installs and uses your app; if it does not work, it does not pass. Fix: test on a real device before submitting, and if your app needs a login, provide working demo credentials in the App access section of Play Console.
2. Minimum functionality and webview wrappers
Apps that are just a website in a frame, offer almost no interactive value, or duplicate what a browser tab does get refused under minimum functionality. This is the same reason we do not accept TWA apps for testing: Google is openly hostile to thin wrappers. Fix: add genuinely native value (offline behavior, notifications, device features), or convert the wrapper into a proper WebView app with real app behavior around it.
3. Store listing problems
Keyword stuffing in the title or description, screenshots that show a different app, claims you cannot support, or mentioning other brands (“better than WhatsApp”). Fix: describe what the app does in normal sentences, use real screenshots from the current build, and keep competitor names out of your listing entirely.
4. Intellectual property
Another company’s name, logo, characters, or content in your app or listing without permission. This includes lookalike icons and “unofficial” clients for popular services. Fix: remove the protected material, and if you have permission, respond to the rejection with proof of it.
5. Data safety form does not match reality
Your Data safety section says you collect nothing, but an ads or analytics SDK in the build collects device identifiers. Google scans the binary and compares. Fix: audit what your SDKs actually collect, redo the Data safety form to match, and make sure your privacy policy URL works and covers the same list.
6. Permissions you cannot justify
SMS, call log, background location, and accessibility access are restricted; requesting them without being the kind of app that needs them is an automatic problem. Fix: remove permissions your core feature does not require. If you genuinely need one, complete the declaration form for it and expect a slower review.
7. Target API level too old
Google requires apps to target a recent Android version, and both new submissions and updates get blocked when they fall behind. Fix: raise targetSdkVersion, rebuild, resubmit. The current deadlines and details are in our target API level guide.
8. Content rating and ads mismatches
A questionnaire that says “no ads” while the app shows ads, a rating of Everyone on an app with mature content, or ad formats that trap users (unclosable interstitials, ads that look like system warnings). Fix: redo the content rating questionnaire truthfully and use standard, dismissible ad placements.
9. Deceptive behavior
Apps that claim features they do not have, mimic system apps, hide what they install, or manipulate reviews. Less common for honest developers, but it also catches innocent-looking things like “cleaner” and “booster” claims that cannot be demonstrated. Fix: make every claim in the app and the listing literally true.
10. Account and verification issues
Sometimes it is not the app: an unfinished developer verification, mismatched developer details, or an account flagged for association with a previously terminated one. Fix: complete verification in Play Console first; nothing ships while it is pending.
How to resubmit after a rejection
- Read the rejection in Play Console under Policy status, not just the email. It names the policy and usually the offending element.
- Fix the actual cause, not the symptom. A rejected screenshot means the listing gets reviewed harder next time; resubmitting the same thing burns goodwill.
- Bump the version code, upload, and resubmit. Reviews usually clear within a few days; up to about seven for new apps.
- Wrongly rejected? Appeal through the Policy status page with specifics. Real errors do get reversed, but only when you point at the exact policy and explain why your app complies.
Rejections are annoying but rarely fatal: fix, resubmit, pass. The pattern to avoid is repeated careless resubmissions, which is what puts accounts at risk.
If your rejection is about testing, not policy
For new personal accounts, the most common “rejection” is really the production access review after the 14-day closed test, and it fails for one reason: testers who installed but never engaged. That one is solvable in advance. We wrote up why apps fail production access, and if you need engaged testers, Testers Community assigns them within 6 hours.
Frequently asked questions
How long does Google take to review a resubmission?
Usually a few days, up to about seven for new apps. Repeated rejections can slow later reviews, so make each resubmission count.
Will a rejection hurt my developer account?
A rejection by itself, no. A pattern of serious or repeated violations can lead to strikes and, in extreme cases, account termination. Fix carefully rather than resubmitting fast.
Can I appeal instead of changing the app?
Yes, through the Policy status page, and appeals do succeed when the reviewer made a genuine mistake. If the rejection accurately describes your app, fixing beats appealing every time.
My app was rejected for “more testing required”. Which reason is that?
None of the policy reasons above. That is the production access review judging your closed testing engagement. See the dedicated guide linked at the top, and run the next test with testers who actually use the app daily.
