Mobile Ads SDK Audit: Versions, Collection and Unused Adapters

Build an artifact-backed inventory

Compare the release dependency tree, merged manifest and packaged libraries. Record each SDK's version, purpose, owner and supported ad formats. Distinguish active integrations from unused code that still increases app size or contributes declarations.

Do not treat a package-name match as definitive proof of runtime activity. Obfuscation and wrappers can complicate detection, while a detected class may never execute in the tested configuration.

Trace initialization and collection

Identify the first code path that initializes each SDK. Include startup providers, application callbacks, remote configuration and mediation adapters. Check whether consent and audience settings are established before that work.

Keep account-side configuration in the review; static APK inspection cannot see a changed mediation mapping.

Remove safely, then rebuild

For an unused adapter, remove the dependency and associated configuration, rebuild and inspect the result. Test startup and remaining ad sources. Deleting a Java import alone may leave the library included transitively.

Check whether removal changes the manifest, Data Safety answers or privacy policy. A privacy improvement in code should be reflected accurately in documentation, not accompanied by unsupported claims that all collection stopped.

Maintain version compatibility

Review core SDK and adapter compatibility before upgrades. Keep legacy and Next-Gen SDK paths separate, and do not mix a current adapter with an incompatible core merely because both are labelled “latest.”

APKLint's Ad SDK/Tracker Detector provides investigation leads, not a full runtime privacy certification. Combine it with Mobile Ads disclosure, Play Data Safety definitions and mediation documentation to build a release-specific record that another developer can verify.