Why Apps Get Rejected
The useful first step is not guessing which policy paragraph applies. Match the notice to the reviewed app behavior, SDKs, declarations, reviewer access, and store listing. The five areas below are a diagnostic checklist, not a frequency ranking.
Start with the notice
Source boundary
1. Developer Program Policy Violations
Start with the policy named in the notice. Do not treat this section as a ranking of enforcement causes.
Policy Areas to Check
- Deceptive behavior — App functionality does not match the store listing description
- Intellectual property — Using trademarked names, logos, or copyrighted content without permission
- Restricted content — Gambling, adult content, or regulated substances without proper classification
- Ads policy — Interstitial ads that cannot be closed, deceptive ad placement, or ads in notifications
- Permissions abuse — Requesting permissions that are not necessary for your app's core functionality
How to Fix
Read the policy, behavior, or declaration cited in the rejection notice. Identify what Google actually observed, compare it with the current build and listing, then submit the appropriate remediation or appeal with versioned evidence.
Before resubmitting
2. Store Listing Metadata Issues
Compare every visible claim and asset with the reviewed build and the current metadata policy.
Metadata Checks
- Misleading descriptions — Claiming features your app does not actually have
- Keyword stuffing — Repeating keywords unnaturally in title or description
- Inappropriate screenshots — Screenshots showing content not in the app, or from a different app
- Icon violations — Using Google Play or Android branding in your app icon
- Impersonation — Title or icon too similar to an existing popular app
How to Fix
Ensure every claim in your listing is accurate and verifiable within the app. Use real screenshots from your actual app. Follow Google Play screenshot guidelines and ASO best practices.
3. App Functionality Problems
Crashes, ANRs, broken reviewer access, and incomplete core flows can block review or lead to rejection. Use pre-launch reports and your own device matrix, then provide working access instructions for gated features.
What Triggers This Rejection
- Crash on launch — App fails before a reviewer can reach the primary flow
- Core feature failure — Primary functionality does not work as described
- Login failures — Unable to create account or log in during review
- Excessive loading — Blank screens or infinite loading states
- Broken deep links — Links within the app leading to 404 or error pages
How to Fix
Test the device, Android-version, screen, network, locale, and account states relevant to the release. Use crash and ANR evidence from the tooling available to the app. If login or another gate is required, provide working review access and clear instructions.
4. Data Safety and Privacy Issues
Compare the Data safety declaration and privacy disclosures with the release build, backend, SDK configuration, and user controls.
Data-Flow Checks
- Data Safety form does not match actual data collection
- Missing the privacy-policy link required in Play Console or the privacy-policy link or text required within the app
- Privacy policy URL returns 404 or is not accessible
- Collecting data not declared in the Data Safety form
- Using third-party SDKs that collect data without declaring it
How to Fix
Audit every SDK in your app for data collection. Check Firebase, analytics, ad SDKs, and crash reporting tools. Update your Data Safety form to match reality. See our Data Safety form guide.
5. Content Rating Errors
Complete the current content-rating questionnaire from content and interactions users can actually reach. The generated labels can differ by rating authority and region.
Questionnaire Checks
- Under-rating violence or mature content in your app
- Not accounting for user-generated content (UGC)
- Forgetting that ads can contain mature content
- Marking your app as "no interactive elements" when it has social features
How to Fix
Re-take the IARC questionnaire against the app's actual content and interactive features. Do not intentionally overrate or underrate the app; preserve the answers used to produce the certificate. See our IARC content rating guide.
Prevention Checklist
Before every submission, verify:
- All store listing claims match actual app functionality
- App does not crash on launch and core features work
- Data Safety form matches actual data collection (including all SDKs)
- Privacy policy is accessible and up to date
- IARC questionnaire is accurate
- No trademarked content used without permission
- All permissions are necessary and justified
- Screenshots are from the actual app
- Test credentials provided if login is required
- App tested across the device, screen, and Android-version matrix relevant to its users
Professional Review
Rejection diagnosis
Turn a rejection into a traceable correction checklist
The fastest defensible resubmission path is to map the notice to the build, listing, privacy, Data safety, content rating, and account evidence that actually changed.
Notice
Quote the cited policy and affected surface instead of relying on a generic list of common reasons.
Correction
Record the code, metadata, declaration, privacy, or asset change that addresses the cited issue.
Proof
Keep before/after screenshots, test results, build identifiers, and a concise response history.
Next step: Create one row per cited issue with owner, change, evidence, and resubmission decision.
Open rejection and appeal helpEvidence standard
Primary references
These first-party sources support the changeable platform requirements in this guide. Your current Play Console notice remains authoritative for account-specific steps.
Review your next Play Console step
Tell us what the account shows, where the release is blocked, and what has already been submitted. We will scope the work around the evidence in your case.
Discuss Your Release