Google Play 数据安全拒审：错的是表单，不是应用

数据安全（Data Safety）拒审在 Google Play 的各类拒审里比较特别：问题几乎从来不在应用本身，而在那张表单。更准确地说，在于你填的内容与审核方观察到的实际采集行为之间的落差。

这个落差通常存在，是因为团队里没有一个人掌握完整答案。应用自己的代码采集三样东西；分析 SDK 采集九样；广告 SDK 采集一个开发者从没看过的标识符；崩溃上报组件上传设备状态。而表单要求一个人把这些全部声明出来。

这张表是"声明"，不是"开关"

这是首先要建立的认知。填写数据安全部分不会改变应用行为、不会限制任何 SDK、也不会关掉任何东西。它是一份关于已经存在的行为的书面陈述，并且会原样公示在你的商店列表上。

由此有两个推论。第一，表单不准确本身就是违规，与主观意图无关——"我们不知道那个 SDK 会这么干"是解释，不是抗辩。第二，除非表单确实填错了，否则你没法只靠改表单来消除不一致；如果应用真的采集了那样东西，准确的声明就是包含它的那一版。

几乎所有拒审都源于同一种不一致

审核方会拿你的声明去对照可观察的行为：审核期间的网络流量、安装包里检出的 SDK、申请的权限、以及你填的隐私政策链接。

拒审通知通常会点名它认为你未声明的那个具体数据类型——设备标识符、粗略位置、应用活动、已安装应用列表。这个名字是整封通知里最有用的东西，它告诉你该去审哪个子系统。

高频形态：

• 表单填"不采集任何数据"，而构建包里存在分析或广告 SDK。任何一个主流广告或归因 SDK 在包里，就几乎必然至少采集设备标识符或广告标识符。
• 数据声明为"采集"但未声明为"共享"，而 SDK 实际把它传给了第三方。采集与共享是两项独立声明，大量表单正是栽在这个区分上。
• 隐私政策与表单自相矛盾——常见原因是政策写在后面、或由另一个人写、或写的是网站而不是应用。
• 声明的用途比实际用途窄：一个实际用于广告或个性化的标识符，被声明成"应用功能"。

怎么搞清楚应用到底采集了什么

三种方法，可靠性递增：

读 SDK 文档。 每一个主流的分析、归因、广告、崩溃上报 SDK 都会发布数据采集说明，很多还直接给出对应 Play 表单的映射表。这是最快的路径，覆盖大多数情况。特别注意默认行为——很多 SDK 在你不显式关掉时会采集更多。

盘点依赖。 列出构建里的每一个第三方依赖，包括被另一个 SDK 间接引入的传递依赖。归因和聚合广告 SDK 经常打包别的 SDK。你没有直接添加的那个依赖，责任同样算在你头上。

观察流量。 在干净设备上挂代理跑应用，看首次启动、同意之后、以及正常使用期间到底有什么离开了设备。这是唯一能抓到"SDK 行为与文档不符"的方法，也是与审核方所做的事最接近的方法。

被拒之后的第一次重提，三种方法都做一遍。代价是一天；同一个原因第二次被拒的代价高得多——同一点上反复失准，会开始显得像是故意的。

那些经常填错的声明项

可选 vs 必需。 只有当用户拒绝提供后应用仍能正常运作，这项数据才算"可选"。如果拒绝就用不了那个功能，它就是必需的。

采集 vs 共享。 把数据发给一个会为其自身目的处理它的第三方 SDK，属于共享；发给一个纯粹作为你的处理方的服务，可能不属于。这个区分要逐个 SDK 判断，不要一个答案套所有。

临时处理。 仅在内存中处理、从不离开设备存储的数据可以排除——但前提是它真的从不被传输或留存。这个豁免被援引的频率，远高于它实际成立的频率。

账号删除。 如果应用支持创建账号，你必须提供请求删除的路径，包括一条不需要安装应用的网页路径。缺失或仅限应用内的删除路径本身就是一条独立的拒审原因，而且经常与数据安全拒审一起出现。

传输加密。 声明这一项，要求它对全部传输数据为真，包括你那些第三方 SDK 发出去的。

广告与归因 SDK 是常见元凶

如果你的应用靠广告变现、或者要衡量获客效果，标识符这个问题就绕不开。广告 ID、安装来源（install referrer）数据、用于归因的设备信号，都是被采集的数据，通常也确实共享给了 SDK 厂商，而且它们的真实用途是广告或分析，不是"应用功能"。

如实声明这些不会伤到你。列表里那个数据采集摘要大多数用户根本不会展开，而绝大多数已上架应用声明的是同一批类别。真正伤人的，是一份审核方花十分钟抓包就能证伪的"干干净净"的声明。

是改表单，还是改应用

搞清楚真实行为之后，你有两个诚实的选项：

如实声明。 通常是正确答案。更新表单，把隐私政策对齐到与表单说同一件事，然后重提。

改掉应用采集的内容。 适用于那些非有意或非必要的采集——某次实验留下没删的 SDK、申请了却没用的权限、没人复核过的默认配置。移除或重新配置它，验证流量确实停了，再按新行为声明。

不可选的做法是：声明你打算以后才有的行为。表单描述的是你此刻提交的这个构建。

重新提交

更新数据安全部分，确认隐私政策与之一致，提交构建。如果拒审点名了某个具体数据类型，确保你的重提可见地处理了那个类型——要么现在声明了它，要么它确实不再被采集。

通用的读通知与重提机制与其他拒审相同，怎么读懂 Google Play 拒审原因并重新提交 讲的是共通部分。另有两个相邻政策面经常在同一轮自查里一起出现：欺骗行为政策到底管什么 与 垃圾内容下架背后的四种违规。

常见问题

我明明不采集任何数据，为什么会因数据安全被拒？ 几乎总是因为构建里的某个 SDK 在采集。分析、广告、归因、崩溃上报 SDK 是在替你采集，它们采集的东西需要由你来声明。

多声明一些数据采集，会不会影响安装量？ 没有有意义的证据表明会。数据采集摘要藏在列表里需要点开一次才看得到，而几乎每一个同类应用声明的类别都差不多。

广告 ID 算被采集的数据吗？ 在它离开设备时算。通常声明为设备标识符，通常与 SDK 厂商共享，且用途通常是广告或分析，而不是应用功能。

应用需要一份单独的隐私政策吗？ 你需要一份准确描述这个应用的政策。一份从不提及应用 SDK 或标识符的网站政策，会与你的表单相互矛盾，而审核方确实会去读它。

能不能只改表单、不出新包就解决？ 有时可以——如果表单填错了而应用行为本身可接受，改正声明加上对齐的隐私政策就够了。如果修复需要移除某个 SDK，那就必须出新包。

一句话版本

数据安全拒审是声明不一致，不是代码缺陷。通知会点名它认为你漏掉的数据类型；用三种方法审那个子系统——SDK 文档、依赖盘点、实际抓包——然后要么如实声明，要么改掉应用，让如实声明变得更短。把隐私政策与表单对齐，因为审核方会对照着读。另外，除非构建里每一个 SDK 都成立，否则不要声明"临时处理"和"传输加密"。