Executive Summary (TL;DR)
- Google Play Requirement: Apps on personal developer accounts must complete a closed test with at least 12 active testers opted-in continuously for 14 days.
- Avoid Rejections: Maintain a buffer of 15 testers. If your active count drops below 12, Google's automated telemetry may pause or reset your 14-day timer.
- Guaranteed Solution: Instead of relying on uncommitted testers, join a 14-Day Testing Cohort at Testers Hub to secure 15 dedicated Android testers and guarantee production access.
One of the top reasons new Android applications are rejected during closed beta and production reviews is a Data Safety Section Mismatch. Google's static analysis engine scans your compiled APK/AAB bundle, detects the third-party SDKs and network calls embedded in your code, and cross-references them against what you declared in the Play Console Data Safety questionnaire.
If your app contains an analytics or ads SDK that collects an Advertising ID (AAID) or IP address, but you marked "My app does not collect user data," your submission will be rejected with an enforcement warning. This guide explains how to properly declare your data collection practices in 2026.
1. The Golden Rules of Google Play Data Safety
To avoid compliance violations, you must understand how Google defines data collection:
- You are responsible for your SDKs: You cannot blame a third-party library. If you integrate Google Mobile Ads (AdMob), Firebase Analytics, Sentry, or OneSignal, you are legally and policy-wise responsible for every byte of data those SDKs transmit.
- "Collected" vs "Shared":
- Collected: Data transmitted off the device to your server or a third party and stored for more than an ephemeral request.
- Shared: Data passed to a third-party entity (e.g. ad networks or data brokers).
- Ephemeral Processing Exception: If data is processed in memory on the server and immediately discarded without being written to disk or logged (such as a weather API querying an ephemeral latitude/longitude), it does not count as collected.
2. Data Safety Mapping for Common SDKs
Use this reference table to accurately map the data collected by popular mobile frameworks and toolchains:
| SDK / Library | Data Types Collected | Purpose / Declaration |
|---|---|---|
| Firebase Analytics / Crashlytics | Device IDs, Crash logs, Diagnostics, In-app purchase history | App Functionality, Analytics, Crash Reporting |
| Google AdMob | Device or other IDs (Advertising ID), Approximate Location, Interaction data | Advertising / Marketing, Fraud Prevention, Personalization |
| Supabase / Firebase Auth | Name, Email Address, User IDs, Authentication tokens | App Functionality, Account Management |
| RevenueCat / Google Play Billing | Purchase history, User IDs, Transaction logs | App Functionality, Fraud Prevention |
| OneSignal / Firebase Cloud Messaging (FCM) | Push Tokens, Device IDs, Interaction logs | App Functionality, Developer Communications |
3. Data Encryption in Transit & Account Deletion URL
Google Play now mandates two critical disclosures for all apps that handle user data:
A. Encryption in Transit
All data transmitted between your app and external servers must utilize standard cryptographic protocols (HTTPS / TLS 1.3). If your app makes insecure plain-text HTTP calls (except for local testing), your Data Safety declaration must declare that data is not encrypted in transit, which displays a security warning to store visitors.
B. Mandatory Account and Data Deletion URL
If your application allows users to create an account, Google Play requires:
- An in-app mechanism allowing users to delete their account and associated personal data.
- A public web URL (e.g.,
https://yourdomain.com/delete-account) where users can request data deletion without needing to reinstall the app.
Warning on Account Deletion Requirements
Simply providing an email address like "email us to delete your account" is no longer compliant for modern production review. You must provide a dedicated web landing page explaining what data is deleted, what data is retained for legal compliance (such as financial records), and an automated or submission-based deletion form.
4. Syncing Your Data Safety Section with Your Privacy Policy
Google employs automated natural language processing (NLP) to inspect the Privacy Policy link submitted in your store listing. Ensure that:
- Your Privacy Policy explicitly mentions your legal developer name and application name.
- All third-party services used (e.g., Google Play Services, AdMob, Supabase) are listed with links to their respective privacy terms.
- The categories of data declared in the Privacy Policy match the checkboxes checked in the Play Console Data Safety questionnaire.
5. Pre-Submission Data Safety Checklist
- Declared all Advertising IDs (AAID) if any ad network or attribution library is present.
- Declared Crash Logs & Performance diagnostics if Sentry, Crashlytics, or Bugsnag are included.
- Provided a working, public Privacy Policy URL accessible worldwide without login barriers.
- Provided a valid Account Deletion URL if authentication is supported.
- Ensured closed testing testers can review the declared privacy terms during onboarding.
Data Safety Ready? Now Clear Google's 14-Day Testing Hurdle
Even with a 100% compliant Data Safety declaration, Google will reject your production submission if you fail to recruit 12 opt-in testers for 14 continuous days. Fulfill your testing requirements safely with fellow Android developers on Testers Hub.
4. Complete 2026 Data Safety Taxonomy and Field Mapping
Google Play's Data Safety Section is not merely an informational questionnaire; it is a legally binding disclosure scrutinized by Google's automated static analysis scanners and human reviewers. Every data point collected by your own code, as well as data collected by third-party SDKs (such as Firebase, AdMob, AppsFlyer, or RevenueCat), must be declared with absolute precision.
| Data Category | Typical Third-Party SDK Trigger | Collection vs. Sharing Declaration | User Deletion Requirement |
|---|---|---|---|
| Device or Other IDs | Google AdMob, Firebase Installations, Adjust, OneSignal. | Collected & Shared (Advertising / Analytics). | Mandatory account deletion request link. |
| Approximate / Precise Location | Map SDKs, Geofencing, Location-based Ad Targeting. | Collected (App functionality). Must declare if optional. | Users must be able to delete historical location. |
| Personal Information (Email, Name) | Firebase Auth, Supabase Auth, User Profile registration. | Collected (Account management / App functionality). | Mandatory: In-app and web deletion URL. |
| Crash Logs & Diagnostics | Firebase Crashlytics, Sentry, Bugsnag. | Collected (Analytics / Diagnostics). Ephemeral data. | Not required if unlinked from user identity. |
| Financial Info (Purchase History) | Google Play Billing, RevenueCat, Qonversion. | Collected (Fraud prevention / Purchase fulfillment). | Subject to statutory transaction retention laws. |
5. The Mandatory Account Deletion URL Requirement
If your application allows users to create an account (via email/password, Google Sign-In, Apple ID, or phone number), Google Play strictly enforces two interrelated account deletion requirements under the Data Safety policy:
- In-App Deletion Mechanism: Users must be able to easily find and trigger an account deletion request within the app's settings menu (e.g., Settings > Account > Delete Account).
- Web-Based Deletion Request URL: You must provide a publicly accessible web link where users can request the deletion of their account and associated data without having to reinstall the mobile application. This URL must be declared under App content > Data safety.
6. The "Discrepancy Between Declared Data and APK Behavior" Rejection
One of the most frequent rejection notices indie developers receive during closed testing or production review reads:
"Issue found: Discrepancy between your Data safety form and app behavior. We detected that your app transmits Android Advertising ID (AAID), but you declared that no Device or Other IDs are collected or shared."
This occurs when developers assume that because they do not personally write code to save device IDs in their database, nothing is collected. In reality, bundling standard ad networks or analytics libraries automatically transmits device identifiers over HTTPS. Always check your third-party SDK documentation and declare all SDK-level telemetry in your Data Safety form.
7. Data Safety Section FAQs
Do offline apps that collect no data need a Data Safety declaration?
Yes. Every single application published on Google Play must complete the Data Safety questionnaire. If your app is truly offline and contains no third-party SDKs, you simply declare "No user data is collected or shared."
Does Google verify Data Safety declarations during the 14-day closed test?
Yes. Google Play's automated static and dynamic analyzers inspect network traffic and permission requests during closed testing releases, flagging data safety discrepancies before production rollout.
Third-Party SDK Auditing: Checking SDK Manifest Merge Output
Many developers fail Data Safety reviews because third-party dependencies silently inject undeclared permissions during the Gradle manifest merging phase. After compiling your release App Bundle, inspect the merged Android Manifest located at app/build/intermediates/merged_manifests/release/AndroidManifest.xml. Search for sensitive permissions such as ACCESS_COARSE_LOCATION, READ_PHONE_STATE, or POST_NOTIFICATIONS that you did not explicitly write in your primary manifest. Every single permission discovered in the merged manifest must be accounted for and declared accurately in your Google Play Console Data Safety form.
Data Safety Compliance for Open-Source Libraries
When incorporating open-source GitHub libraries into your Android codebase, always audit the library's network layer. Certain networking, caching, or logging utilities inadvertently transmit telemetry to author-hosted analytics servers. Auditing all outbound network calls using tools like Chucker or Charles Proxy ensures that no undeclared third-party endpoints receive user identifiers, keeping your Data Safety disclosures 100% accurate.
Data Encryption in Transit: Mandatory TLS 1.3 Protocol
Under Google Play's Data Safety declaration, checking the box for "Data is encrypted in transit" requires that all network communication between your mobile client and backend servers is secured using modern TLS 1.2 or TLS 1.3 cryptographic protocols with valid certificates. Transmitting user personal information, tokens, or telemetry over unencrypted HTTP endpoints will fail automated security scans and trigger policy enforcement warnings during closed testing.