Google Play Data Safety: Build an SDK Inventory Before Completing the Form

Start the Data safety review with the app's actual components and behavior, not a copied set of answers. A useful SDK inventory connects each library or service to its version, configuration, data flow and supporting documentation. It gives the publisher a way to ask precise questions before submitting declarations.

Google's guidance makes clear that third-party libraries and SDKs are part of the app's data practices and that the developer remains responsible for accurate declarations. This article is a technical evidence workflow, not a legal assessment or a completed disclosure for your app.

Inventory the release candidate, not just the source proposal

Ask the developer for the dependency list associated with the build being reviewed. Include advertising and mediation adapters, analytics, crash reporting, authentication, payments and other connected components. Record the versions and configuration references, rather than writing only a familiar product name.

A proposal may say “analytics included” without identifying which SDK is in the release. A removed screen may also leave a dependency or background behavior in the app. Review the delivered build and its configuration; do not assume a marketing feature list describes the complete data flow.

SDK and service inventory worksheet

Field	Question to resolve
Component and version	Which exact library or service is in this release?
Purpose	What app function needs it?
Configuration	Which options change the behavior?
Data flow	What leaves the device, under what conditions, and to whom?
Provider evidence	Which version-specific disclosure or documentation supports the answer?
App evidence	What code, build configuration or observed flow confirms this app's use?
Review owner	Who checked the entry and what remains uncertain?

Use examples as investigation prompts, not copied answers

Consider a hypothetical app with an advertising SDK, crash reporting and account sign-in. Those three rows need separate investigation even if the publisher describes the product as “a simple free app.” The same provider name can also represent different features or settings in different projects.

For each row, ask the implementer to explain the relevant behavior in plain language and point to its evidence. Mark an unanswered question as unresolved. Do not turn uncertainty into “no data collected,” or turn a provider's generic document into a claim that every feature described there is enabled in your app.

Check the provider page against the installed SDK branch

Google Mobile Ads publishes data-disclosure guidance for its SDK, including a warning to check the version covered. That page is evidence for the component it describes; it does not complete the assessment for your app's other libraries, backend or configuration.

Save the reference URL, checked date and installed version in your worksheet. If the page covers a newer branch, ask what changed and find documentation appropriate to the actual implementation. Avoid copying a fixed list of data types into a project record without checking which SDK and settings the record represents.

Follow data beyond the visible screen

• Check sign-in and account creation, including optional fields.
• Identify analytics and diagnostic events, including background activity.
• Review advertising and mediation components separately from the app's own backend.
• Identify embedded website flows or forms and who operates them.
• Record relevant configuration, consent choices and user controls without assuming they behave identically in every region or device state.

The goal is a defensible evidence map. A network observation can help investigate behavior but is not, by itself, a complete inventory: some flows may depend on a later action or a different configuration. Combine the build's dependency/configuration evidence with provider documentation and targeted checks.

Review declarations and supporting pages together

Compare the proposed Data safety answers with the app's actual behavior and its public privacy information. If the developer's explanation and the public wording conflict, resolve the underlying facts first. Do not hide a contradiction by changing only the store form.

Keep access scoped while collecting this evidence. A developer can supply dependency and implementation details without asking for the owner's Google password. Use the collaboration checklist to arrange an appropriate working relationship.

Make the inventory part of release maintenance

Record which release the review covers and what will trigger a new check: adding an SDK, changing a feature, replacing an advertising adapter or altering a data flow. Keep the reviewed inventory with the app handover record. An old answer set should not silently become the default for every future release.

If you are commissioning the work, ask for this inventory and its unresolved questions as a named deliverable. A blanket promise that an app is “privacy ready” is less useful than a traceable explanation of the actual components. Final declarations should be checked against the current form and the app's facts by the responsible publisher.

Sources

Google Play Data safety guidance and Google Mobile Ads data-disclosure guidance, checked on publication. This worksheet is an editorial aid and does not replace the live form or any applicable professional review.