Android 联系人权限将如何变化：MANAGE_CONTACTS 与迁移指南

Android 联系人访问方式正在变化，这会影响应用开发、Google Play 政策审核以及用户看到的隐私选择。Google 于 2026 年 10 月 21 日宣布，面向下一代 Android 的应用将不能再默认使用 WRITE_CONTACTS 直接写入联系人。大多数应用应改用标准联系人 Intent，或使用权限更窄的系统界面。

这项变化很容易被误解。它不是禁止所有联系人功能，也不意味着现有应用会在一夜之间失效。核心转变是：从可以在后台广泛修改地址簿的权限，转向由用户发起和确认的操作——新增联系人、编辑联系人、让用户选择联系人，或通过系统目录展示应用内的通话和消息能力。提前迁移可以减少权限提示，让应用更容易通过审核，也能避免在开始面向新 Android 版本时临时返工。

快速结论：多数应用不应再直接写入联系人

如果用户要求应用保存名片、添加电话号码或编辑某个联系人，推荐使用 ACTION_INSERT、ACTION_EDIT 或 ACTION_INSERT_OR_EDIT 等标准联系人 Intent。这些流程会打开系统编辑器，在运行下一代 Android 的设备上不需要广泛的联系人写入权限。

如果应用只需要用户选中一个人，应使用 Contact Picker。如果通话或消息应用想提供“使用某应用通话”或“使用某应用发送消息”，应研究 People Directory，而不是向用户地址簿添加额外条目。MANAGE_CONTACTS 应只用于确实需要广泛、直接管理联系人的应用，例如专业联系人管理器、拨号器替代品、备份恢复工具。详情可阅读 Android Developers 官方公告 和 常用 Intent 参考。

为什么 Google 要替换广泛的联系人写入权限

旧模式把一次性的用户请求和持续维护整个地址簿几乎当成同一个权限问题。一个只想保存一条联系人的应用可以申请 WRITE_CONTACTS，但这个权限也可能允许它在后台大范围修改联系人。用户很难从权限提示中判断应用究竟只做一件小事，还是需要长期高权限。

新的方式围绕用户当下的动作设计。当应用打开系统联系人编辑器时，用户可以看到即将保存的字段、目标账户和最终操作。系统保留了确认边界，同时不必把不受限制的写入能力交给应用。这与 Android 的其他隐私界面一致：完成任务需要什么就申请什么，不要把整本地址簿交给只需要一条数据的功能。

Google 也在解决可靠性问题。过去联系人 Intent 在不同设备上表现不一致，有的编辑器会丢失照片等字段，有的设备不容易找到新建联系人入口，还有的设备对返回键的行为处理不同。下一代 Android 将标准化相关新增和编辑行为，使推荐路径更容易测试和维护。

开发者应该选择的迁移路径

用 Intent 保存或编辑一个联系人

名片扫描器、聊天应用、订单应用和活动工具通常不需要广泛联系人权限。新建联系人时使用 ACTION_INSERT，用户可能要把电话号码或邮箱添加到已有联系人时使用 ACTION_INSERT_OR_EDIT，已经拥有明确联系人 URI 且用户要求修改时使用 ACTION_EDIT。

不要只测试 Intent 是否成功创建。还要检查账户选择、照片、电话号码、邮箱、取消操作、旋转以及保存后的返回结果。标准 ContactsContract.CommonDataKinds 之外的自定义 MIME 类型可能被系统编辑器忽略，因此应用需要为字段无法传递的情况准备清晰的降级方案。

用 Contact Picker 让用户选择联系人

如果应用只需要用户选择某个人，读取完整地址簿就是过度访问。Android 17 起提供的 Contact Picker 允许用户选择联系人，而无需广泛权限。邀请、支付、共享行程和拼车等功能通常只需要一个用户选择的人，而不是整个联系人数据库。

这不仅有隐私好处，也改善产品体验。选择器在用户做出选择的时刻说明应用为什么需要联系人信息，比在用户理解功能之前先弹出一个宽泛权限请求更容易获得信任。

用 People Directory 展示应用内可达性

通话和消息应用有时会向联系人中写入额外条目，让用户看到“使用某应用通话”或“使用某应用发送消息”。Google 计划在 2026 年第四季度的 Android QPR2 引入 People Directory，为这类信息提供更合适的位置。应用可以发布用户如何在应用内联系彼此，而不是修改用户的私人地址簿。

这种分工更清楚：联系人应用保存个人地址簿，People Directory 描述应用能力。团队应跟踪 QPR2 的可用性，并在支持的设备上测试集成，再移除旧的兼容方案。

什么时候才应该申请 MANAGE_CONTACTS

MANAGE_CONTACTS 是特殊应用访问权限，不是普通运行时弹窗。用户需要在 设置 > 特殊应用访问权限 > 管理联系人 中开启。对于符合条件的应用，它包含读取能力，因此不一定还要同时申请 READ_CONTACTS。

它适合核心功能就是管理联系人的应用，例如联系人管理器、拨号器替代品、会批量更新地址簿的来电识别或骚扰拦截工具、企业同步、批量备份恢复以及设备换机工具。仅仅想保留自定义联系人编辑界面，并不能成为申请广泛权限的理由。

一份可执行的迁移清单

1. 搜索 WRITE_CONTACTS、直接 ContentResolver 写入、自定义联系人行和 Play 政策声明。
2. 把功能分类为新增、编辑、用户选择、应用内可达性或广泛联系人管理。
3. 用 ACTION_INSERT、ACTION_EDIT 或 ACTION_INSERT_OR_EDIT 替换单联系人操作。
4. 能使用 Contact Picker 的场景不要读取完整地址簿。
5. 用 People Directory 评估应用内通话和消息入口。
6. 只有核心功能确实要求广泛管理时才保留 MANAGE_CONTACTS，并写明理由。
7. 在新 Android 和旧版本上测试取消、不完整数据以及权限边界。
8. 确认 Manifest、Play 声明、隐私政策和应用内说明描述一致。

如果你是 Android 用户，也可以采用同一原则：优先选择能解释权限用途、提供用户主动触发流程的应用。安装工具前，可先浏览 BTTC 的 Android 软件目录，对比官方来源、权限、版本和隐私说明。

常见问题

这会立即影响所有 Android 应用吗？

不会。直接写入限制针对面向下一代 Android 的应用。面向旧版本的应用保持当前行为，而新系统上的标准联系人编辑器可以被所有应用使用。

应用能用 Intent 删除联系人吗？

不能。Android 没有用于删除联系人的标准 Intent。用户应在联系人应用中删除，拥有合理 MANAGE_CONTACTS 权限的应用才可以直接删除。

MANAGE_CONTACTS 会取代 READ_CONTACTS 吗？

对符合条件的应用，它包含读取能力。但只读取、不修改联系人的应用仍可能合理申请 READ_CONTACTS，具体取决于真实功能。

应用还能保留自定义联系人编辑器吗？

只有符合广泛联系人管理条件时才可以。单纯想保留品牌界面并不是申请 MANAGE_CONTACTS 的理由，普通新增和编辑应优先使用系统 Intent。

结论

Android 正把联系人访问变成更明确、由用户参与的流程。多数应用的迁移路径很清楚：保存和编辑使用系统联系人 Intent，选择联系人使用 Contact Picker，应用内通话和消息入口使用 People Directory。只有真正大规模管理地址簿的产品才应保留 MANAGE_CONTACTS，并在发布前充分测试目标 SDK 变化。这样可以减少广泛权限请求，让不同设备上的行为更一致，也让用户更清楚应用能对联系人做什么。