Every Android developer must complete the Data Safety form in Google Play Console. It's not optional — apps with inaccurate declarations face blocked updates or removal from the store. And if you're still using a guide from 2022, you're working with outdated information.
Google's April 2025 policy update reclassified Android ID, clarified what "sharing" means, and tightened enforcement. In 2025 alone, Google prevented over 255,000 apps from gaining excessive data access and banned 80,000+ developer accounts.
This guide walks you through every section of the Data Safety form with the 2026 rules, shows you exactly what different analytics SDKs require you to declare, and gives you a fast-track path if you want to keep your declarations minimal.
⚡ What Changed in April 2025 (And Why Old Guides Are Wrong)
The April 10, 2025 policy update made three changes that invalidate most existing Data Safety guides:
1. Android ID Reclassification
Android ID is now explicitly classified as a device identifier that must be declared under "Device or other IDs". If your analytics SDK reads Settings.Secure.ANDROID_ID, you must disclose it — no exceptions.
2. Stricter "Sharing" Definition
Google clarified that data is "shared" whenever it's transferred to a third party — including your SDK provider if they use the data for their own purposes (ad targeting, cross-app profiling, benchmarking). If your analytics vendor uses aggregated data from your app to improve their own products, that counts as sharing.
3. Pre-Review Automated Checks
Play Console now runs automated checks against your APK/AAB before you can submit. If your binary accesses data types you didn't declare, you'll get flagged before human review. Play Policy Insights also appears directly in Android Studio, giving real-time feedback during development.
📋 Step-by-Step: Filling Out the Data Safety Form
Navigate to Play Console → Your App → App content → Data safety. You'll walk through five sections:
Step 1: Data Collection Overview
"Does your app collect or share any of the required user data types?"
If you use any analytics SDK (Firebase, Mixpanel, Amplitude, or Respectlytics), answer Yes. Even if you believe you collect minimal data, the threshold is low — transmitting anything off the device counts.
Step 2: Data Types
This is where your analytics SDK choice makes the biggest difference. You must check every data type your app (and its SDKs) collects. The categories that apply to analytics are:
- • Location: Approximate location (derived from IP address or coarse location APIs)
- • App activity: App interactions (screen views, button taps, events)
- • Device or other IDs: GAID (Google Advertising ID), Android ID, Instance IDs
- • App info and performance: Crash logs, diagnostics, performance data
-
•
Personal info: User IDs, email (if your SDK collects
identify()calls)
Step 3: Data Usage and Handling
For each data type you checked, you must answer:
- • Is this data shared? Transferred to third parties for their own purposes?
- • Is this data collected? Transmitted off the device?
- • Is this data processed ephemerally? Only used in memory without being stored?
Step 4: Security Practices
Google asks whether your collected data is encrypted in transit and whether users can request deletion. For analytics:
- ✓ Encrypted in transit: Should be Yes — any reputable analytics SDK uses HTTPS/TLS.
- ✓ User deletion: Can users request their data be deleted? If you use persistent user IDs, you need a mechanism. If you use session-based analytics with no persistent identifiers, there is no personal data to delete.
Step 5: Privacy Policy
You must provide a valid privacy policy URL. Your policy should accurately describe the data your analytics collect. If your privacy policy says "we don't collect personal data" but your SDK sends device IDs to a third-party server — that's a mismatch Google will flag.
⚖️ What Your Analytics SDK Requires You to Declare
Your Data Safety form is only as clean as your most data-hungry SDK. Here's exactly what the most common analytics tools require you to check:
| Declaration | Firebase | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Device or other IDs | Yes (GAID, Instance ID) | Yes (Device ID) | Yes (Device ID) | No |
| Location | Approximate | Approximate (IP) | Approximate (IP) | Country only (IP discarded) |
| Personal info (User IDs) | Yes | Yes | Yes | No |
| App activity | Yes (custom props) | Yes (custom props) | Yes (custom props) | Event name only |
| Diagnostics | Yes | Optional | Optional | No |
| Data shared with 3rd parties | Depends | Depends | Depends | No |
Why Does Respectlytics Have Fewer Declarations?
Respectlytics stores exactly 5 fields: event_name, session_id, timestamp, platform, and country. No device identifiers, no GAID, no user IDs, no custom properties. IP addresses are processed transiently for country lookup and immediately discarded — never stored. The SDK writes zero bytes to the device for analytics purposes.
🚀 The Quick Path: Minimal-Analytics Apps
If you use Respectlytics as your only analytics SDK, here's exactly what to check on the Data Safety form:
- 1. "Does your app collect or share data?" → Yes
- 2. Data types: Check "Location → Approximate location" and "App activity → App interactions". That's it.
- 3. For both types: Mark as "Collected" (not shared). Purpose: "Analytics".
- 4. Is this data processed ephemerally? → For location: Yes (IP is processed and discarded). For app interactions: No (event names are stored).
- 5. Security: Encrypted in transit → Yes. Data deletion → Not applicable (no personal data stored).
🔍 "Collected" vs. "Shared" — Getting This Right
This distinction trips up more developers than anything else on the form:
Collected
Data transmitted off the device to you or your service provider. If your analytics SDK sends event data to its server (yours or theirs), that data is collected.
Shared
Data transferred to a third party for their purposes. If your analytics vendor uses data from your app for cross-app benchmarking, ad targeting, or their own product improvements — that's sharing.
Why This Matters for Your SDK Choice
With a self-hostable, open-source analytics platform, your analytics data goes to your server (or our managed SaaS where data is never shared with anyone). No third-party data sharing to declare. With closed-source SDKs from companies whose business model includes data aggregation, the "sharing" question gets complicated.
🛡️ Enforcement Is Real
Google's 2025 Annual Safety Report showed this is no longer a "best effort" form:
- ⚠ 255,000+ apps prevented from gaining excessive access to sensitive data
- ⚠ 80,000+ developer accounts banned for policy violations
- ⚠ Expanded developer verification requirements for 2026
- ⚠ Automated pre-review checks that scan your binary before human review
The era of "just check No and hope for the best" is over. Declare accurately, or simplify what you need to declare by using tools that collect less.
🍎 Also on iOS? Read the Companion Guide
If you ship on both platforms, you need to get both privacy declarations right. Our Apple Privacy Label guide covers the iOS equivalent step-by-step:
Step-by-step walkthrough of App Store Connect App Privacy, with the same SDK comparison approach.
📚 Related Reading
- → Mobile Analytics Without Collecting Personal Data
- → How to Track App Conversions Without Device IDs
- → Why We Killed Custom Event Properties
Legal Disclaimer: This information is provided for educational purposes and does not constitute legal advice. Google Play policies change over time. Consult your legal team to determine the requirements that apply to your specific situation.