Why Apps Get Rejected
Google Play reviews each app before release. The useful first step is not guessing which policy paragraph applies; it is matching the notice to the app behavior, SDKs, declarations, and store listing. The five patterns below are where that check most often finds a mismatch.
Start with the notice
1. Developer Program Policy Violations
The most common rejection category. Google's policies cover everything from ads to user data handling.
Most Frequent Policy Violations
- 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
Your store listing is the first thing Google reviews, and many apps fail at this stage.
Common Metadata Problems
- 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 crashes within the first 30 seconds
- 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 your app on at least 5 different Android devices before submission. Use Firebase Crashlytics to catch crashes early. If your app requires login, provide demo credentials in the review notes.
4. Data Safety and Privacy Issues
Since the Data Safety section became mandatory, incomplete or inaccurate declarations are a major rejection cause.
Common Issues
- Data Safety form does not match actual data collection
- Missing privacy policy (required if you collect any personal data)
- 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
The IARC questionnaire must be completed accurately. Incorrect answers lead to wrong age ratings and rejection.
Common Mistakes
- 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
Evidence 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