Play Data Safety: declared versus observed
How often a Play Data Safety label disagrees with what the same build demonstrably contains — and every reason it might do so innocently.
Published 2026-10-07 · apk-scanner.com research
Historical snapshot · 2026-10-07. Figures and checks describe the published study, not current exposure. Verification applies to the date the check ran. Current methodology
What this does and does not show
This is a static signal, not a finding of wrongdoing. It compares what an app declares in its Play Data Safety label against what the same build demonstrably contains: the permissions it requests and the third-party SDKs it ships. A mismatch is a reason to ask a question. It does not establish that any data left the device, that a declaration is incorrect, or that a Play policy was breached.
There are ordinary explanations for every mismatch below. An advertising SDK can ship in a build and never be initialised, be configured without data collection, or sit in a variant that is never shipped to users. A permission can be requested for processing that never leaves the handset. Only the app's developer can distinguish those cases from an under-declaration, which is why each affected report links to a way to respond.
Population
Of 6,460 public app reports, 2,714 have a most-recent scan that actually compared a Data Safety declaration against the package. Those 2,714 are the denominator for every figure here. The other 3,746 are excluded because no declaration was available to compare at the moment that scan ran — Play did not serve one, or the parser could not read both of its sections.
That exclusion is more than half the corpus, and it is deliberate. An unread section looks exactly like a section declaring nothing, and an earlier version of this analysis treated it that way — publishing 282 apps as declaring no collection and no sharing when the parser had simply failed to extract their labels. The comparison now refuses to run unless both the “Data collected” and “Data shared” sections were positively read.
The figures are also read from the comparison each scan recorded, not from the label stored against the app. Those drift apart: a stored label is kept when a later scan fetches none, so it can describe a build that was never compared. Counting findings from one population against labels from the other is how the first version of this page understated the omission rate as 15.2% when it was 25.9%.
Apps shipping ad or attribution SDKs while declaring no data shared
41 of 2,714 apps (1.5%) ship at least one SDK we classify as advertising or attribution while their “Data shared” section is empty.
This is the narrower and more interesting of the two signals, because an empty “Data shared” section is an affirmative statement rather than an omission. It is still only a question: the SDK's presence is read from the package, not from its behaviour, and an uninitialised SDK shares nothing.
Declarations that omit a category the app can reach
696 of 2,714 apps (25.6%) request a permission for a data category their declaration does not list, in either the collected or the shared section.
| Category | Apps |
|---|---|
| Location | 379 |
| Contacts | 312 |
| Calendar | 170 |
| Messages | 27 |
| Health and fitness | 3 |
Only five categories are compared, and the exclusions matter more than the inclusions. Camera, microphone, photos and phone are deliberately not diffed, because Play exempts data that is processed only on the device, and an offline scanner or photo editor would otherwise be reported for a declaration that is entirely correct. The five above are categories where requesting the permission is strong evidence that the data is reachable — which is still not evidence that it is collected or sent anywhere.
Method
For each app we take the most recent public scan, parse the Play Data Safety label into its “Data collected” and “Data shared” sections, and compare them against two observations from the same build: the permissions in the manifest, and the third-party SDKs identified in the package. A category counts as declared if it appears in either section, so an app that lists a category as collected but not shared is not reported.
Nothing in this study runs the app, instruments it, or observes network traffic. No credential found in an APK is ever used to authenticate, and no stored data is read — see how analysis works and the limits of this evidence. Findings of this kind are recorded as unverified by design: there is no probe that could confirm them without observing the app at runtime.
If this is your app
Every figure resolves to named reports you can open and check. If a mismatch has an explanation — an SDK you ship but do not initialise, a permission used only on-device — tell us and we will record it against the finding. See how to respond to a finding and the Data Safety review guidance, which links the primary Play references rather than paraphrasing them.
Figures are computed from the current corpus each time this page is served and will move as builds and coverage change. For a claim you need to cite at a fixed point in time, cite a dated individual report, or a signed Proof Capsule.