Google Play's Data Safety form: where almost everyone gets it wrong

You publish an app with no sign-up, no server and nothing stored off the device. You fill in the Data Safety form marking “no data collected”, because that is literally true.

Weeks later an email arrives from Google Play: invalid Data Safety form. The app is now at risk of removal.

It’s one of the most common and most frustrating situations in Android development, and it almost always comes from the same misunderstanding.

What the form is really asking

The question isn’t “do you collect data?” It’s:

Is data collected from your app?

That difference is everything. Google isn’t asking about the code you wrote. It’s asking about everything that leaves the device from your application, whether your code caused it or a library you included did.

And here’s the part almost nobody has front of mind: a third-party SDK is your app. If you integrate an ad kit, an analytics system or a crash reporting platform, everything that component sends counts as collection by your app. You are responsible for declaring it, even though you wrote none of that code and never see the data.

The most common case: advertising

An ad kit needs, by its very nature, an identifier to know who it’s showing what to. On Android that’s the advertising ID, and in Google’s taxonomy it falls under Device or other IDs.

That identifier leaves the device the moment an ad is requested. It doesn’t matter that you never read it, never store it and couldn’t tell anyone what it is. It is collected, and it must be declared.

For a free app with ads, the correct declaration usually looks like this:

Field	Value
Data type	Device or other IDs
Collected?	Yes
Shared?	Yes — it goes to the ad network, a third party
Required?	Yes — ads can’t be served without it
Purpose	Advertising or marketing

Marking “no data collected” while shipping an ad SDK is, in practice, the number one cause of this notice.

The contradiction that triggers review

Google doesn’t just read your form. It cross-checks it against other signals:

• Analysis of the package itself, which reveals which SDKs you bundled
• The network traffic the app generates when it runs
• The permissions declared in your manifest
• What your privacy policy says

When any of those contradicts the form, review triggers. The usual trigger is simple: analysis detects a known ad SDK, and the form says nothing is collected. The contradiction is obvious without a human being involved.

The other three stumbles

In-app purchases. If you have subscriptions or payments, purchase information is processed. Even though Google Play handles the billing, your app is part of the flow and there is usually something to declare. Worth reviewing specifically rather than assuming it’s covered.

Crash reporting. Very easy to overlook. A crash reporting SDK sends the device model, OS version and a stack trace — which can contain session data. That’s collection, and there’s a category for it.

A privacy policy that doesn’t match. Google compares the two. If the form declares advertising IDs but the policy says “we collect no data whatsoever”, the contradiction is right there in the open. Both documents have to tell the same story.

That last point gets harder when you run several apps with different configurations. If some only have ads and others also have subscriptions, one generic policy won’t cover both: it will end up false for one group or the other. The sensible approach is one policy per real configuration, with each listing pointing at its own.

On-device processing doesn’t mean zero data

There’s a subtle trap here that catches a lot of honest developers.

You can have an app that does everything on the device: edits the photo locally, uploads nothing, has no server. That’s true, and it’s a good property of your product.

But if that app shows ads, the advertising ID does leave. Your processing is local; your monetisation isn’t. Both live in the same binary, and the form asks about the whole thing.

The correct declaration reflects exactly that: no user content collected, device identifiers collected for advertising. It’s a more precise answer than either extreme.

How to check before you submit

A procedure that works:

1. Inventory your dependencies. Open your build file and list every third-party library. For each one, ask: does this send anything to the internet?
2. Read each SDK’s data documentation. Serious vendors publish exactly what they collect; many provide the table already formatted for this form.
3. Watch the real traffic. Run the app with a network inspector and see which domains it calls. It’s the most honest check, because it shows what actually happens rather than what the docs claim.
4. Check your manifest permissions. A permission declared but unexplained in the form is a contradiction signal.
5. Read your privacy policy next to the form. They must say the same thing. If they don’t, fix both, not one.

If you already have the notice

Don’t panic: there’s normally a deadline and no immediate removal.

Correct the form with the real declaration, update the privacy policy to match, and submit. If the same problem affects several apps on your account, fix them all at once. Fixing only the one that got flagged leaves the rest exposed to the next review cycle, which will come.

What’s behind all this

The form exists because your Play listing shows users a summary of what data leaves their phone. People use that information to decide whether to install something.

Seen that way, over-declaring costs you nothing: nobody uninstalls a free app for learning that it shows ads, which they already assumed. Under-declaring, by contrast, puts your entire developer account at risk — not just that one app.

When in doubt, declare. The asymmetry is in your favour.