Your Data safety form is a declaration about a binary, and the binary keeps changing

Most Google Play obligations are things you do in a console. This one is a claim about what your code does, and you can check that claim against the binary.

Quotations below are from the Play Console Help page, read 3 September 2026.

Who it binds, and since when

Google's scope sentence has no qualifiers in it:

"All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks."

And it reaches apps that collect nothing:

"After July 20, 2022, all apps will be required to have completed an accurate Data safety form that discloses their data collection and sharing practices (including apps that do not collect any user data)."

There are exemptions and they are narrow. "Apps that are active on internal testing tracks are exempt from inclusion in the data safety section. Apps that are exclusively active on this track do not need to complete the Data safety form." Note exclusively: a build promoted to closed testing is no longer on that track alone. Separately, "System services and private apps do not need to complete the Data safety form."

One exclusion is easy to miss and occasionally useful. Developers "may exclude old artifacts from their form", which is "applicable for artifacts with effective target SdkVersion below 21 where the majority of the app’s active user install base (90%+) is on artifacts with effective target SdkVersion 21 or higher."

The clause that makes it a technical question

The form describes the shipped app, including the code your team did not write:

"This includes data collected and handled through any third-party libraries or SDKs used in their apps."

Google offers a way to find out what a library does: "You may want to refer to your SDK providers’ published Data safety information for details. Check Google Play SDK Index to see if your provider has provided a link to their guidance". Google then closes the question of who answers for the result in a single sentence:

"You alone are responsible for making complete and accurate declarations in your app’s store listing on Google Play."

Those two sentences are the whole subject. An SDK's published information feeds your declaration; it does not move responsibility for it. If an analytics library added eighteen months ago started collecting an identifier it did not collect before, your form now describes an app you no longer ship, and the sentence above says whose problem that is.

Why the form drifts without anybody changing it

Nothing has to be done wrongly for a form to stop being accurate. Three ordinary things do it:

• A dependency is added. The declaration was accurate for the dependency set at the time it was filled in.
• A dependency updates. A minor version bump is not usually reviewed for what it collects, and the form is not usually revisited when one lands.
• A transitive dependency arrives. Nobody chose it, nobody lists it, and it is in the merged manifest and the compiled artefact exactly like the ones that were chosen.

The team with the hardest problem here is the one that filled the form in carefully at launch and has shipped steadily since. The form is a point-in-time statement about a codebase that moved.

What Google does about an inaccurate one

Stated plainly on the page, with its conditional intact:

"If we find that you have misrepresented the data you've provided and are in violation of the policy, we will require you to fix it. Apps that don’t become compliant are subject to policy enforcement, like blocked updates or removal from Google Play."

The order matters. Enforcement attaches to not becoming compliant. An inaccurate form is something to fix; the consequences land on one left alone.

Google states its own review times, which matters when planning a release around a correction: "Certain apps may be subject to expanded reviews, which may result in review times of up to 7 days or longer in exceptional cases."

The part that is actually checkable

Almost every store obligation is a console action: you either did it or you did not, and no test tells you anything about it. This one makes claims the artefact either supports or contradicts.

The comparison is between two things you can hold:

1. The declaration, as it currently stands in Play Console.
2. The merged manifest and the resolved dependency set of the shipped artefact, including everything a transitive dependency contributed. That is the part nobody has a list of.

Establishing the second is ordinary binary work. In our own methodology it is the same step as any other Android engagement: "IPA / APK retrieved, decrypted, decompiled, and analysed for hardening posture", plus component mapping across activities, intents, providers, services, schemes and deep links, and the merged manifest with every permission line attributed to whatever contributed it.

Two practical notes on doing it yourself:

• Read the merged manifest, not the manifest in your source tree. The difference between the two documents is the part this exercise is about.
• Take the dependency list from the resolved graph, not from the dependency block in your build file. The block lists what somebody chose. The graph lists what is in the app.

Where this stops

A test does not satisfy a Play requirement, and completing the form does not make an app secure; both obligations sit on the same release. Comparing a declaration against an artefact tells you whether the two agree. Correcting the form is a Play Console action that belongs to the account holder, and no third party can perform it.

Google reviews the form as part of the app review process and shows the result on the store listing. There is no Data safety certificate and no verification a third party can issue. A comparison like this produces your own evidence, for your own use.