Build two inventories
The first inventory describes the build: direct dependencies, transitive dependencies and the versions resolved for the release. The second describes behavior: initialization, collection settings, consent requirements and data flows.
| Inventory field | Why it matters |
|---|---|
| Resolved version | Policies and vulnerabilities can be version-specific |
| Initialization path | An SDK may start before your main screen |
| Data categories | Needed for privacy and Play disclosures |
| Destination and purpose | Distinguishes analytics, ads, diagnostics and core features |
| Consent or opt-out controls | Determines behavior before and after a user choice |
| Removal owner | Makes an obsolete SDK actionable |
Check the final package
Use the resolved Gradle graph and inspect the shipped APK or split set. An SDK can arrive transitively or remain through a different dependency after you remove a direct declaration. Obfuscation can also make name-only detection incomplete.
APKLint's tracker detector and SDK scanner help surface recognizable indicators, but those indicators do not prove every library or exact version has been identified.
Verify behavior under different states
Observe a clean installation before consent, after consent, after withdrawal and after logout where applicable. Use test accounts and controlled traffic inspection. Check background initialization and failure paths, not only the happy path through your settings screen.
Do not assume a documentation statement about an SDK's optional feature describes your configuration. Compare provider documentation with the actual settings and observed requests.
Reconcile disclosures
Google Play's Data safety guidance makes the developer responsible for data practices in the app, including relevant third-party code. Maintain a mapping from each disclosed data category to the feature or SDK responsible for it.
A tracker scanner cannot fill the Data safety form accurately by itself: collection, sharing, optionality and purposes require context that static package inspection does not contain.
Make updates reviewable
Treat an SDK upgrade as a data-flow change until checked. Review release notes, permissions, initialization and disclosure implications. Retain the inventory per release so a future policy question can be answered with evidence rather than a guess about what the current source tree contains.
Sources and further reading
Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
