2026年7月15日，Google Play 公布了短信与通话记录权限（SMS and Call Log Permissions）政策更新。政策截止日期表把它列在使用短信或通话记录权限组一行，截止日期是2027-01-27。已公布的变更很具体：Play 将不再允许把通过电话进行账号验证作为申请 READ_CALL_LOG 的用例。如果应用仍靠读取通话记录来确认漏接电话或闪呼 OTP，这条例外按计划将消失。KappS 这篇是政策操作说明，不能代替线上帮助页。

今天要解决的问题：查清是否有二进制或 SDK 仍用 READ_CALL_LOG 来证明来电已到达；从预览帮助里挑选不依赖敏感权限的替代方案；若这是你持有该权限的唯一理由就去掉它；并在 Play 控制台重新提交权限申报表（Permissions Declaration Form），使申报与实际上架的构建一致。请核对当前 Play 控制台帮助里的表单标签——本文只复述这三篇帮助页已经公布的内容。

Play已经公布的内容（截止日期、现行页、预览页）

三份官方页面用不同篇幅描述同一截止日期：

改清单之前，把两篇政策对照着读。默认短信 / 电话 / 助理处理程序规则保持不变。其他例外行也还在，包括银行或经纪应用中的基于通话的身份验证与授权。被拿掉的是「通过电话进行账号验证、靠读取通话记录确认来电」这一行——不是表里所有与通话相关的例外。

现行页和预览页都仍把下面这项列为无效用途：通过广泛访问短信或通话记录权限来做账号或设备认证。截止日期之后，仍依赖 READ_CALL_LOG 的漏接/闪呼 OTP 会落入这一无效类别，除非你已迁到已公布的替代方案。

第一步：判断你是否用 READ_CALL_LOG 做漏接/闪呼 OTP

不要先打开控制台，先看二进制和每一条合并进来的库。Play 准备删除的例外原文是：设备可通过拨出一通电话来验证；通过核对通话记录中的号码来确认已接到该来电。现行页上对应的合格权限是 READ_CALL_LOG。

这就是漏接电话 / 闪呼模式：后端拨出（或让用户等待）一通短促来电，然后应用读取通话记录，证明设备接到了那个号码。只要功能、SDK 或「验证服务商」仍这样做，你就落在2027-01-27截止的那条例外上。

核对真实产物，不要只看商店文案：

  1. 在合并后的清单以及依赖库清单中搜索 READ_CALL_LOG（以及仅为该流程添加的其他通话记录组权限）。
  2. 在代码和 SDK 文档中搜索与注册、登录、设备绑定或 OTP 绑定的通话记录查询——而不是默认拨号器或仍保留的其他例外。
  3. 问清楚产品是靠读通话记录确认「电话打进来了」，还是银行/经纪应用里那种预览页仍单独列出的基于通话的身份验证与授权。
  4. 用户拒绝 READ_CALL_LOG 后，注册还能不能走通？如果唯一路径就是通话记录，说明你还没有不依赖敏感权限的后备方案。
  5. 该功能是否出现在 Play 商店列表里？现行页和预览页都写明：只有在用途属于允许范围、且为了实现关键核心功能时，才可访问通话记录或短信权限；商店描述应显著说明该核心功能。

不要把这项检查和默认处理程序身份混为一谈。已主动注册为默认短信、电话或助理处理程序的应用仍走处理程序表格——必须先成为已注册的处理程序，才能提示用户授予这些权限；不再是默认处理程序时必须立即停止使用。这条路径没有改。本教程针对的是靠通过电话进行账号验证例外持有 READ_CALL_LOG 的应用。

也不要把仍保留的银行/经纪行当成闪呼 OTP 的改名。预览页保留「银行或经纪应用中的基于通话的身份验证与授权」，适用于为自身服务提供安全的基于设备的金融交易的银行或经纪应用。若你不是这类产品，不要申报这一行，来继续为注册 OTP 读取通话记录。

第二步：选择不依赖敏感权限的替代方案

政策截止日期页和预览页的「替代方案」指向同一组工具。Play 写明的目标是：在不要求敏感应用权限的情况下验证账号。已公布的选项如下——不要自行发明额外 API：

  1. Digital Credentials API——预览页推荐的、在不要求敏感应用权限的情况下安全验证手机号的方案，可直接使用，或通过基于该 API 的验证服务商。政策截止日期页用同样措辞描述账号验证。
  2. SMS Retriever API——自动完成基于短信的用户验证，无需用户手动输入验证码，也不要求额外应用权限。若 SMS Retriever 不适用，现行页和预览页都写明用户也可以手动输入验证码。
  3. Incoming Call Retriever API——仅出现在预览页（截止日期后的文章）。Play 写明可通过来电完成手机号验证。应用只能访问验证所需的那一个来电号码，且号码须落在应用提供的指定号码段内。这就是 Play 描述的、在不再申请广泛通话记录权限的情况下仍用来电验证的路径。

