Android 17 READ_CONTACTS 政策：Contact Picker 与上架检查｜御盾

Google Play 将从 2027 年 1 月 27 日起，对 target Android 17（API 37）及以上且请求 READ_CONTACTS 的应用执行联系人权限政策。发布前先检查最终 APK/AAB；再按业务需要评估 Play 声明或 Contact Picker。御盾候选和 Play Console 申报状态未测试。

适用条件速查

读者对象

本文面向需要检查联系人相关 Android 应用最终发布包的研发、测试与发布人员；不代替具体产品的 Play Console 个案审核。

核心结论

最终 APK/AAB 的权限集合、Play Console 申报状态和加固兼容性是三项独立核查结果，不应合并成单一的“PASS”。

适用范围和政策时间线

Google Play 的联系人权限说明把政策适用条件限定为 target Android 17 或更高版本（API 37+）且请求 READ_CONTACTS。开发者应先核实实际提交版本的 target SDK 和最终权限列表，再判断是否进入声明流程。仅因为设备运行 Android 17，或项目计划未来升级 target SDK，都不能单独推断某一当前版本已经触发这项政策。

Google 于 2026 年 4 月公布联系人和位置权限政策，并在 2026 年 10 月 5 日再次提醒开发者：Play Console 中的联系人用途声明现已可用，政策将于 2027 年 1 月 27 日生效。Google 的同一提醒提到，如果开发者届时仍未完成合规准备，可以在 Console 申请一次 30 天的自动自助延期。延期只是额外准备时间，不应理解为永久豁免，也不替代声明或迁移要求。

另一个独立节点是 2026 年 10 月 27 日：Google 计划在 Play Console 提供新的预审检查，提示潜在的联系人或位置权限政策问题。这类检查是提交前的提示机制，不代表最终审核通过，也不应被描述为自动拒绝。团队应把它当作提前发现问题的信号，而不是把检查结果当成合规结论。

技术拆解：Contact Picker 适合什么场景

判断是否适合 Contact Picker，首先要看用户要完成的动作，而不是看应用是否“有联系人功能”这个宽泛标签。一次性邀请好友、选择收件人、分享文件给指定联系人、从联系人中挑选一个电话号码或邮箱，通常可以从用户主动选择出发，按实际需要请求字段。应用无需为了单次操作先读取整本通讯录。

Contact Picker 的数据范围由应用说明所需字段、用户选择和系统返回结果共同限制。例如仅发送短信的流程可以只请求电话号码字段，而不必顺带访问邮箱或其他联系人数据。Picker 支持搜索、个人与工作资料切换以及多选等能力；具体可用行为仍需按照 Android 版本与官方 API 文档进行实现和测试。

广泛访问可能适用于联系人管理、联系人备份恢复、基于全部联系人执行核心功能，或某些必须持续检查通讯录的核心体验。但“产品希望导入更多联系人”“增长团队想做社交推荐”本身不能自动证明广泛权限不可替代。Play 声明需要开发者解释哪些用户功能依赖广泛访问，以及为什么 Contact Picker 无法支撑该核心功能。最终政策判断由 Google Play 根据其现行规则作出，本文不替具体应用预判审批结果。

ACTION_PICK 需要重写吗？

不一定。Android Developers 文档说明，对 target Android 17/API 37 及以上的应用，系统会自动把现有 Intent.ACTION_PICK 升级为新的联系人选择器界面。如果应用已经使用 ACTION_PICK，仅为了获得新界面，通常不必因此全面重写现有代码。

如果应用要使用新的能力，例如在一次请求中指定多个数据字段、切换个人与工作资料，或接收单一 Session URI 后查询被选中的数据，则应评估迁移到 ContactsPickerSessionContract.ACTION_PICK_CONTACTS 及相关 extras。迁移范围取决于现有调用方式和业务所需字段；不要把“系统可以升级旧 UI”误写成“所有旧代码自动获得新 API 的全部能力”。

系统在选择完成后返回 Session URI，并给予临时读取权限。若业务需要在进程结束后继续使用所选数据，官方建议及时持久化必要的数据。团队还应明确数据保留期限、服务端同步范围、用户撤回或删除路径，以及隐私政策说明。临时授权不是允许无限期收集、复制或转作其他用途的许可。

APP 加固为什么也要查最终 Manifest

联系人政策属于平台分发与用户数据权限规则，不是加固强度指标。御盾加固不能代替 Play 声明，也不能决定某个业务是否满足“核心功能”的政策条件。另一方面，应用进入加固和发布流程后，最终提交物仍应被纳入检查：开发源码里删掉了 READ_CONTACTS，不代表所有构建变体、第三方 SDK 或最后打包的 APK/AAB 都一定不再包含该权限。

Android Gradle 构建会合并主源码集、构建变体和导入库中的 Manifest，按合并规则形成打包结果。主 Manifest、product flavor、debug/release variant、AAR 库和自动化打包配置都可能影响最终清单。若权限出现在最终产物中，第一步应对比每个阶段的合并来源，不应直接归因于加固器。

