当你的 Data safety 表单与隐私政策不一致时
同一个 App 的两份声明，会被放在一起对照，却往往相隔数月写成。它们各是什么、在哪里出现偏差，以及如何从依赖列表出发让两者一致。
它们是对同一个 App 的两份描述，商店会把它们放在一起看，所以不一致本身就是问题。应当从 App 本身出发来修正，而不是以其中任何一份文档为准：列出构建中的每个 SDK，写下每个 SDK 发送什么数据，然后根据这一份清单填写表单并重写隐私政策。
几分钟就能搞定
AppFoyer 托管本指南所讲的页面——隐私政策、服务条款、支持、账号删除和 app-ads.txt——放在它们自己的子域名上，你无需自己的域名或服务器。一个应用免费，而且商店要求的任何内容都绝不放在付费墙后面。
核查于 2026年9月19日。 商店政策会变，有时不会事先通知。下文所有内容都链接到官方文档，以那个页面为准，而不是本页。如果两者不一致，以商店为准。 本指南译自英文；引用的商店文档保留英文原文。
你的 Data safety 表单和隐私政策是对同一个 App 的两份描述，商店会把它们放在一起看。两者不一致时，问题在于不一致本身，而不在于哪一份恰好写错了。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 发现你的 App 行为与你的声明不符时，我们可能会采取相应措施，包括执法措施。）
Apple 的结构相同，只是名称不同：产品页上的 App Privacy 详情，加上必须提供的隐私政策 URL。
本页讲的是如何让这两者保持同步，以及它们都要接受核对的第三样东西：你的 App 实际上做了什么。
两份文档简介
Data safety 表单（Play Console → App content）和 App Privacy 详情（App Store Connect）是结构化的声明：勾选框和分类，在你的商店页面上呈现为一份摘要，用户在安装前会读到。它们是对一份固定问卷的回答。
隐私政策是托管在你自己 URL 上的一段文字。它用句子讲同样的事情，外加问卷里没有对应选项的内容——你的法律依据、数据保留期限、联系方式、如何申请删除。
两者不能互相替代。一份政策不会替你填好表单，填完的表单也不代表你的政策准确无误。
两者在哪里出现偏差
它们相隔数月写成。 隐私政策在上线那一周写好。表单在提交当天由某个人对着依赖列表填写，之后没有人回头去改政策。
引入了新的 SDK。 你在某个迭代里加了一个崩溃上报工具。拉取请求里没有任何关于政策或表单的改动，所以两者都没变。Google Play 明确表示这也算在内：数据收集“includes data collected and handled through any third-party libraries or SDKs used in their apps… You must reflect data collection or sharing carried out by such third-party code in the Data safety form for your app.”（译文：包括通过其 App 中使用的任何第三方库或 SDK 收集和处理的数据……你必须在 App 的 Data safety 表单中反映此类第三方代码进行的数据收集或共享。）Apple 的要求相同：“You need to identify all of the data you or your third-party partners collect.”（译文：你需要列明你或你的第三方合作伙伴收集的所有数据。）
功能上线了，声明却没跟上。 为”附近”功能使用位置信息，或者一个与合作方共享用户 ID 的推荐系统。工程工作大家都看得到；声明方面的工作却不在任何人的任务板上。
其中一份用了模板。 一份自动生成的政策，为一个没有广告的 App 列出了广告标识符，这和遗漏一样属于不一致——而且更容易被发现，因为它与你如实填写的表单相矛盾。
让两者一致：唯一可行的顺序
从 App 出发，而不是从任何一份文档出发。两份文档都应该描述这个 App，所以拿一份去修正另一份，只会把错误挪个位置。
- 打开你的依赖文件——
build.gradle/libs.versions.toml、Podfile/Package.swift、pubspec.yaml、package.json。列出每一个第三方 SDK。 - 为每个 SDK 写下它发送什么数据。 崩溃上报工具发送设备标识符和堆栈跟踪。分析 SDK 发送事件，通常还有广告 ID。广告 SDK 发送的则多得多。推送库会注册设备令牌。这里的依据是供应商自己的隐私文档。
- 加上你自己收集的数据——账号、上传内容、你的后端存储的任何东西。
- 检查你声明的权限和用途说明字符串，它们是另一份独立的清单，列出 App 能访问什么：
ACCESS_FINE_LOCATION、NSLocationWhenInUseUsageDescription、相机、通讯录、照片。 - 然后根据这份清单填写表单，并根据同一份清单重写政策。 两者最终一致，是因为它们来自同一个来源，而不是因为你逐项比对过。
需要保持最新的是这份清单，而不是表单。两份声明都是从它派生出来的。
之后如何保持同步
声明会悄无声息地过时，所以检查必须挂在一个不会悄无声息的事件上。Google Play 对此有要求：“Your Data safety form responses must remain accurate and complete at all times.”（译文：你的 Data safety 表单回答必须始终保持准确和完整。）Apple 同样如此：“You’re responsible for keeping your responses accurate and up to date.”（译文：你有责任让你的回答保持准确和最新。）
最省事又有效的做法是在发布检查清单里加一行——这次发布有没有依赖发生变化？如果有，重新检查政策和表单——因为依赖变化恰恰是让两者同时失效的那个事件。
本页无法告诉你的
具体哪套法规适用于你。GDPR、UK GDPR、CCPA/CPRA、LGPD 以及儿童隐私规则各自对政策有特定要求，哪些适用取决于你的用户在哪里以及你的 App 做什么。如果你的 App 有任何特殊之处——健康数据、儿童、任何你难以用一句话解释清楚的东西——那就值得花一小时咨询律师。模板（包括我们的）只是起点，不是建议。
AppFoyer 在这里做什么
我们根据在你的构建文件中找到的 SDK 起草隐私政策——可以通过读取代码仓库的编码代理，也可以通过一份简短的表单——这样政策和你给商店的回答都来自同一份依赖列表，而不是凭记忆。在列出第三方的占位符被替换之前，检查清单会一直标记这个页面，因为审核人员正是拿这一部分去和你的表单对照。
我们不会替你填写 Data safety 表单，任何服务都不能：它是你在自己的控制台里签署的声明，Google Play 说 “you alone are responsible for making complete and accurate declarations.”（译文：只有你本人对作出完整、准确的声明负责。）
权威来源
- 为 Google Play 的 Data safety 部分提供信息 — Google Play Console 帮助
- App Store 上的 App 隐私详情 — Apple
- 隐私政策要求 — Google Play 帮助