arXiv dataset maps third-party SDKs across nearly 100,000 Android apps

What happened on this date

On 2026-07-02 (13:19 UTC), the paper "A large-scale dataset of Android applications and their SDK dependencies" (arXiv 2607.02627, v1) was submitted. The authors describe a dataset that links Android apps to the third-party SDKs they embed, covering advertising, analytics, authentication, crash reporting, location and more. It was built by combining APKs and metadata from AndroZoo with SDK detection rules from Exodus Privacy, using a reproducible static-analysis pipeline that downloads APKs and matches code-level signatures. The release covers 334,719 app-version observations across 99,722 apps and 246 SDKs, maps SDKs to the companies operating them, and is published on GitHub and Zenodo.

What it means for protecting app logic

The paper is about third-party dependencies, data collection and privacy, but it illustrates a broader point: under large-scale static analysis, which SDKs an app uses, and in which versions, is effectively public. For teams worried about cloning, this means the tech stack itself is not a secret, and an imitator can quickly reproduce the same dependency mix. What is genuinely hard to copy should be the smaller part beyond the SDKs: your own logic, data and server-side capabilities. It is also a reminder that SDK initialization parameters, default configuration and any keys shipped in the package are equally visible. A caution: signature-based detection depends on rule coverage, and the paper reports results for the authors' pipeline, so it says nothing precise about detection accuracy for any single app.

Checks to run on your own builds

First, build an SDK and version inventory from the final released APK/AAB rather than only from Gradle declarations, because transitive dependencies can pull in components you did not expect. Second, compare that inventory with your Play Console Data safety declaration and privacy policy to make sure no data recipient is missing. Third, review each SDK's initialization code; treat any API key or account identifier written into the client as public, and move what you can behind a server-side proxy or narrower permissions. Fourth, accept that your dependency make-up is visible and put differentiation into server-side rules and data rather than hoping to hide which libraries you use. Fifth, regenerate and diff the inventory after every AGP or R8 upgrade.

Your checklist

• Generate an SDK and version inventory from the shipped artifact, including transitive dependencies
• Reconcile it with your Data safety declaration and privacy policy
• Treat SDK keys in the client as public and move what you can server-side
• Regenerate and diff the inventory after toolchain upgrades