只从这些页面公布的方案里选。一个仍读取整本通话记录的闪呼 SDK，并不等于迁到了 Incoming Call Retriever。预览页的要点是：访问范围限定在指定号码段——不再需要广泛的通话记录权限。

同一张表上的其他替代方案不能顶替这项 OTP 工作：SMS Intent（发起短信）、Share Intent（分享或邀请）、Dial Intent（打开电话应用拨号，且不需要 CALL_PHONE）。它们只用于 Play 指定的用途，不能代替账号验证。

如果供应商仍让你为「通过电话进行账号验证」保留 READ_CALL_LOG，这句话正好对应 Play 正在删除的例外。替换该流程，或替换该供应商。

第三步：去掉权限并更新权限申报表

现行政策和预览页都写明：若应用不符合通话记录或短信权限的资格，必须从应用清单中移除这些权限。验证功能迁走之后，从应用清单以及任何仅为闪呼 OTP 而合并进来的库里去掉 READ_CALL_LOG。

然后更新控制台。官方要点如下，不额外编按钮：

  1. 若你仍符合允许用途或仍保留的例外，必须直接通过 Google Play 控制台申报任何通话记录或短信权限。
  2. 不符合政策要求、或缺少权限申报表（Permissions Declaration Form）的应用，可能被移出 Google Play。
  3. 若你改变了应用使用这些受限权限的方式，必须再次提交权限申报表，并提供更新、准确的信息。欺骗性或未申报的权限使用，可能导致应用被暂停和/或开发者账号被终止。

迁离闪呼 OTP，就是改变了权限用法。即使新构建不再申请 READ_CALL_LOG，也要重新提交，以免 Play 仍按一份声称「通过电话进行账号验证」的表单来审你。若你保留通话记录或短信权限的真实理由是预览表里仍在的其他例外（备份、来电显示、配套设备等），新表单必须写那个用途——不是已删除的 OTP 例外。

本文不编造控制台菜单路径或问卷标签，只用 Play 公布的名称：权限申报表。以你账号里实际出现的标签为准，并重读该表单链出的现行帮助。

旧 APK：两篇文章仍描述一条狭窄的政策例外——针对你已无法改代码、且在2019年1月1日之前发布的 APK。在同一张表的APK Exceptions字段填写这些版本号，向 Android Oreo（API 26）及更高版本的用户提供另一套合规 APK，且申请例外的 APK 只能占安装量的极小比例。这条路径不能用来继续向当前用户提供闪呼 OTP。

第四步：2027-01-27 之后什么会失败

Play 公布了后果。不要用坊间说法替换：

若你读完本文后，控制台又出现新的问卷，以该表单链出的现行帮助为准。本文不编造额外按钮、额外 API 类名，也不在已公布的2026-07-15（公布）和2027-01-27（政策截止日期 / 现行页横幅与预览页的生效日期）之外再发明日期。

10分钟自检清单

  1. 在每一个仍在分发的软件包（包括测试轨道）中搜索 READ_CALL_LOG。
  2. 给每一处用途打标：漏接/闪呼账号验证（即将删除的那一行）、预览表里仍保留的例外，或默认短信 / 电话 / 助理处理程序。
  3. 若持有该权限的唯一理由是通过电话做账号验证，就选择 Digital Credentials API（直接或通过基于它的服务商）、SMS Retriever API 或手动 OTP，或限定在指定号码段的 Incoming Call Retriever API。
  4. 从清单以及任何仅为该 OTP 路径存在的库中去掉 READ_CALL_LOG。
  5. 打开 Play 控制台，提交与新的权限集合和剩余用途相符的权限申报表。
  6. 确认商店列表描述的核心功能，仍与你继续申请的通话记录或短信访问相符。
  7. 在发布下一个软件包之前，重读当前的政策截止日期、现行短信/通话记录文章，以及预览页。

一句话

自2026年7月15日公布、2027-01-27截止起，Play 的短信与通话记录政策不再允许用 READ_CALL_LOG 做通过电话的账号验证；把漏接/闪呼 OTP 迁到 Digital Credentials API、SMS Retriever（或手动 OTP）或 Incoming Call Retriever，然后去掉该权限并重新提交权限申报表。

参考来源