Your SDKs Collect Data You Do Not Declare. That Leads to Rejection

Android Data Safety: When SDKs Collect Undeclared Data

Google requires every app on the Play Store to have a Data Safety section. It describes what data your app collects, how it's used, and whether it's shared with third parties.

Filling it out feels like a form. But getting it wrong has real consequences.

Inaccurate declarations can lead to policy warnings, enforcement actions, reduced visibility, or in severe cases, suspension. And the tricky part isn't your own code. It's the SDKs you didn't know were collecting data.

What does the Data Safety section cover?

The Data Safety form in Google Play Console asks about:

• Data collection: what data types your app collects (location, contacts, financial info, device identifiers, etc.)
• Data sharing: whether collected data is sent to third parties
• Data handling: encryption in transit, deletion options, whether collection is optional
• Security practices: whether the app follows responsible security practices

Google defines specific data types and categories. Your declarations need to match what the app binary actually does at runtime.

Why is this harder than it looks?

If your app only uses code you wrote, mapping data practices to the form is manageable. You know what you collect.

But most apps include third-party SDKs. And those SDKs can collect data you didn't explicitly ask for.

Common examples:

• An analytics SDK that collects device identifiers, installed app lists, or hardware info
• An advertising SDK that reads the advertising ID and sends it to ad networks
• A crash reporting SDK that collects device model, OS version, and stack traces
• A social login SDK that accesses the user's profile data

Each of these creates a data collection event that needs to be reflected in your Data Safety declaration. If the SDK docs don't mention it clearly, and many don't, your declaration will be incomplete.

Why can't you trust SDK documentation alone?

The Data Safety form expects you to know exactly what data every component in your binary collects.

SDK documentation quality varies wildly:

• Some SDKs publish a detailed data collection guide specifically for the Data Safety form
• Some mention data practices buried in their privacy policy
• Some don't document their data collection behavior at all

For well-maintained SDKs, you can find data safety guidance. For smaller libraries, vendored code, or older dependencies, you're often guessing.

Binary analysis helps here. Instead of relying on documentation, analyze the compiled APK or AAB to detect actual data collection signals: network endpoints, identifier access, permission usage, and data storage patterns.

How does Google verify your declarations?

Google doesn't just take your word for it.

They verify Data Safety declarations through a combination of automated review, policy audits, and user reports. The specifics of their automated analysis aren't public, but the trend is toward more sophisticated verification.

When Google finds a mismatch between your declaration and actual app behavior, you receive a policy notice. Depending on severity, consequences range from a warning with a deadline to reduced visibility or suspension.

Relying on incomplete or outdated declarations is risky.

How do SDK behaviors map to Google's data types?

The practical challenge is translating SDK behavior into Google's data type categories.

Here's how common SDK behaviors map to Google's data type categories:

SDK Category	Data Collected	Google Data Safety Type
Analytics (e.g. Firebase Analytics)	Device ID, usage events, sessions	App activity, Device or other IDs
Crash reporting (e.g. Crashlytics)	Stack traces, device model, OS version	Crash logs, Device or other IDs
Advertising (e.g. AdMob)	Advertising ID, coarse location, app usage	Advertising ID, Approximate location
Social auth (e.g. Facebook SDK)	Profile name, email, profile photo	Personal info
Location services	GPS coordinates, coarse location	Precise location, Approximate location
Device identifiers	Android Advertising ID, unique device ID	Device or other IDs

Analytics SDKs vary widely. Some only collect app interaction events, others pull device info and location data. Check the specific SDK's behavior rather than assuming based on category.

How do you keep your declaration accurate?

Step 1: inventory your SDKs

You can't declare data practices accurately if you don't know what's in your binary. Start with a full SDK inventory of the compiled APK or AAB, not just your build.gradle dependencies.

Step 2: document data practices per SDK

For each SDK, record: - what data it collects - whether collection is required or optional - whether data is shared with the SDK provider - whether the user can request deletion

Step 3: map to Google's categories

Translate each SDK's data practices into Google's specific data type categories. This is tedious but necessary.

Step 4: update on every dependency change

SDK updates can change data collection behavior. A minor version bump in an analytics SDK might add a new data signal. Treat dependency updates as triggers to review your Data Safety declaration.

Step 5: verify with binary analysis

After building your release artifact, scan the binary for actual data collection indicators. Compare detected behavior against your declaration.

What are the most common mistakes?

Declaring only your own code's data practices

Your code might collect email and password. But if Firebase Analytics is embedded, it collects additional data. Your declaration needs to cover all of it.

Using "No data collected" when SDKs collect data

Some developers select "My app doesn't collect or share any user data" because their own code doesn't. But SDKs in the binary do. Google checks the binary, not your intent.

Not updating after SDK changes

You filled out the Data Safety form at launch. Since then, you've updated three SDKs, added a new analytics provider, and integrated a crash reporter. The form still reflects the original state.

Confusing "collected" with "shared"

Google distinguishes between data you collect (store or use on the server) and data you share (send to third parties). Google's definitions include exceptions for service providers processing data on your behalf, but the line between a service provider and a third party requires careful evaluation of your SDK agreements. When in doubt, declaring the data practice is safer than omitting it.

Forgetting the account deletion requirement

Google requires that apps offering account creation also provide in-app account and data deletion options. This is related to but distinct from Data Safety declarations. If your Data Safety section says users can request data deletion, the functionality needs to exist in-app.

Ignoring optional data collection

Some SDKs let you disable certain data collection via configuration. If you've opted out, you don't need to declare it. But verify that the opt-out actually works in the binary. Configuration flags that are supposed to disable telemetry don't always do what they claim.

What does a practical tooling approach look like?

Manually auditing every SDK in your dependency tree doesn't scale. Teams ship updates weekly. Dependencies change constantly.

A more sustainable approach:

1. Automate SDK inventory as part of your build pipeline
2. Flag new or changed SDKs for data practice review
3. Scan the binary for data collection signals
4. Track declarations alongside your dependency manifest, so changes to one trigger review of the other

AppCompliance scans APK and AAB files to detect embedded SDKs, dangerous permission declarations, and privacy-related patterns. This gives you a factual baseline for your Data Safety declaration instead of relying solely on SDK documentation.

No tool can fill out the Data Safety form for you. Some decisions require judgment (whether collection is optional, whether you offer deletion). But having accurate binary-level data makes those decisions easier and keeps your declaration honest.