Why Google Play rejected your app, and what to change before you resubmit
A Play rejection is rarely mysterious. The email names a policy, the policy names a requirement, and the fix is usually smaller than the panic suggests. What makes it expensive is resubmitting without changing the thing that was flagged.
These are the twelve reasons that account for most first Android submissions, in the order they actually happen. Each entry gives the policy behind it and the change that clears it.
1. Target API level is too low
Since 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher; the extension window closed on 1 November 2026. Wear OS, Android TV and Automotive have slightly different floors, but the main track is API 36.
The common mistake is bumping targetSdkVersion in the project and uploading an older signed bundle. Check the artifact you actually uploaded: the Play Console release page shows the target SDK it detected, and bundletool can print it locally.
2. The Data safety form contradicts the app
Data safety is a declaration, and Play checks it against observed SDK behaviour and your privacy policy. Declaring no collection while shipping an ads or analytics SDK is the single most common mismatch.
Walk the merged manifest for SDKs you did not add yourself, list what each one collects, and make the privacy policy say the same thing in the same words.
3. Permissions that no feature uses
SMS, call log, background location, all-files access and accessibility are reviewed closely and need a core-feature justification. A permission copied from a starter template reads as data collection without purpose.
Remove it, or move the feature behind an explicit user action so the runtime prompt has context. Accessibility Service in particular is rejected unless it is the product itself.
4. A WebView-only app with no added value
Play's spam and minimum-functionality policies reject apps that are a browser frame around a website with nothing added. This is the risk every website-to-APK conversion runs into, and it is worth designing around rather than arguing with.
Clear it by shipping what a browser tab cannot: offline handling with a real fallback screen, native navigation and back behaviour, push notifications, a share target, file upload that works from the WebView, or a login that persists. Document those features in the release notes — reviewers read them.
5. Broken core functionality
Blank screens, crashes on launch, dead buttons and "no internet" loops are rejected as broken functionality. They usually appear only in the release build: minification stripping a reflection-based library, a missing ProGuard rule, or an API base URL still pointing at localhost.
Test the signed release artifact on a clean device, with the network off and with a low-end screen size, before uploading.
6. Reviewer access not provided or not working
If the app requires sign-in, Play needs credentials that work at review time. Expiring demo accounts, OTP-only logins with no bypass, or a regional block on the reviewer's location all read as "app inaccessible".
Provide a dedicated review account, keep it alive, and describe the path to the paid or restricted area in the App access field.
7. No account deletion path
If users can create an account in the app, they must be able to delete it — in the app or through a clearly linked web page — and the Data safety form must point to it.
A "contact support to delete" email address is not enough unless the policy allows it and the route is documented.
8. Ads that break the experience
Full-screen interstitials on launch, ads that appear behind a tap by accident, and ad layouts that cover content are treated as disruptive ads. Ads inside an app aimed at children have separate rules entirely.
Move interstitials behind a natural break, never on first open, and keep a visible close control.
9. Impersonation and intellectual property
Using another company's name, icon, screenshots or brand colours in a way that implies affiliation is rejected as impersonation. Unlicensed fonts, images and audio are rejected as IP infringement.
Use assets you can prove you own, and keep the receipts: stock licences, font licences, commissioned artwork.
10. The store listing does not match the app
Screenshots that show features the app does not have, a title stuffed with keywords, or a description referencing another platform all fall under metadata policy.
Screenshots must come from the app. Keep the title under the character limit, avoid "best", "#1", "free" style claims, and do not name competitors.
11. Families and sensitive categories
An app that targets children must use a families-compliant ads SDK, avoid interest-based advertising, and declare the target audience correctly. Health, finance and government categories carry extra documentation requirements.
If the audience is mixed, use the neutral age screen rather than declaring the app as adult-only to dodge the rules — that gets flagged too.
12. Repeated policy strikes
Repeated rejections of the same policy can escalate to a suspension of the app or the developer account. Two failures on one policy is the point to stop resubmitting and read the policy line by line, or appeal with a written explanation.
Use the appeal route in Play Console with a specific account of what changed; general assurances are not reviewed as a fix.
Pre-submission checklist
Target API 36 or higher in the uploaded AAB. Data safety matching every SDK in the merged manifest. Permissions limited to features that exist. Release build tested offline on a clean device. Reviewer credentials valid. Account deletion route live. Privacy policy URL reachable and consistent. Screenshots from the real app. Content rating completed.
If you are building the Android file with APKBuild, the build log already tells you the target SDK and the permissions that went into the manifest — check them against this list before you open Play Console.
Step-by-step
- Read the exact policy named in the rejection email: Play Console names the policy and the app version it applied to. Open that policy page; the email paraphrases it, and fixing the paraphrase instead of the policy is why a second submission fails the same way.
- Check the target API level of the uploaded artifact: New apps and updates submitted after 31 August 2026 must target Android 16 (API level 36) or higher. Confirm it in the AAB, not in your Gradle file — a stale bundle is the usual culprit.
- Make the Data safety form match reality: List every category the app actually collects, including data gathered by third-party SDKs such as analytics and ads. A form that says "no data collected" next to an advertising SDK is an automatic mismatch.
- Remove permissions you do not use: Every dangerous permission in the manifest must be justified by a feature. Drop the ones copied in from a template, and use the runtime prompt only where the feature needs it.
- Give reviewers a working path into the app: If anything sits behind a login, supply credentials in App access and keep them valid through review. A reviewer locked out is a rejection regardless of quality.
- Test the release build with no network: Install the exact AAB locally with bundletool, open it in airplane mode, and confirm it shows something useful. Blank screens and infinite spinners are logged as broken functionality.
- Resubmit with a specific change note: State the policy, what you changed, and where. A one-line "fixed issues" note gives the reviewer nothing to verify and often costs another cycle.
Frequently asked questions
How long does a Google Play review take after resubmission?
First reviews commonly take a few days and can take longer for new accounts; updates to an established app are usually faster. Resubmitting does not reset the queue to zero, but it does start a new review of the new artifact.
Can I appeal a rejection instead of resubmitting?
Yes, when you believe the policy was applied incorrectly, and Play Console shows an appeal route for that decision. For a genuine policy failure an appeal without a change is usually answered with the same policy text; fix first, then resubmit.
Does converting a website to an APK get rejected automatically?
No, but it is reviewed against the minimum-functionality and spam policies. A site that works as a product, with offline handling and app-level features, can pass; a thin wrapper around a marketing page usually does not.
What target API level does Google Play require now?
New apps and app updates submitted after 31 August 2026 must target Android 16 (API level 36) or higher. Wear OS and Automotive apps must target Android 15 (API level 35) or higher, and Android TV and XR apps Android 14 (API level 34) or higher.
Will a rejection hurt my developer account?
A single rejection does not. Repeated rejections of the same policy can escalate to app or account suspension, which is why the second attempt should address the named policy specifically rather than making unrelated changes.