Most Play review rejections are not mysterious. They are the predictable result of skipping a check Console already offered for free before submission — the pre-launch report, the Data safety form, the target API rule. This is the ten-item pass to run before you press publish, written against what Play's own pages publish.
What you are solving today: verify the release artifact (target API level, signing, version codes, debuggable flag), verify the compliance paperwork (Data safety, content rating, privacy policy, permissions), verify the store listing assets, and actually read the pre-launch report Play generates automatically for every bundle you upload to a test track. Fix what it flags before users see the build.
What the pre-launch report actually tests
Play's pre-launch reports page states the mechanics plainly: every time you publish an app bundle or APK to a test track, you automatically receive a pre-launch report. Google runs your app on a range of physical Android devices in the cloud and reports on stability, performance, accessibility, and display.
Two published best practices decide whether the report is worth anything to you:
- Publish to the default closed or open testing track to be eligible for a pre-launch report.
- Provide test account credentials if your app has a sign-in screen, so the crawl reaches the flows behind it. Without credentials the report stops at your login wall and tells you almost nothing about the app.
Google also publishes a dedicated help article on interpreting the results, and the reports page links a short training course. Read the interpretation article before you write a red flag off as a false positive — and read it before you panic about one either.
The 10 checks
1. Target API level
New apps and app updates must target the API level Play currently requires, and failing the requirement prevents submission in Console rather than triggering a warning. Play's target API level help states the current thresholds with dates; the Android Developers requirement page carries the same rule for developers working from the build side. Confirm the target in your build configuration, not in a note from last quarter.
2. Signing and Play App Signing
Publish an artifact signed with your upload key, with Play App Signing enrolled. Confirm the uploaded bundle is the intended one — the artifact you tested, not a stale build from a parallel branch.
3. Version code and version name
The version code has to be higher than the one already live, and it has to unambiguously identify this release. A version code reused across tracks is a classic way to ship the wrong build to the wrong audience.
4. Not debuggable, shrinking on
Your release build must not be debuggable. Turn on code shrinking and resource shrinking so the artifact that reaches Play is the artifact you meant to ship, not a fatter build that leaked a debug flag.
5. Data safety matches your actual SDKs
The Data safety form is the most commonly incomplete section for new developers, and the mismatch is almost always an SDK. Every third-party library that collects or shares data — analytics, crash reporting, push, ads, auth — has to be reflected in the answers. Walk your dependency list, not your memory of it.
6. Privacy policy URL is live
A privacy policy URL is required and it has to resolve. A dead link, or a template policy that contradicts your Data safety answers, is a rejection waiting to happen — and a policy that promises less than your SDKs actually do is worse than a missing one.
7. Content rating questionnaire
Complete the rating questionnaire and receive the rating. Answer accurately: misdeclaring content is a policy problem, not a paperwork problem.
8. Store listing assets
Icon, feature graphic, screenshots, descriptions, contact details. Play publishes exact asset specifications — check the current numbers rather than reusing whatever an older project used. Every claim in the listing has to match the build that is actually shipping. Retired screenshots and promises for features that were cut are review and trust risks.
9. Permissions are minimal and declared
Request only what the app uses, and complete any declaration a sensitive permission requires. A permission sitting in the merged manifest that no feature needs is both a privacy finding and a policy finding.
10. Test track and staged rollout
Run the build through a test track first, install it on a real device, then start production at a small percentage and watch Android Vitals before going to 100%. The pre-launch report gives you a snapshot before users see the app; staged rollout limits the blast radius if the snapshot missed something.
What the report flags, in plain terms
The report is not a score. It is a list of findings across the categories Google publishes — stability, performance, accessibility, and display. Treat it as triage:
- Crashes and ANRs are not negotiable. A crash the crawl found on a mid-range device is a crash your users will find.
- Security findings need a decision, not silence. Investigate, fix, or document why the flagged behavior is intended.
- Accessibility findings are cheap before launch and expensive after. Content descriptions and contrast are the usual hits.
- Display findings — clipped layouts, unreadable text on small screens — are what your first one-star reviews are made of.
If the report stops at a sign-in screen, that is a finding about your test setup, not about your app. Re-upload with credentials.
The one-line version
Before you publish: confirm the artifact (target API level, upload key plus Play App Signing, a fresh version code, not debuggable), finish the paperwork (Data safety that matches every SDK, a live privacy policy, a completed content rating, minimal declared permissions), complete the listing assets, and actually read the pre-launch report Play generated for your test-track upload — with test credentials supplied so the crawl could reach the real app.