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, which makes it the unusual one: a declaration and a binary are two artefacts, and two artefacts can be read against each other.

Read 3 September 2026, from the Play Console Help page rather than from a summary of it.

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 the word 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."

There is also an exclusion for old artefacts that 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 is not a description of the code your team wrote. It is a description of what the shipped app does:

"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" — and 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 together are the whole subject. An SDK's published information is an input to your declaration. It is not a transfer of the declaration. If an analytics library added in a sprint eighteen months ago began collecting an identifier it did not collect before, the form that describes your app is now describing something else, 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 that has the hardest time here is the one that filled the form in carefully at launch and has shipped well since. The form is a point-in-time statement about a codebase that has 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 and is worth reading twice. The enforcement attaches to not becoming compliant, not to having been wrong. An inaccurate form is a thing to fix. An inaccurate form that stays inaccurate is the one with consequences attached.

Google also states its own review times, which is useful 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." That is Google's statement about Google's process, and nobody else can commit to it.

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 is different, because the declaration makes claims that the artefact either supports or does not.

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, which is the half 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. They are different documents, and the difference is precisely 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.

What this is not

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

There is also no such thing as a Data safety certificate or a verification anyone can issue you. Google reviews the form as part of the app review process and shows the result on the store listing. Everything else is your own evidence, for your own use, which is the honest description of what a comparison like this produces.