建议按下列阶段保存权限差异：

P0 业务源码 Manifest
P1 对应 variant 的 Merged Manifest
P2 Original APK/AAB 最终权限
P3 Yudun Protected Candidate 权限
P4 客户正式签名后的 Final Artifact 权限

从相邻阶段找出权限首次出现的位置，才能确定下一步调查方向。若 P0 没有权限、P1 出现，应检查构建变体或依赖库；若 P1 无权限而 P2 已出现，应检查构建、打包或产物选择；若 P2 无权限而 P3 出现，才有必要围绕该保护阶段核对输入输出和 Manifest 处理；若 P3 无权限、P4 出现，则进一步检查客户签名与最终打包流程。差异定位不是责任判定，仍需用相同输入重复确认，并排除构建配置变化。

权限发布核对矩阵

加固版本的 Permission Release Gate

对每个准备提交的发布候选，建议同时记录 targetSdk、包类型、构建变体、READ_CONTACTS 是否存在、权限首次出现阶段、依赖来源、Contact Picker 替代方案评估、Play Console 声明状态、候选摘要、检查日期和责任人。只留“源码已删除权限”的截图不足以复核最终产物；也不能把一次静态清单读取当作运行时隐私审查。

对于仍保留 READ_CONTACTS 的应用，应把业务用途写成可被审阅的具体功能，并记录为什么基于用户选择的 Picker 或 Sharesheet 无法满足该功能。对于迁移到 Picker 的应用，要检查字段是否最小、Session URI 读取与持久化是否符合业务需要、拒绝或取消后的流程是否可用，以及旧 Android 版本的兼容路径。

需要先比较两份 APK 清单时，可使用御盾本地 APK 权限清单差异比较器处理 apkanalyzer 输出，并参考权限差异检测与 Manifest Merge 排查指南定位来源；该工具不上传 APK，也不作政策合规判断。

对于同一业务版本的 Original、Basic、Target 和 Final Signed 候选，使用相同构建变体和同一权限比较规则。若某项保护策略不应改动 Manifest，就把“权限集合一致性”作为可验证的发布门禁项；若工具链确实会重写清单，则必须在提交前复核最终文件。任何结果都应绑定到具体候选与版本，而不是概括成“所有加固包权限都不变”。御盾在本页对应的 APK/AAB 与 Manifest 对照尚未执行，状态为 NOT_TESTED。

测试目标与非目标

本节定义的是发布前清单核对目标，不是已完成的御盾验证。本轮主目标是定位联系人权限从源码到最终提交物的状态，并明确需要由哪个环节继续处理；非目标包括验证某个御盾候选、代替 Play Console 申报、推断审核结论或读取真实用户通讯录。所有产品侧结果仍为 NOT_TESTED。

事实依据与脱敏证据

下表列出支撑本文政策解释的公开事实。来源是 Google Play 或 Android Developers 文档；它们描述政策和平台能力，不代表御盾已进行 APK 权限核对、完成 Play Console 申报，或取得某个具体应用的审核结果。

从政策提醒到发布决定：执行时间线

这是一条建议的工程检查时间线，不是御盾已完成的现场记录。

1. 政策确认。 读取 Google Play 当前规则，记录 target SDK 条件、权限条件、强制日期和声明要求。若 Google 后续更新页面，应按新版本复核，不能只依赖旧截图。
2. 10 月 27 日预审准备。 对候选应用执行一次 Play Console 提交前检查，将联系人和位置提示与实际 Manifest、功能说明对照。保存提示与处理结论；没有提示不等于政策豁免。
3. 权限来源定位。 固定变体和依赖版本，从源码清单走到 Merged Manifest、Original 产物、Yudun Candidate 和 Final Artifact，记录权限首次出现阶段。
4. 最小权限决策。 若用户只需主动挑选联系人，评估 Contact Picker；如需要广泛长期访问，则准备具体用途声明和不能采用 Picker 的技术理由。不要为了通过提示而虚构功能用途。
5. 同候选回归。 对相同业务版本验证 Picker 的选择、取消、Session URI 读取、持久化和旧版本兼容。加固前后使用相同路径，避免把功能差异误判为保护影响。
6. 提交放行。 检查最终 APK/AAB 的 targetSdk 与权限，核对 Play 声明和预审提示处理情况，确认客户签名、版本号、摘要与提交文件一致。最终审批仍由 Play 作出。

权限检查记录示例（未执行模板）

下面的机器可读记录只展示字段与适用范围。因为本次没有访问御盾测试 APK、Play Console 或加固候选，所有产品侧字段均标为未测试，不应被引用为御盾功能或兼容性结论。

policy:
  target_sdk_threshold: 37
  permission: READ_CONTACTS
  enforcement_date: 2027-01-27
  play_declaration: REQUIRED_IF_PERMISSION_REQUESTED_IN_SCOPE
  pre_review_checks_from: 2026-10-27
