2026年Play年龄信号API教程

年龄验证的责任已经从应用搬到了商店。德州 SB 2420 已生效，巴西 Digital ECA 自 2026 年 3 月 17 日起开始下发年龄信号，Google Play 现在直接给开发者一个过去只能猜的答案：这个用户多大。Play Age Signals API（beta）就是拿到这个答案的客户端入口。本文按不会导致重写的顺序，把接入过程走一遍。

先把定位说清楚：Google Play 并不强制使用这个 API。是各地的法律给在这些辖区发行的应用加了义务，Google 提供工具，是否使用、怎么使用由开发者自己决定。这个决定要写下来——留痕比事后回忆群聊可靠。

三个带日期的事实，全部来自 Google 官方文档，决定了这次接入的范围：

• 德州。App Store Accountability Act（SB 2420）已在联邦上诉法院中止 2025 年 12 月的初步禁令后生效。对符合条件的用户，Google Play 会为 2026 年 5 月 28 日之后创建的账号返回年龄信号，并承诺在其他美国州的年龄验证法案生效前提前给出更新（Play Console 帮助）。
• 巴西。自 2026 年 3 月 17 日起，API 开始为巴西用户返回年龄信号，对应 Digital ECA 的要求（Age Signals 概览）。
• 义务怎么分。商店负责验证，家长负责审批，开发者要接收年龄区间与重大变更的家长审批状态，并在发生重大变更时通知商店。Google 在 FAQ 里写得很直白：Play 不要求必须使用这个 API，法律要求的是「适龄体验」。

换句话说，API 解决的是最难的那部分——你自己验证出生日期，就意味着要收集一堆你并不想持有的身份数据；剩下那部分才是你能控制的：13-15 档和 18+ 档的用户，应用到底有什么不同。

客户端库是 com.google.android.play:age-signals，Google 建议使用最新版 0.0.4。支持的设备形态是手机、折叠屏与平板，系统要求 Android 6.0（API level 23）及以上。在 app 模块里加一行：

• implementation 'com.google.android.play:age-signals:0.0.4'

两个容易漏掉的约束。第一，这是客户端运行时API：年龄信号在应用打开时取，不会推到后端，所以任何服务端门禁都得由 App 取得结果后再决定怎么传。第二，使用即表示你接受其服务条款，并承诺遵守 Google Play 开发者政策。

上来就调 checkAgeSignals() 是最常见的错误。必须先用 requestAgeSignalsAccess(activity) 确认共享状态，它只返回三种值，每种对应不同界面：

• SHARED — 可以读取年龄信号。覆盖在符合条件的自动共享地区完成验证或自报年龄的成年人，以及由家长共享年龄的受监护未成年人。
• NOT_SHARED — 用户或家长拒绝共享。走你的兜底体验，禁止循环弹窗。
• VERIFICATION_REQUIRED — 在适用的美国州，用户必须先到 Play 商店完成验证才会有信号。把用户引导过去，并保证返回时请求是幂等的。

地区行为是刻意不同的。在要求用户选择的市场（例如欧盟、英国、巴西），用户可选「询问后再共享」「始终共享」「绝不共享」；选「询问后再共享」时由 Play 渲染内置的应用内提示。在适用的美国州完全没有应用内提示——验证由 Play 商店完成，调用只会返回 SHARED 或 VERIFICATION_REQUIRED。受监护账号的共享由家长在 Family Link 里管理。如果用户关闭了提示，Play 会再弹几次然后抑制——所以把 NOT_SHARED 做成硬阻断是产品决策，不是技术默认值。

checkAgeSignals() 返回的字段决定你的分支逻辑（响应字段说明）：

• ageLower / ageUpper — 年龄区间的闭区间上下界。默认档位为 0-12、13-15、16-17、18+；最高档不设上界，ageUpper 为 null。
• ageRangeSource — TIER_A 自报；TIER_B 家长/监护人管理；TIER_C 通过信用卡、邮箱、自拍评估、政府证件或税号评估；TIER_D 政府证件加自拍评估，或 Digital ID。把它当作可信度等级，和分支一起记录。
• significantChangeStatus / significantChangeApprovalDate — APPROVED、PENDING、DECLINED，在不适用该辖区的场景返回 null。
• installId — 分配给受监护安装，用于「应用授权被撤销」的通知。

