Launching on Google Play: the checklist
Play blocks releases with forms and automated checks, not with a reviewer's opinion. That single fact changes how you prepare.
On Apple, a person uses your app, so review notes and a working demo account carry real weight. On Play, they mostly do not. The Console's own release-blocking list is the authoritative source, and "we explained it in the notes" is not a mechanism.
The gates, in the order they bite:
1. Closed testing, for new personal developer accounts. A required number of testers for a required period before production access. A hard gate with a clock, so it starts weeks before a launch date, not alongside it. Detail.
2. Target API level. A published floor for new apps and a separate one for updates. Below the update floor you cannot ship a fix. Detail.
3. Data safety. A declaration compared against what your app and its SDKs actually do. Filled in from memory is the most common avoidable failure on this list. Detail.
4. Sensitive permissions. SMS, Call Log, All files access, background location. Declaration, reviewed, slow. Detail.
5. Foreground service types. Declared and matching actual use. Detail.
6. Account deletion. In-app and a public web URL. Detail.
Start these first, because they have clocks
Closed testing. Recruit real testers early. The requirement is about sustained participation over a period, so a list assembled the week before does not satisfy it.
Sensitive permission declarations. These reviews are slower than a release review and some require a demonstration video.
Everything else can be done in an afternoon. These two cannot, and they are the two that turn a launch date into a missed launch date.
The Data safety form, done properly
Not from memory. From the dependency tree.
# collectors actually present, including transitive ones
grep -riE 'firebase|crashlytics|analytics|amplitude|mixpanel|segment|sentry|bugsnag|appsflyer|adjust|branch|facebook|onesignal|posthog|intercom' package.json | head -30
# what the merged manifest requests, which is what Play sees
grep -o 'android:name="android.permission.[A-Z_]*"' \
android/app/build/intermediates/merged_manifests/release/AndroidManifest.xml 2>/dev/null | sort -uFor each collector, read its own documentation on what it collects by default, then declare that. An SDK collecting on your behalf is your declaration to make.
And keep it consistent with your Apple App Privacy label. Declaring no collection on one store and collection on the other, for one codebase, is a discrepancy anyone can see from outside. App privacy labels.
The manifest audit
Android manifest merging folds every dependency's entries into yours, and the merged file is what Play evaluates. Read it, not your source manifest, and for each sensitive permission decide: declare it or remove it.
In Expo, removals belong in a config plugin, not in the generated android/, which prebuild regenerates. The permissions declaration. · The EAS submission checklist.
The listing
Screenshots, to Play's specs, showing the app. A feature graphic, which is required and easy to forget. A short and full description, with no references to other platforms and no unsubstantiated claims — the same discipline as the App Store listing, for the same reasons. Writing store copy that does not get rejected.
A privacy policy URL that is live. Checked, and trivially checkable.
Content rating questionnaire, answered honestly, particularly for anything with unpredictable output. Submitting an AI app.
Before you press publish
# the Console's own list is authoritative; read it for THIS release
# then confirm the basics locally:
# target and compile levels
grep -n 'targetSdkVersion\|compileSdkVersion' android/build.gradle app.json app.config.js 2>/dev/null
# deletion URL live today
curl -s -o /dev/null -w '%{http_code}\n' https://yoursite.example/delete-account
# other-platform references in the listing
grep -rniE 'app store|ios|iphone|testflight' fastlane/metadata store 2>/dev/null | headThat last one is the mirror image of the Apple problem, and cross-platform teams write one set of copy and ship it to both stores.
Then the ordinary release discipline
Staged rollout from the first release, watched rather than started and forgotten. Shipping your first update.
And read the Console's blocking list rather than reasoning from an email. On Play, the Console is the source of truth about what is stopping this specific version. Google Play rejections. · After a rejection.
shipcheck reads the merged manifest, the dependency tree and the app config together and reports what your Data safety declaration and permissions need to say, citing the Play policy for each. What it checks. · The first-submission checklist.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
What blocks a Google Play release?
Mostly forms and automated checks rather than a reviewer's judgement: the target API level floor, the Data safety declaration, sensitive permissions declarations, foreground service types, account deletion, and for new personal developer accounts the closed testing requirement.
How is Play different from App Review?
Play decides most things through declarations you make in Console and checks run against the bundle, so the Console's release-blocking list is the authoritative source. Apple decides more through a person using your app, which is why review notes matter there and matter much less here.
What is the closed testing requirement?
New personal developer accounts must run a closed test with a required number of testers for a required period before production access is granted. It is a hard gate with a clock, so it has to be started well before a launch date.
How long does Play review take?
Google does not guarantee a time, and first releases from new accounts commonly take longer than updates. Plan around the gates rather than around a number.
Do I need separate screenshots for Play?
Yes, with their own requirements, and the same rules about honesty apply: they must show the app, and they must not reference other platforms. A feature graphic is also required and is easy to forget.
What is the most common avoidable failure?
A Data safety declaration that does not match what the app and its SDKs actually do. It is filled in from memory, the dependency tree says something else, and automated checks compare the two.
shipcheck. “Launching on Google Play: the checklist.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/guides/google-play-launch-checklist/