Avoid Google Play Rejection: Complete Checklist (2026)
Google Play rejects apps for a predictable set of reasons. Here is the complete pre-submission checklist covering every category of rejection — technical, privacy, content, metadata, and payment compliance.
Run this first: Before working through this checklist, upload your APK or AAB to the AppTester Health Check. It automatically detects the most common technical rejection causes in 30 seconds. Fix those, then work through the rest of this checklist.
Build and technical
targetSdkVersion is API 35 or higher
Google Play enforces a minimum target SDK level. Submissions below the threshold are rejected automatically. Check app/build.gradle.
App is signed with your release keystore
Debug-signed builds are rejected. Verify with: keytool -list -printcert -jarfile your-app.apk — should show your release certificate.
No crash on launch
Test on at least 3 real devices including older Android hardware. A crash on launch is an instant rejection.
App is not a debug build
Run: aapt dump badging your-app.apk | grep debuggable — should return nothing for a release build.
64-bit native code included (if applicable)
Apps with native code must include 64-bit libraries. 32-bit only is no longer accepted for new apps.
Privacy and Data Safety
Data Safety section is complete
In Play Console, fill in every field in the Data Safety form. Every permission your app requests must be declared. Incomplete forms are flagged.
Third-party SDKs declared in Data Safety
SDKs like Firebase, AdMob, Meta, and Adjust collect data. Their data collection must be reflected in your Data Safety declaration even if you did not write the code.
Privacy policy link is valid and accessible
Add a working privacy policy URL in Play Console under Store Listing. Test the link. A 404 or placeholder page will cause rejection.
Privacy policy covers all data collected
The policy must specifically mention each type of data your app collects. A generic template that does not mention your permissions will not pass review.
Permissions match declared purpose
Every permission in AndroidManifest.xml must be justified by a feature the user can see. Remove any unused or over-broad permissions.
Content policy
Content rating matches actual content
Complete the IARC content rating questionnaire accurately. If your app contains violence, adult themes, or user-generated content, the rating must reflect this.
User-generated content moderation is in place
Apps that allow users to post content must have moderation and reporting mechanisms. No moderation is a policy violation.
No policy-prohibited content
Prohibited categories include child endangerment, harassment, spam, and deceptive behaviour. Review the full Developer Program Policies.
Intellectual property is clear
App name, icon, and screenshots must not infringe on trademarks or copyrights. Search for your app name and icon concept before submission.
Metadata and store listing
App title is under 50 characters
Google Play enforces a 50-character limit on app names. Longer names are truncated or rejected.
No keyword stuffing in title or short description
Repetitive keywords in the title or 80-character short description is a policy violation. Write for users, not algorithms.
Screenshots show the actual current app UI
Misleading screenshots that show features not present in the build, or UI that does not match the current version, cause rejection.
Feature graphic is present
The 1024x500 feature graphic is required for store front placement. A missing feature graphic limits your listing's visibility.
All listed features are functional
Test every feature mentioned in your description. If something is broken, remove it from the description or fix it.
Payments and subscriptions
In-app purchases work in testing
Create a test account and verify every IAP flow through Google Play Billing. Failed purchases during review cause rejection.
Subscription terms are clearly disclosed
Price, billing period, and cancellation instructions must be visible before the user subscribes. Bury this and it will fail review.
No external payment links for digital goods
Google Play Billing must be used for all in-app purchases of digital content. External payment links for digital goods are a policy violation.
Accounts and login
Account deletion option exists
Apps with account creation must allow account deletion from within the app. Add this to account settings.
Guest access is available (or justified absence)
Apps that force account creation before showing any content risk rejection. Allow some exploration before requiring sign-up.
Test credentials provided (if login-gated)
In the App Review Notes, provide a working test account. If reviewers cannot access features, they cannot approve them.
After the technical checklist: human testing
Google Play reviewers test apps manually. Automated checks and this checklist catch technical and policy issues, but they cannot catch what a real person notices on a real device: confusing UX, flows that break in unexpected ways, content that feels inconsistent with the age rating, or features that do not quite do what the description says. Human testing before submission closes that gap.
Catch rejections before Google Play does
Upload your APK or AAB. The Health Check scans for target SDK, signing, debug build, and 6 other common rejection causes in under 30 seconds.