A developer adds Firebase Analytics, ships a release, and then stares at the Google Play Data Safety form wondering which of the dozens of data types to tick. They open AndroidManifest.xml and start selecting anything that looks related. That produces a declaration matching the manifest rather than the app — precisely the mismatch that gets a release blocked.
The form is short. The work behind it is not, because the answer depends on what your code, libraries and backend actually transmit.
This guide covers which apps must complete it, how Google defines collection, why permissions are a poor proxy for the answers, how to audit SDKs, and how to work through the form without guessing.
What Is the Google Play Data Safety Section?
It is a summary on your app's store listing describing what data the app collects and shares, and how it handles that data. You fill it in through a form in Play Console; Google shows the result to users considering the app.
Two characteristics shape how you fill it in:
- It is global. Google documents one form per package name, agnostic to usage, app version, region and user age. The section describes the sum of your collection and sharing across every version currently distributed on Google Play, anywhere in the world. A practice in any live version belongs on the form.
- It is your responsibility. Google states that only you possess the information required to complete it, and that it cannot make determinations on your behalf. Misrepresentation that violates policy leads to enforcement, up to blocked updates or removal from Play.
In one sentence: the Data Safety section is a public, per-package summary of what your app transmits off the device, and you are accountable for its accuracy.
The section is disclosure, not consent. It adds no new disclosure or consent step to the install — the in-app disclosure and consent requirements in the User Data policy still apply.
Which Apps Need to Complete the Data Safety Form?
Google documents exactly one testing-track exemption: apps that are active on internal testing tracks are exempt from inclusion in the Data safety section. Every other track requires it.
| Track | Form required? | What that means in practice |
|---|---|---|
| Internal testing only | Exempt | Google documents that apps active on internal testing tracks are exempt from inclusion in the Data safety section |
| Closed testing | Required | Testers install from a real listing, so the section is visible. Prepare it before the first closed release |
| Open testing | Required | Anyone can join, so treat the declaration as public-facing |
| Production | Required | Must stay accurate for as long as the app is distributed |
Internal testing and closed testing are not interchangeable here. The exemption is specific to internal testing, and an app that moves to closed testing stops qualifying immediately.
An app that collects nothing still has to deal with the form. The User Data policy expects a privacy policy in both the store listing and inside the app — so "we collect nothing" shortens the answers, it does not skip the work.
What Information Does Google Ask Developers to Disclose?
The form works through data categories — location, personal info, financial info, health and fitness, messages, photos and videos, files and docs, contacts, calendar, app activity, web browsing, app info and performance, device or other identifiers — and asks, for each applicable type, whether it is collected, whether it is shared, and why.
For each declared type, expect to state the purpose, whether collection is required or optional, and whether it is processed ephemerally. Google's guidance on required versus optional is specific: if a data type is required for any of your users, do not call it optional.
Two details that are easy to get wrong:
- Nested collection counts. If you purposefully collect one data type while collecting another, disclose both. Google's example is collecting photos and using them to infer characteristics such as ethnicity, which means ethnicity is also disclosed.
- Location has a numeric boundary. Approximate location covers areas of 3 square kilometres or more; precise covers anything smaller. Coarse and fine permission names map loosely onto that split.
IP addresses are declared according to how you use them: if you use them to determine location, that usage drives the answer.
Data Collection vs. Data Sharing: What's the Difference?
Collection and sharing are separate answers, and a single SDK can trigger both.
Collection means data leaves the device. Processing that stays local — filtering an image, calculating a score, caching a preference — is not collection. The moment that data is transmitted to your server or a third party's service, it is.
Sharing means the data reaches another party. Sending analytics to your own backend is collection; sending it to an advertising network is collection and sharing. The User Data policy defines selling separately, and prohibits selling personal and sensitive user data.
Three edge cases need more care than a flowchart can give:
- Pseudonymous data. An identifier that is not a name is still declarable if it can reasonably be linked to a user.
- WebViews you control. Google lists code controlling a
WebViewas an indicator of possible collection. - Ephemeral processing and end-to-end encryption. The form treats these differently, but the conditions are specific rather than automatic — check the current guidance before assuming an exemption covers you.
Android Permissions vs. Data Safety Declarations
This section causes most bad submissions. A declared permission is evidence that your app could access data. It is not evidence that the app collects it.
Google's form guidance lists permission declarations and API calls as places to look — starting points for investigation, not the answer. The answer comes from following what the code does once the permission is granted.
| Permission | Actual data access | Transmitted off-device? | Disclosure may be required |
|---|---|---|---|
ACCESS_FINE_LOCATION | Precise coordinates via location APIs | Only if sent to a server or SDK | Yes, if transmitted — as precise location |
ACCESS_COARSE_LOCATION | Location accurate to roughly 3 km or more | Only if sent off-device | Yes, if transmitted — as approximate location |
READ_CONTACTS | Reads the device contact list | Only if uploaded or synced | Yes, if transmitted; not if purely local |
INTERNET | No data category by itself | Enables transmission; is not data | Not on its own; declare what it carries |
| No permission declared | An SDK may still read identifiers or usage data | Possible | Yes — why the manifest is not enough |
The last row is the one teams miss. Third-party code can collect data without you writing a line that touches it, and without a permission that makes it obvious. If your audit stops at AndroidManifest.xml, your declaration describes your intentions rather than your app.
Developer tip: run a release build through a network inspector and read the list of hosts it contacts. It is usually faster — and more accurate — than tracing permissions by hand.
For the runtime side — requesting permissions and handling denial without breaking the flow — the Android app permissions guide covers the implementation.
How Third-Party SDKs Affect Your Data Safety Answers
Google is explicit: if a third-party SDK or library in your app collects or shares user data, you must reflect that in the form. Responsibility does not transfer with the code.
What you must not do is assume uniformity. Firebase products are separate SDKs with separate behaviour; an analytics SDK differs from a crash reporter; the same vendor's advertising and authentication libraries answer different questions. The declaration follows the actual product, version, configuration and calls you make.
| Component | What to inspect |
|---|---|
| App code | Forms, hidden text input such as password fields, upload paths, and any call posting to a remote endpoint. Google lists forms and alerts, autofill support and data access auditing APIs as general indicators. |
| Firebase products | Which product, which version, and whether it logs events or user properties. Treat each product separately. |
| Analytics SDKs | Event names and parameters you send, plus automatic collection the SDK performs unasked. |
| Crash reporting | Whether device state, logs or custom keys attach to reports, and whether identifiers are included. |
| Advertising SDKs | Identifiers used, whether data is shared with the ad network, and any consent gating the SDK documents. |
| Authentication SDKs | Which profile fields arrive in the token, and whether they are stored or only used to sign in. |
| Payment SDKs | What your app receives versus what the provider handles, and whether purchase history stays with them. |
| WebViews | Which pages load, what JavaScript bridges are exposed, and whether the page can reach device APIs through your app. |
| Backend and APIs | What your servers log by default, including IP addresses and identifiers, and how long records are kept. |
Google publishes per-SDK disclosure information for the Google Play services libraries, split between data collected automatically and data collected depending on how you invoke the SDK. It covers only the latest versions listed and recommends re-reading whenever you change versions.
Google also publishes an SDK Index for exploring SDKs used on Play, and providers can register on Play SDK Console to share information; Play can warn you about a problematic SDK version before you publish. Treat both as starting points, then confirm in the SDK's own documentation for the version you ship.
How to Prepare Before Opening the Form
Open the form first and you will answer from memory. Do the evidence work first and the form becomes transcription.
Practical ways to do the audit:
- Search for network calls and upload paths rather than starting from permissions.
- List every dependency with its version, then check each provider's disclosure docs for that version.
- Review what your backend logs, including request metadata you never asked for.
Test the real artifact rather than a debug build, because debug tooling changes what is transmitted. For coverage beyond your own device, the real device testing guide covers picking hardware.
Step-by-Step: How to Complete the Data Safety Form in Play Console
Google documents the form as living on the App content page in Play Console. Play Console labels change over time, so treat the wording below as the shape of the workflow and confirm the current labels in your own console.
- Open Play Console and select your app.
- Go to the App content page and find Data safety.
- Read the overview before answering anything.
- Answer the collection questions for the app as a whole: whether it collects or shares any applicable data types.
- Answer the security and deletion questions where they apply — encryption in transit, and whether users can request data deletion.
- Select the data types your audit found, then set collected or shared, required or optional, and the purposes.
- Describe the handling for each type, including ephemeral processing where that option exists.
- Check the store listing preview. It shows what users will read; if it reads as vague or contradicts your policy, fix the answers rather than the wording.
- Save and return later if unsure, or submit when the answers reflect the audit.
On deletion, the form asks whether you provide a mechanism for users to request data deletion. Google documents that you can select the deletion-related option if you provide such a mechanism, or if you automatically delete or anonymize collected data within 90 days of collection. There is no prescribed mechanism, but the route should be easy to find — an in-app feature, a contact form, or a dedicated email address.
How to Review and Submit Your Answers
Review is where a rushed submission gets caught, so do it as a separate pass with the audit open beside you.
Four checks worth doing every time:
- Completeness. Every data type in your audit appears, and nothing appears that the audit did not find.
- Required versus optional. Nothing is optional if any users must provide it.
- Consistency. Policy, in-app disclosure and form should describe the same practices; a policy omitting a declared collection is a visible inconsistency.
- Recency. Re-check after every release that adds an SDK, changes configuration, or touches user data.
The declaration does not end at submission. Google requires it to remain accurate and complete at all times. Because the form is global and version-agnostic, a practice added in one release immediately becomes part of the answer for the whole app.
Common Data Safety Mistakes Developers Should Avoid
| Mistake | Better practice |
|---|---|
| Answering from the manifest | Trace each permission to the API call and then to the network request. A permission without transmission is not a declaration; an SDK without a permission can still be one. |
| Treating all Firebase products as one answer | Check each product, version and configuration separately against its own disclosure documentation. |
| Marking everything optional | If any user must provide the data to use the app, it is required. Optional means genuinely skippable. |
| Omitting a region-specific practice | One global form per package. A practice in any currently distributed version, anywhere, belongs in the answers. |
| Privacy policy only on the listing | Google's policy expects a valid policy in both the store listing and inside the app. |
| Treating account freeze as deletion | Google states freezing is not a valid substitute, and deletion must be available in-app and on an external web resource. |
Practical Pre-Submission Checklist
- Every dependency listed with its version, each checked against its own disclosure docs.
- Network traffic from a release build inspected, not just source code read.
- Backend reviewed for what it logs and stores by default.
- Each declared data type mapped to a specific feature and purpose.
- Required versus optional set from real user flows.
- Sharing answers reviewed separately from collection answers.
- Privacy policy live, linked from the listing, and reachable inside the app.
- Policy text matches the form, including third-party sharing and retention.
- A deletion route users can find, in-app and on the web.
Frequently Asked Questions
Do all apps need a Data Safety form?
Apps on closed testing, open testing or production need one. Google documents that apps active only on internal testing tracks are exempt from inclusion in the Data safety section.
What counts as data collection?
Data leaving the device. Processing that stays local is not collection, but transmission to your servers, an SDK provider, or a third party is — including via a WebView you control.
Is declaring a permission the same as declaring collection?
No. A permission shows your app could access data. Whether it is collected depends on what the code does with it and whether that data is transmitted.
Do third-party SDKs count towards my declaration?
Yes. Google requires SDK and library collection to be reflected in the form, and responsibility stays with you as the developer.
What if a data practice only affects one app version?
It still belongs on the form. Google documents one global form per package describing the sum of collection and sharing across all versions currently distributed on Play.
Where does the form live in Play Console?
On the App content page, as Data safety. Labels change, so confirm the current wording in your console.
Do I need a privacy policy inside the app?
Google's User Data policy expects a valid privacy policy in both the store listing and within the app.
What happens if my declaration is wrong?
Google requires you to correct misrepresentations; apps that do not become compliant face enforcement, including blocked updates or removal from Play.
Official Google Resources
- Provide information for Google Play's Data safety section — the form itself, global scope, deletion mechanism, and review questions
- Declare your app's data use — data categories mapped to permissions and API calls, and general indicators to audit
- User Data policy — transparency, privacy policy, prominent disclosure and consent, account deletion
- Google Play Developer Program Policy — the parent policy set that the User Data policy belongs to
- Prepare for Google Play's data disclosure requirements — per-SDK disclosure information for Google Play services libraries
- Google Play SDK Index — exploring SDKs used on Play and how providers share information with developers
Conclusion
The Data Safety form is a short questionnaire on top of an audit. Answer it from evidence — code, dependencies and observed network traffic — and it takes an afternoon. Answer it from memory and it becomes a liability that surfaces months later as a blocked release.
Three habits prevent most problems: start from transmission rather than permissions, audit each SDK by product and version rather than by vendor, and keep the policy, the in-app disclosure and the form describing the same app.
If your audit turns up real defects rather than disclosure gaps, the bug report guide covers recording them so they get fixed, and the closed testing checklist covers the release steps. TestersHQ works with developers on the pre-release validation that surfaces both.
