Build a Third-Party SDK Inventory for Local AI

Direct answer

A third-party SDK inventory answers a static question: what code is included in a particular app artifact, what does the team believe each component is for, and what evidence supports that belief? It is not the same as watching network traffic, and an SDK listed in a build does not prove that the SDK executed or transmitted data in a tested session. Conversely, a missing name in a top-level dependency file does not prove the final package contains no transitive or bundled code. PRIVACY-01 and PRIVACY-02 support documenting data boundaries and disclosure decisions; they do not describe the contents of any particular release artifact. Pin the package variant and build type first. Record application version, build variant, dependency lockfile revision, resolved dependency graph, and the exact artifact inspected. A debug APK, release APK, dynamic feature, and split install can differ. Include native libraries, generated code, plugins, and SDKs brought in by other libraries. Keep the dependency graph as evidence rather than copying a vendor marketing list. If an SDK is optional or enabled only after consent, document that configuration and the code path that enforces it. For each component, create a row with the exact artifact and version, direct or transitive path, feature that invokes it, initialization timing, permissions or sensitive APIs, known data categories, destinations described by the provider, and any collection controls. Separate known facts from provider claims, code inference, and unknowns. A general statement that an SDK is for analytics is not enough to know what fields leave the process. Read the vendor’s current privacy documentation and version notes, but mark those statements as vendor-published claims until the packaged version and integration are checked. Use a consistent classification vocabulary: app-provided content, device or diagnostic metadata, account identifiers, transfer metadata, and data derived from user activity. Do not call an identifier anonymous solely because it is pseudonymous, and do not infer purpose from a field name. Record whether a value is user-entered, generated, device-generated, or collected by the component. If the SDK documentation does not say whether a field is transmitted, label that as unknown instead of filling the gap with assumptions. Compare the inventory with the final artifact. Inspect the resolved dependency report, package contents, manifests, native libraries, and feature flags for the exact release candidate. An SDK dependency can be present but dormant; it can also initialize automatically before a visible feature is opened. Static inspection establishes inclusion and configuration, not actual runtime behavior. Dynamic tests belong in a separate audit that records requests, triggers, and payloads. Keep those two records linked but do not merge their conclusions. Treat permissions as evidence to investigate, not as proof of collection. A declared permission may be unused in a specific flow; a library may also use APIs that do not require a runtime permission. Map each permission and sensitive API to its feature owner and a test. If no user-facing function needs a component, record a removal candidate and check whether removal breaks other functions. Do not remove production code or alter an app’s permission state based on this checklist alone. Finally, map inventory rows to the product’s disclosure review. Google Play says developers remain responsible for third-party code and its user-data practices in the shipped app. Apple’s privacy documents similarly describe app and SDK responsibilities for their platform. These sources support a review process, not an automatic compliance conclusion. The completed inventory should include unresolved items, a reviewer, date, package identity, evidence links, and next action. Repeat after a dependency update or build-variant change. This page makes an inventory reproducible; it does not claim that any particular local AI application has no SDK data flow.

A release review finds an unfamiliar transitive SDK

A mobile team is preparing a privacy review for a release build and notices a transitive analytics library that does not appear in the feature team’s top-level dependency list. The reviewer needs to identify its exact version and owner before deciding whether additional runtime tests are required.

Decision

Inspect the resolved graph and final package, document provider statements separately from observed behavior, and avoid declaring the component dormant without a tested trigger.

Expected outcome

The release record names the artifact, dependency path, declared purpose, unknowns, and follow-up audit instead of making a no-data-collection claim.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Dependency inventory
• Traffic capture
• Feature-off behavior

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Pin the inspected artifact. Record release build variant, app version, lockfile revision, resolved dependency report, package hash, and any dynamic feature or split configuration.
2. Enumerate direct and transitive components. Include plugins, native libraries, generated code, and SDKs included by dependencies; link every row to the exact package and version.
3. Map function, access, and provider statements. For each component, record feature owner, initialization path, permission or API use, documented data categories, destinations, controls, unknowns, and evidence owner.
4. Compare the inventory with the final package. Inspect manifests and packaged libraries for the release candidate, then separate inclusion evidence from actual runtime requests and payload evidence.
5. Resolve or assign unknowns. Assign an owner and next test for undocumented fields, optional modules, or unexplained components; repeat the review after dependency or build changes.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Every listed component is tied to the exact package version and build artifact; the inventory distinguishes direct and transitive dependencies.
• Provider statements, static code observations, and runtime observations are clearly labeled as different evidence types.
• Unknown purposes or fields remain unknown and receive an owner and follow-up rather than being converted into a privacy guarantee.

Decision table

Failure patterns to prevent

• Assuming SDKs are dormant
• Omitting analytics endpoints

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove network audit
• Google Play SDK requirements
• Google Play Data safety section
• Apple third-party SDK requirements

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions