如何弄清楚你的 SDK 收集了什么
一套可重复的方法，一个基于 Firebase 官方公布数据表的实例，以及当供应商什么都不公布时该去哪里找。
打开你的依赖文件，列出每一个第三方 SDK，然后阅读每家供应商自己的数据披露页面——例如 Firebase 就公布了其每个产品具体收集哪些数据。这份清单就是你隐私政策的实质内容，也是你的 Data safety 和 App Privacy 回答必须依据的来源。
几分钟就能搞定
AppFoyer 托管本指南所讲的页面——隐私政策、服务条款、支持、账号删除和 app-ads.txt——放在它们自己的子域名上，你无需自己的域名或服务器。一个应用免费，而且商店要求的任何内容都绝不放在付费墙后面。
核查于 2026年9月19日。 商店政策会变，有时不会事先通知。下文所有内容都链接到官方文档，以那个页面为准，而不是本页。如果两者不一致，以商店为准。 本指南译自英文；引用的商店文档保留英文原文。
商店关于数据的每一项要求，归根结底都是同一份清单，而几乎没有人把它写下来。你的隐私政策、你的 Data safety 表单和你的 App Privacy 回答，是同一份清单的三种呈现——所以把它认真做一次，就是全部工作。
两家商店都明确表示，SDK 的行为算你的。Google Play 说数据收集 “includes data collected and handled through any third-party libraries or SDKs used in their apps”（译：包括通过其应用中使用的任何第三方库或 SDK 收集和处理的数据）。Apple 要求你说明 “you or your third-party partners collect”（译：你或你的第三方合作伙伴收集）的数据。
第 1 步——找出每一个 SDK
阅读文件，不要凭记忆：
| 平台 | 文件 |
|---|---|
| Android | build.gradle / build.gradle.kts、libs.versions.toml、AndroidManifest.xml（权限、meta-data） |
| iOS | Podfile、Package.swift、*.pbxproj、Info.plist（用途说明字符串）、*.entitlements |
| Flutter | pubspec.yaml |
| React Native / Expo | package.json、app.json |
把那些不是你选择的传递依赖也算进去：一个引入了广告库的 SDK，会收集那个广告库收集的东西。
第 2 步——阅读每家供应商自己的披露
大多数正规供应商都会发布一个页面，明确说明它们的 SDK 发送了什么，因为它们的客户在填写这些表单时同样需要。那个页面——而不是博客文章，也不是论坛回答——才是你的来源。
Firebase 是一个实例，因为 Google 发布了按产品划分、并对应到 Apple App Privacy 类别的明细：
| Firebase 产品 | 根据 Google 文档，它收集的内容 |
|---|---|
| Analytics | 应用实例 ID、用户属性、事件、IP 地址 |
| Crashlytics | 崩溃时的堆栈跟踪和应用状态、设备和系统信息，以及你附加的任何自定义键、日志和用户 ID |
| Cloud Messaging | 与应用安装 ID 关联的推送令牌；设备型号、语言、时区、系统版本、应用标识符和版本 |
| Authentication | 它生成的标识符，以及来自你启用的登录提供方的邮箱地址、电话号码和显示名称 |
| Performance Monitoring | 启动时间、网络延迟等性能指标，设备和系统信息，用于地理分组的 IP 地址 |
| Remote Config | 国家和语言代码、时区、系统版本、应用和 bundle 标识符 |
如果你用 Crashlytics，请把这张表读两遍：最后一列有一部分是你自己造成的。你附加到崩溃报告中的自定义键和用户 ID，是你选择发送的数据，它们应该用你自己的话写进你的政策。
其他公布了披露信息、值得直接去查的供应商：广告网络（AdMob、AppLovin、Unity、ironSource）、归因工具（AppsFlyer、Adjust）、错误报告（Sentry、Bugsnag）、购买（RevenueCat、Adapty）以及身份验证提供方。
第 3 步——当供应商什么都不公布时
这种情况确实存在，尤其是较小的库。这时：
- 查看网络流量。让应用经过代理运行，看看 SDK 发送了什么。这是唯一无可争辩的方法，一个下午就能把问题弄清楚。
- 阅读源代码，如果它是开源的。
- 以书面形式询问供应商，并保留回复。
- 考虑移除它。一个没人愿意说明其数据行为的依赖，是你为了别人的方便而背负的隐患。
第 4 步——把清单变成三份文件
一份清单，三种呈现，按以下顺序：
- 隐私政策——类别、用途、具名的第三方、保留期限、联系方式。
- Play Console 中的 Data safety 表单——同样的事实，以勾选框的形式呈现。
- App Store Connect 中的 App Privacy——同样的事实再来一遍，使用 Apple 的类别。
根据清单填写它们，绝不要互相照抄。两者不一致时，商店相信的是 SDK：Google Play 表示 “when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action”（译：当 Google 发现你的应用行为与你的声明不一致时，我们可能会采取适当措施，包括执法措施）。
保持它的准确性
让这三份文件同时失效的事件总是同一个：某个依赖变了。在你的发版检查清单里加一行——这个版本有依赖变化吗？如果有，重新检查政策和两份表单——因为两家商店都要求它们保持准确，而不只是上线时曾经准确。
AppFoyer 在这里做什么
我们的代理自动化的正是这套方法。把一个编码代理指向你的代码仓库，它会读取这些依赖文件，把找到的内容与已知 SDK 的映射表进行匹配，并起草一份写明它所找到的第三方的隐私政策——同时报告每个事实来自哪个文件和哪一行，让你可以核查，而不是只能信任。没有代理的话，一个简短的表单会问同样的问题。
它产出的是一份由你审阅的草稿。它看不到自己不认识的库，而且没有你的点击，它绝不会发布任何内容。
权威来源
- Privacy and security in Firebase 和App Store data collection —— Google。上面的表格出自这些页面；它们才是权威，而不是本页。
- Provide information for Google Play’s Data safety section — Google Play 管理中心帮助
- App privacy details on the App Store — Apple