Find Trackers and SDKs in Your App

What counts as a tracker or SDK finding

The check separates the libraries that merely sit in the package from the ones that act. These are the classes we document:

• Analytics and attribution SDKs, including ad-identifier linkage across apps.
• Advertising networks that receive purchase or behaviour data.
• Session-replay tools and screen overlays that record how people use the app.
• Push SDKs, including vendor SDKs with a history of public controversy.
• Tags that a tag manager deploys remotely, without an app update.
• Privacy Sandbox and similar advertising APIs declared in the manifest.

How the SDKs are found

We decompile the build and read it. The manifest shows declared providers, receivers, services and permissions. The decompiled classes show which SDK sits behind them and how large it is: one report counts 315 classes for a push SDK, another 3,622 classes for a messaging platform. Class counts separate a stub from a fully integrated SDK.

Each library is correlated across our whole corpus of audited apps, so a finding comes with context: who else ships the same SDK, in which version, and what it did there.

When it starts

Timing decides the legal weight of a finding. The check records whether an SDK initialises at process start through the manifest, whether it waits for consent, and whether it begins working after a device restart before the app was ever opened. A location-marketing tool that starts at boot and a content provider that initialises before the consent screen are different findings with different consequences.

What changes between releases

A new build is checked against the last audited version, permission by permission and SDK by SDK. Apps change their stack with every release, and a tracker that was absent in the last version can be present in this one. The comparison makes that visible.

What you receive

A written report with one entry per SDK: name, version, class count, trigger, endpoints and data categories, each with its evidence from the binary. Human specialists re-verify every finding. The base knowledge graph that ships with the report links SDKs, endpoints and findings. For teams that need the same view across many apps, the Data offer builds SDK and tracker graphs. See the Access page for scope and plans.

Evidence from audited apps

The public ledger lists 387+ audited apps and 262+ critical findings. These full reports show SDK findings in real apps:

• Tchibo: A session-replay tool starting automatically, and 22 tracking tags deployable remotely.
• dm: Three advertising networks receiving purchase data from which health status can be inferred.
• Geizhals: A permanent device fingerprint and four advertising APIs the app does not disclose.
• SAP: A push SDK with 315 classes in a field-service app.
• Gemini: The counter-example: zero third-party tracking SDKs in the app.

Browse the full evidence ledger →

Start with the free check

The free check examines one domain from the outside: read-only, from a European IP address, with no login and no payloads. A researcher reviews your request and replies within one business day. It is an initial external assessment, so it complements the SDK inventory of a full audit and does not replace it.

The plans for a full audit are on the Access page.

See plans and pricing → · Meet The Squad → · Standards and frameworks →

Questions about tracker and SDK checks

Related pages

App Security Audit · GDPR App Audit · NIS2 for Software Vendors