Google Play's Data Safety section is one of the most confusing parts of publishing an Android app. It looks like a simple questionnaire, but the questions are vague, the categories overlap, and getting it wrong can delay your app review or | worse | result in enforcement action after your app is live. Most developers fill it out by guessing, and most of those guesses are wrong in ways that create compliance risk they don't even know about.
This guide walks through the Data Safety section in plain English, explains what each question actually means, and shows you how to fill it out correctly the first time.
What is the Data Safety section?
Google requires every app on the Play Store to declare what user data it collects, how that data is used, and whether it's shared with third parties. This information is displayed publicly on your app's listing page, and Google audits it against your app's actual behavior. If your declaration doesn't match reality | if you claim you don't collect location data but your app requests location permissions - you're in violation.
The Data Safety section was introduced in 2022 as Google's answer to growing privacy regulation (GDPR, CCPA) and consumer demand for transparency. It's not optional, and skipping it or filling it out carelessly is one of the most common reasons apps get flagged during review.
The core questions, decoded
Does your app collect or share any user data?
If your app requests any permission that provides access to user data - location, contacts, camera, microphone, storage, device identifiers, crash logs, analytics - the answer is yes. Even if you don't "store" the data on a server, accessing it locally on the device counts as collection in Google's framework. The only apps that can truthfully answer "no" are apps that request zero permissions and include zero third-party SDKs (which is rare).
Data types: what categories apply to your app?
Google breaks data into categories: Location, Personal info, Financial info, Health and fitness, Messages, Photos and videos, Audio files, Files and docs, Calendar, Contacts, App activity, Web browsing, App info and performance, and Device or other IDs. For each category you declare, you'll need to specify whether it's collected (transmitted off-device), shared (transferred to third parties), and the purpose (app functionality, analytics, advertising, etc.).
The tricky part is that many common third-party SDKs collect data you might not be aware of. Firebase Analytics collects device identifiers and app usage data. AdMob collects advertising IDs and potentially location. Even crash reporting libraries like Crashlytics collect device info and app performance data. You need to account for what your dependencies collect, not just what your own code collects.
Is data encrypted in transit?
If you're using HTTPS for all network requests (which you should be), the answer is yes. But verify that every endpoint - including third-party SDKs - uses TLS. One unencrypted HTTP call in a dependency and your declaration is inaccurate.
Can users request data deletion?
If your app collects data that's stored on a server (including through third-party analytics), you need to either provide a data deletion mechanism or declare that deletion isn't available. GDPR requires deletion for EU users regardless. If you're unsure, provide a contact email and a process - it's better to offer deletion and rarely use it than to not offer it and face a compliance complaint.
Common mistakes that get apps flagged
Declaring "no data collected" when using Firebase or AdMob. These SDKs collect data by design. If they're in your app, you must declare their data practices even if you didn't write the collection code yourself.
Forgetting about crash reporting. Crashlytics, Sentry, Bugsnag - all of these collect device info and app performance data. This falls under "App info and performance" in Google's taxonomy.
Not matching permissions to declarations. If your app's manifest includes ACCESS_FINE_LOCATION but your Data Safety section doesn't mention location collection, Google will flag the inconsistency. Your declared data practices must align with your app's actual permissions.
Ignoring "shared" vs "collected." Sending data to an analytics provider counts as "sharing" in Google's framework, even if the data isn't sold. The distinction between collection and sharing is about where the data goes, not what you do with the money.
How IOn Emit simplifies Data Safety
IOn Emit tackles the Data Safety section from two angles. First, the AAB analyzer automatically extracts permissions from your app bundle and maps them to Google's Data Safety categories - so you can see exactly which data types you need to declare based on what your app actually requests, not what you think it requests. Second, the Pre-Flight Wizard walks you through the complete Data Safety questionnaire with AI-assisted explanations for each question, so you understand what you're declaring and why.
The result is a Data Safety section that accurately reflects your app's behavior, matches your permission set, and won't trigger inconsistency flags during review. It's available in IOn Emit's free tier - along with the 8-step new app wizard that handles every other section of the Play Console setup process, from content ratings to privacy policies.