Why your Android app keeps getting rejected from the Play Store

Getting a Play Store rejection with a vague policy violation email is one of the most frustrating experiences in Android development. You spent weeks building something, you submit it, and you get back a three-line email telling you your app violates a policy, often without telling you specifically what or where.

I’ve been through this. Here are the actual reasons behind the most common rejections and what to fix.

”Your app requests permissions it doesn’t need”

This is the most common one for new developers and it’s usually an honest mistake.

Google reviews every permission your app declares in the manifest and checks whether your app’s stated purpose justifies them. If you request READ_CONTACTS but your app is a calculator, that’s an automatic flag.

The fix seems obvious, only request permissions you actually use. But the hidden version of this problem is permissions added by SDKs and libraries you’ve included. Firebase, analytics libraries, ad SDKs, they sometimes add permissions to your manifest that you didn’t explicitly add yourself.

Check your merged manifest in Android Studio (not just your app’s manifest, the merged one that includes library manifests) before every submission.

Also: if you request a permission that requires special declaration (like READ_CALL_LOG, ACCESS_BACKGROUND_LOCATION, or MANAGE_EXTERNAL_STORAGE), you need to fill out the permissions declaration form in the Play Console and justify the use. Skipping this form is an automatic rejection.

”Your app’s privacy policy is missing or insufficient”

If your app collects any data at all, even just crash logs, you need a privacy policy. Not a template you copied from a random generator. An actual policy that accurately describes what your app collects, why, and how it’s handled.

The policy needs to be:

• Hosted at a live URL (not a PDF attachment)
• Linked in the Play Console store listing
• Linked inside the app itself (in settings or about screen)
• Accurate, if you say you don’t collect location data but your app requests location, that’s a violation

The most common mistake is using a generic template that lists data types your app doesn’t actually collect, or misses types it does. Google’s reviewers check whether your policy matches your actual app behavior and permissions.

I host privacy pages for all my apps at darkmintis.dev/appname-privacy. Simple HTML page, covers exactly what that specific app does, links from the app and the Play Console listing.

”Your screenshots or store listing are misleading”

Your screenshots have to show your actual app. Not mockups. Not the app running on a different OS. Not features that aren’t in the version you’re submitting.

Common traps:

• Screenshots showing a feature you removed before submission
• Marketing text in screenshots that makes claims you can’t back up (“Best photo editor on Android”)
• Icon that looks similar to a well-known app (this triggers a separate trademark issue)
• Short description or full description that doesn’t match what the app actually does

Read your own store listing like you’re a suspicious reviewer who’s never seen your app. Does every claim check out?

”Your app targets children but doesn’t comply with Families Policy”

If your app could reasonably be used by children under 13, even if you didn’t build it for them, Google may flag it under the Families Policy.

This catches developers off guard because the determination isn’t just about your intended audience. If your app has cartoon graphics, simple gameplay, or any content that could appeal to children, you might need to comply with Families Policy requirements regardless of what you put in your target audience settings.

Families Policy requirements include things like no interest-based ads, specific content rating requirements, and no links to external websites that aren’t family-safe.

”Policy violation, sensitive content”

This is the vague one that makes developers the most frustrated. It covers a wide range of things:

• Content that could be used to harm (even educational content about security tools needs careful handling)
• Gambling mechanics (including some reward systems that look like gambling)
• Health claims that aren’t medically verified
• Anything touching on dangerous activities

For security tools specifically, hash crackers, network analyzers, penetration testing apps, Google’s policy requires that the app’s primary purpose be clearly educational or defensive. If the description or screenshots could be read as promoting offensive use, you’ll get flagged.

The thing nobody tells you about resubmitting

When you fix a violation and resubmit, the reviewer doesn’t necessarily look at just the thing you fixed. They review the whole app again. Sometimes a resubmission catches a second violation that the first review missed.

This means you should do a full self-audit before every resubmission, not just fix the specific thing they mentioned.

Before you submit, the checklist

Merged manifest, check every permission is justified
Privacy policy, live URL, accurate, linked in app and console
Screenshots, show actual current app, no unsupported claims
Description, accurate, no superlatives you can't back up
Target audience, set correctly, implications understood
Permissions declaration form, filled out if applicable
App content rating, filled out honestly
Data safety section, accurate and matches actual behavior

The Data Safety section is newer and a lot of developers fill it out carelessly. Google cross-references it against your app’s behavior and your privacy policy. Inconsistencies get flagged.

Closed testing (recommended before public release)

Before promoting a build to production, run a closed-test track in the Play Console to gather real-world usage and targeted feedback. Recommended practice:

• Run the closed test for at least 14 days to surface intermittent bugs.
• Recruit at least 12 testers who will use the app regularly during the test window.
• Encourage testers to exercise key user flows, open edge cases, and submit structured feedback via the Play Console testing feedback or by email.
• Publish iterative test builds during the window that address reported issues — reviewers respond better when they see active fixes and improvements.
• Ask testers to provide a short rating or review in the testing channel if available; constructive tester feedback helps demonstrate the app functions in the wild.

Closed testing shows reviewers that the app is stable, used, and improved based on real feedback — a strong signal that increases the chance of a successful public submission. For a detailed checklist and recommended test criteria, see the companion post: Closed testing: preparing your app for review.

Play Store reviews are frustrating but they’re mostly consistent once you understand what they’re actually checking. Most rejections are fixable in an hour if you know what to look for.

If you’re building Android apps and want to see examples of straightforward store listings and privacy pages, check out how I handle it for my apps at darkmintis.dev/android-apps.