Google Play Pre-Launch Review: A Compliance and Policy Guide
Google Play uses a layered review process: automated policy scanning at submission, pre-launch report testing on real devices, and human policy review. Each layer catches different categories of issues. This guide covers the preparation steps that reduce policy violation risk across all three layers, with particular focus on the Data Safety form and permissions declarations that generate the highest violation volume.
The three layers of Google Play review
Understanding which review layer catches which category of issue allows QA teams to allocate pre-submission effort appropriately.
- Layer 1 — Automated policy scanning: runs at submission time, checks for prohibited APIs, sensitive permission requests, and comparison of Data Safety form against detected SDK behaviour. Results typically available within hours.
- Layer 2 — Pre-launch report: Google crawls the app on real devices in its labs, exercising features automatically. Captures crashes, accessibility issues, and UI performance data. Available in Play Console as a Pre-Launch Report 1–2 days after submission.
- Layer 3 — Human policy review: triggered by automated signals, new developer accounts, or policy-sensitive app categories (health, finance, child-directed). Timeline varies from 24 hours to several days.
Data Safety form: the highest-risk area
The Data Safety section in Play Console is the most common source of policy violations in 2026. Google compares declared data types against detected SDK behaviour in the APK/AAB. A mismatch between declaration and detected behaviour triggers a policy violation notice.
- Every third-party SDK that collects data must be reflected in the Data Safety form — not just the app's own code
- Common violation: adding Firebase Analytics, Facebook SDK, or an attribution SDK without updating the Data Safety form
- Test step: after any SDK integration, compare the new SDK's data collection documentation against the current Data Safety form; update the form before submission
- Key distinction: 'Shared with third parties' must be declared for any data sent to an SDK that sends data off-device, even if the SDK vendor is a service provider
Permissions: use case declarations and minimisation
Sensitive permissions require a compliant use case declaration. Permission requests that do not satisfy the policy use case requirements result in app removal, not just rejection.
- CALL_LOG and SMS permissions: restricted to apps whose primary function is call or message management. Supplementary use (e.g., to pre-fill an OTP field) does not qualify.
- LOCATION (background): requires that background location is essential to the app's core function. Cannot be requested at install time; must use the graduated permission request flow (foreground first, then background).
- CONTACTS: valid use cases include address book, contacts management, and communication apps. Requires disclosure of how contact data is used.
- Best practice: request the minimum permission scope required. Use photo picker API instead of READ_MEDIA_IMAGES. Use One-Time Permission for location where possible.
Target API level and technical compliance
Google Play enforces minimum target API levels for new submissions and updates.
- New apps and updates must target Android 14 (SDK 34) or higher as of August 2024
- New submissions must include a 64-bit binary; 32-bit only apps are blocked from new submissions
- Apps using the Camera or Microphone must display the green indicator dot (Android 12+); apps that attempt to suppress it will be flagged
- Test step: run 'gradlew lint' and review all deprecated API warnings; verify targetSdkVersion is SDK 34+ in build.gradle
Frequently asked questions
Most major SDKs publish data collection documentation: Firebase/Google's data disclosure is at firebase.google.com/docs/analytics/data-disclosure; Meta's is at developers.facebook.com/docs/privacy. For less well-documented SDKs, static analysis tools (like MobSF or custom apktool analysis) can identify off-device data transmission. Alternatively, MAT's compliance audit service analyses your APK's network traffic against your Data Safety declarations.
Google Play policy violations result in an app being removed from the store within 30 days if not resolved, or immediately for severe violations. The violation notice includes the specific policy section, the detected issue, and a remediation path. You have the right to appeal the decision through Play Console if you believe the violation finding is incorrect. Most violations are resolvable by updating the Data Safety form or removing/replacing non-compliant SDKs.
Need more detail?
Our team can provide vertical-specific data, custom analysis, or a live walkthrough of any resource on this page.