On this page (7 sections)
1. Technical requirements that block the upload itself
These are checked by Play Console before any human sees the app. Failing one of them means the release cannot be created at all.
- Target API level 36 — new apps and updates must target Android 16 (Wear OS and Automotive: 35; TV and XR: 34). What breaks when you raise it.
- Play Billing Library 8+ if the app sells anything digital — including when the version is decided by Unity IAP,
in_app_purchase,react-native-iapor RevenueCat. Upgrade notes. - 16 KB page size support for every native library in the bundle, yours and your SDKs'. How to verify it.
- Signing — Play App Signing enabled, upload key stored somewhere two people can reach, fingerprints registered with every API provider (Google Sign-In, Maps, Firebase). If the key is already lost.
- Package name registered under Android developer verification, and the developer account verified. What that involves.
- Version code higher than anything ever uploaded to any track — including builds you deleted.
- 64-bit and app bundle — an AAB with the required ABIs; APK-only distribution is long gone.
You can read most of these out of a build file: paste it into the Android update readiness checker.
2. Declarations that must match the app
Play Console's App content section is where most first-submission trouble starts, because the answers are commitments. Reviewers compare them with the build, the listing and the privacy policy.
| Declaration | What it must match | Usual first-submission mistake |
|---|---|---|
| Privacy policy | A reachable URL describing the data the app and its SDKs actually handle | A template policy that never mentions the analytics or ads SDK in the build |
| Data safety | Real collection, sharing, purposes, encryption in transit and deletion — including SDK behaviour | Declaring “no data collected” with an analytics or crash SDK compiled in |
| App access | Working credentials and steps for every gated feature, including OTP paths | A demo account that expired, or a login that needs an SMS code the reviewer cannot receive |
| Ads | Whether the app shows ads at all, matching the SDKs present | Forgetting that a mediation SDK counts |
| Content rating questionnaire | The app’s actual content and features | Answering for the current build and never re-taking it when features change |
| Target audience and content | The audience you design and market for | Selecting a child audience without the Families requirements in place |
| Government / financial / health / news declarations | The category you are really in | Assuming a category declaration is optional |
| Advertising ID | Whether the app uses the AD_ID permission | Leaving AD_ID in the manifest from an old SDK |
Details and the consequences of a wrong answer: app content declarations and Data safety.
3. Permissions the reviewer will question
Google only allows restricted permissions when they are necessary for a core feature promoted in your listing, and several of them need a Permissions Declaration Form. Check the merged manifest, not just your own: SDKs add permissions.
- Location (especially background), SMS and Call Log, all files access, package visibility (
QUERY_ALL_PACKAGES), install packages, accessibility service, exact alarms, full-screen intents, body sensors, Health Connect. - Each one has a scoped alternative Google prefers — system pickers for media, the contact picker for contacts,
<queries>for package visibility. Using the alternative is usually faster than defending the broad permission. - Foreground services need a declared type and, for apps targeting Android 14+, a Play Console declaration with a demonstration video.
Full breakdown: sensitive permissions and declarations.
4. Accounts, testing and production access
- New personal developer accounts must run a closed test before applying for production access, and the application is judged on how the test went. Plan it into the timeline rather than discovering it at submission: production access.
- Account deletion — if users can create an account in the app, there must be an in-app deletion path and a web deletion URL, both declared.
- Reviewer access — test the app access instructions on a device that has never seen the app, with a clean Google account.
5. Store listing that matches the build
- Title, short and full description describe what the app does now — no “coming soon” features, no competitor names, no keyword stuffing.
- Screenshots and feature graphic come from the actual app, not from mock-ups or a different platform.
- No claims the app cannot support (medical, financial, earnings), and no unverifiable badges.
- Contact email is monitored — enforcement notices go there.
6. Stability and behaviour
- Install the release build on a clean device and run every promoted feature, offline and on a slow connection.
- Check the pre-launch report after the first upload to an internal or closed track; crashes there are a rejection waiting to happen.
- No cleartext traffic, no debug logging of user data, no dead code paths pointing at staging servers.
- Deep links and app links resolve; nothing in the app requires an APK sideload.
7. Release configuration
- Upload to an internal track first, then closed, then production — the same bundle each time.
- Staged rollout for the first production release, with a plan for halting it.
- Release notes in every listed language; countries and device exclusions reviewed.
- Mapping file (deobfuscation) and native debug symbols uploaded so crashes are readable.
The pre-submission review is the same free review
You do not have to wait for a rejection to use it. Send what the app does, what it collects, what it charges for and which permissions it needs, and our technical team tells you which declarations will be questioned and which technical requirements the build does not yet meet. If implementation is needed, it is quoted separately — the review itself is free.
Submitting to both stores? The Apple side has a different set of blockers: App Store submission checklist.