contact_picker:
  available_on: Android_17_API_37_plus
  selected_data: USER_SELECTED_FIELDS_AND_CONTACTS
  session_uri_access: TEMPORARY
release_evidence:
  source_manifest: NOT_TESTED
  merged_manifest: NOT_TESTED
  original_artifact: NOT_TESTED
  yudun_candidate: NOT_TESTED
  final_signed_artifact: NOT_TESTED
  play_console_declaration: NOT_TESTED
  checked_at: null

若要形成真实记录，应补充应用构建变体、Manifest 来源、最终产物类型、权限差异、Picker 测试路径、Play Console 处理状态、检查时间和复核人。不要在公开记录中包含未脱敏的客户包名、签名证书、账号或用户联系人数据。

攻防视角：权限差异应从首次出现阶段定位

安全审查不应把权限数量简单等同于风险，也不应把“源码没有该权限”当作最终结论。更有效的做法是记录权限从哪个构建阶段进入产物：依赖库可能为自身功能声明权限，Manifest Merger 会根据来源和规则合并，变体配置也可能产生不同结果。先确定差异边界，再判断是否存在不必要的访问，能减少将 SDK 行为、构建变化和保护处理混为一谈的误归因。

当最终包出现业务并不需要的广泛权限时，处理顺序应是确认功能依赖、检查合并来源、向 SDK 提供方核实配置，并在必要时采用官方支持的移除或替代方式。不要只为消除预审提示而机械删除权限，导致核心功能在运行时失败；同样也不要因加固候选能启动，就推断权限用途已符合商店政策。

工程落地：把权限检查放进最终发布门禁

执行时应固定业务版本、构建变体和依赖版本，将源码 Manifest、Merged Manifest、Original 产物、保护候选及正式签名产物逐一关联。每个差异都应记录来源、复核人和时间；若权限在某阶段首次出现，先检查该阶段的合并输入与构建配置，不直接把差异写成工具缺陷。若应用使用 Contact Picker，还应覆盖用户选择、取消、字段最小化、Session URI 读取、必要数据保存和旧系统兼容路径。

发布记录应把政策判断与技术比对分栏保存：一栏记录 target SDK、权限及声明状态，另一栏记录产物摘要和 Manifest 差异。这样可以避免将“Play Console 提示已处理”误读为“加固兼容性通过”，也避免将“权限集合未变化”误读为“隐私政策已合规”。任何自动化门禁都应允许 UNKNOWN 或 NOT_TESTED，不能把缺失数据默认转成通过。

风险边界

本文提供的是政策与发布工程检查框架，不是法律意见、隐私审计报告或 Google Play 审批承诺。政策文档可能更新，适用条件应在每次提交时复核。Contact Picker 的行为取决于目标 Android 版本、调用方式和所请求字段；最终 APK/AAB 是否包含权限，必须针对具体构建产物读取。御盾产品侧的权限差异、兼容性和 Play 提交均未测试。

责任边界与常见误区

• 运行 Android 17 的设备不等于其上每个应用都触发政策；需检查 target SDK 和最终权限条件。
• Contact Picker 能缩小联系人数据选择范围，但不代替 Play 声明、隐私披露或审核。
• 从源码删除权限不代表最终产物中不存在；构建合并和渠道交付仍要复核。
• 加固候选发生差异不自动证明加固器是原因，应从相邻阶段定位首次差异。
• 加固负责保护应用代码和运行时；Play 政策判断及审批由平台规则和审核流程决定。

常见问题

Android 17 以后是不是完全不能再使用 READ_CONTACTS？

不是一概禁止。对 target Android 17/API 37 及以上且请求该权限的应用，需依现行 Google Play 政策提交用途声明并说明广泛访问的必要性；具体结果由 Play 审核决定。

已有 ACTION_PICK 必须迁移到新接口吗？

不一定。官方说明 target API 37+ 的既有 ACTION_PICK 会升级到新的选择器界面；需要多字段或 Session URI 等新能力时，再评估迁移到 ACTION_PICK_CONTACTS。

10 月 27 日 Play Console 预审提示代表应用会被拒吗？

不能这样推断。它用于提示潜在政策问题，不是最终审批结论，也不代表处理提示后必然通过。

加固后最终权限与源码不同，应该先找谁？

先比较源码、对应变体的 Merged Manifest、Original 产物、保护候选和最终签名产物，定位首次出现阶段；再核对 SDK、构建配置和打包流程，不要仅凭差异直接归因。

参考资料与延伸阅读

• Google Play：2026 年 10 月 5 日联系人权限政策提醒
• Google Play：具有最小范围替代方案的受限权限说明
• Android Developers：Android 17 Contact Picker
• Android Developers：Play 权限政策更新与 10 月 27 日预审检查
• Android Developers：管理 Manifest 文件与合并
• 御盾：APP 加固 PoC 验收指南
• 御盾：性能与兼容性中心