Google Play's Data safety section is the Android counterpart to Apple's privacy label, and it carries the same trap: it is self-reported, so it feels like a form you can fill in loosely, but Google holds you to its accuracy. Every app needs one, it has to match what your app actually does with user data, and the most common reason it ends up wrong is a third-party SDK collecting data you did not account for. Get it wrong and Google can require a fix or take enforcement action. Here is what the form must declare and how to make it accurate.
Short answer
Every app on Google Play must complete a clear and accurate Data safety section declaring what user data it collects, how it is used, and whether it is shared with third parties. Per Google's Data safety guidance, the developer is solely responsible for the accuracy of the declaration and for keeping it current, and Google can take enforcement action, including requiring a fix or removing the app, when it finds a discrepancy between the declaration and the app's behavior. The form must match your actual data practices, including what your SDKs collect, so the reliable way to fill it accurately is to establish your real data flows first, then declare from them.
What you should know
- Every app needs one: the Data safety section is mandatory on Google Play.
- You own the accuracy: the developer is responsible for the declaration.
- It must match behavior: Google enforces on declared-versus-actual discrepancies.
- SDKs are the usual blind spot: a library collects data you did not account for.
- Keep it current: update it as your data practices change.
What is the Data safety section?
It is the privacy disclosure Google Play shows users before they install, generated from a form you complete in Play Console. It tells users what types of data your app collects, the purposes that data serves, and whether any of it is shared with third parties, where shared generally means transferred to another company, with some exceptions like sharing with a service provider or after explicit user consent. It is the Android equivalent of Apple's App Privacy label, and like that label it is a declaration you are accountable for. Google's app review is not designed to verify your declaration's accuracy for you, so the responsibility to make it complete and truthful rests entirely with you, the developer.
What must the Data safety form declare?
Your collection, use, and sharing of user data, accurately. The table summarizes the parts.
| Element | What you declare |
|---|---|
| Data collected | The types of user data your app collects |
| Purpose | Why each data type is collected and used |
| Data shared | Which data is transferred to third parties |
| Security practices | Whether data is encrypted in transit, and deletion options |
| SDK and library data | Data collected by third-party code in your app |
The element developers most often get wrong is the last one: a third-party SDK, for ads, analytics, or crash reporting, collects and may share data on your behalf, and that counts as your app's data practice for the form. So an otherwise honest declaration becomes inaccurate when it omits what a library does, which is exactly the kind of gap Google's enforcement targets.
How do you fill it accurately?
Establish the real data flows, then declare from them, SDKs included. Start by mapping what your own code collects and sends, then go through every third-party SDK and account for the data each one collects and shares, since those count as your app's practices. Map each data type to its purpose, declare any third-party sharing honestly, and state your security practices, like encryption in transit, truthfully. Keep the declaration aligned with your privacy policy so the two agree, and revisit it whenever you add a feature or a library, because data collection changes as the app grows. The objective is a Data safety section that describes the app as it actually behaves, which is both the compliant position and the one that survives Google's enforcement and outside scrutiny.
What to watch out for
The first trap is treating the form as a low-stakes self-report because Google's review does not verify it, when Google acts on discrepancies it discovers and can require a fix or remove the app. The second is omitting SDK data collection, which silently makes an honest declaration inaccurate. The third is letting the form go stale as you add libraries. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces the SDKs and network endpoints that collect and send data, giving you the ground truth your Data safety section should reflect. The declaration itself you complete in Play Console, but the scan tells you what to declare.
What to take away
- Every Google Play app must complete an accurate Data safety section covering data collected, used, and shared, and the developer owns its accuracy.
- Google enforces on discrepancies between the declaration and the app's behavior, including requiring a fix or removing the app.
- The common error is omitting what third-party SDKs collect and share, which counts as your app's data practice.
- Establish your real data flows, declare from them, keep the form current, and use a pre-submission scan such as PTKD.com to find what your SDKs actually collect.