坑在这里：上下界为 null 不等于未成年。已完成验证的成年人同样返回双 null；状态为 NOT_SHARED 或 VERIFICATION_REQUIRED 时也是双 null。如果把 null 映射成「受限」，你会把付钱的成年人挡在门外。正确顺序是先判状态、再判区间，并把 null 区间视为「未知，走默认档」，除非状态另有说明。

默认档位很少和真实产品规则对得上。在 Play Console 的 Age signals 页面，Custom age ranges 标签页最多可填三个最小年龄；相邻最小年龄至少相差两年，且每年只能修改一次。只设一个 15：0-14 岁用户返回 ageLower=0, ageUpper=14，15 岁及以上只返回 ageLower=15。设 13 和 17，就得到 0-12、13-16、17+ 三档。

因为一年只能改一次，保存之前就要把档位和产品规则、商店页承诺对齐。事后调整属于变更申请，不是随手改个配置。

「重大变更」由你定义，不由 Google 定义。当你上线了新的社交功能、改了数据共享方式、新增了付费入口，就到 Play Console 的 Age signals 页面通知 Play——不需要发布新版本。家长随后批准或拒绝，你通过 significantChangeStatus 读取结果。Play 明确说明：家长拒绝时它不会撤销应用访问或下架应用，后果由你自己定义；授权被撤销的通知链路走 installId。

德州还有一条和钱相关的独立要求：内购商品可能需要单独标注年龄分级，与应用的內容分级是两件事。可以在 Play Console 或通过 Publishing API 设置，Play 会在德州用户的 Play Billing 购买审批流程里展示该分级。把 SKU 分级写进发布清单，别当补丁——一个跳过这一步的购买流程，最后不是以崩溃形式暴露，而是以合规问题的形式暴露。

错误表实质只有两组。可重试：-1 API 不可用、-2 找不到 Play 商店、-3 无网络、-4 Play 服务缺失、-5 绑定服务失败、-6 Play 商店版本过旧、-7 Play 服务版本过旧、-8 客户端瞬时错误。不可重试：-9 应用不是从 Google Play 安装、-10 SDK 版本不再支持、-100 内部错误（携带 API 名称联系 Play 开发者支持）。

第一组用有上限的指数退避重试并给出可操作提示（更新 Play 商店、检查网络）。第二组直接落入默认体验并记日志——对 APP_NOT_OWNED 反复重试只浪费电量。侧载的包永远会落在这里，这也是测试必须用官方提供的假管理器、而不是手装 APK 的原因。

这里常被混淆两个数据问题。Play Age Signals 客户端库本身不收集数据、也不向第三方共享，年龄信号由 Play 商店在设备上处理。但你在读到这些值之后怎么用，完全由你负责，风险也在这里：写进隐私政策，保留期限只留够支撑适龄体验的部分，不得把信号用于广告、画像或分析——条款把用途限定在「提供适龄体验」，滥用会终止 API 访问权限，并让应用本身承担风险。

Google 还建议同时调用 Play Integrity API，避免被篡改的安装包伪造响应。接入时顺手加上成本很低，出事之后再补代价很高。

上线前自查：三种共享状态都处理了、null 区间没有被当成未成年、自定义档位与产品规则对齐、重大变更通知有明确责任人、德州内购 SKU 分级已设、可重试错误有上限、隐私政策已更新、Play Integrity 已评估。八项，商店一项都不会替你验证。

来源：developer.android.com 上的 Play Age Signals API 文档（概览、接入、响应字段、错误处理）与 Play Console 帮助中关于美国各州应用商店法案的说明，均于 2026-10-23 核对。Google Play 未公布执法阈值或逐应用的合法性判定，本文不做推断。