arXiv 数据集：近十万款 Android 应用的 SDK 依赖图谱

当天发生了什么

2026-07-02（UTC 13:19），arXiv 上提交了论文《A large-scale dataset of Android applications and their SDK dependencies》（2607.02627，v1）。作者介绍了一个把 Android 应用与其内置第三方 SDK 对应起来的数据集，涵盖广告、分析、登录认证、崩溃上报、定位等类别。构建方法是把 AndroZoo 的 APK 与元数据和 Exodus Privacy 的 SDK 检测规则结合起来，用可复现的静态分析流程下载 APK 并匹配代码层面的签名。数据集包含 99,722 款应用的 334,719 条“应用-版本”观测和 246 个 SDK，并把 SDK 映射到运营公司，流程和数据在 GitHub 与 Zenodo 上公开。

对保护应用逻辑意味着什么

这篇论文本身研究的是第三方依赖、数据收集和隐私，但它从侧面说明了一件事：在规模化的静态分析面前，一个应用用了哪些 SDK、用了哪些版本，基本可以视为公开信息。对担心被克隆的团队来说，这意味着技术栈本身不是秘密，模仿者可以很快复刻同样的依赖组合；真正难复制的应当是 SDK 之外那一小部分自有逻辑、数据和服务端能力。它也提醒开发者，SDK 初始化参数、默认配置和随包分发的密钥同样会被看到。需要保持谨慎的是，基于签名的检测依赖规则库覆盖面，论文给出的是作者流程下的结果，不能据此推断任何单个应用的检测准确度。

可以在自己的构建上做的检查

第一，从最终发布的 APK/AAB 而不是只从 Gradle 声明出发，整理一份 SDK 与版本清单，因为传递依赖可能带进你没预期的组件。第二，把这份清单与 Play 管理中心的 Data safety 声明和隐私政策对照，确认没有遗漏的数据收集方。第三，检查各 SDK 的初始化代码，凡是写在客户端的 API Key、账号标识都按“公开”处理，能在服务端代理或限权的就迁移过去。第四，接受“依赖构成可见”这一事实，把差异化放在服务端规则和数据上，而不是寄望于隐藏用了哪些库。第五，每次升级 AGP 或 R8 后重新生成清单并比对差异。

行动清单

• 从发布产物生成 SDK 与版本清单，包括传递依赖
• 与 Data safety 声明和隐私政策逐项对照
• 客户端中的 SDK Key 按公开处理，能迁移的迁到服务端
• 升级构建工具后重新生成并比对清单