H4.09.1per-contact access instead of full address book设计
通讯录访问应尽量提供联系人级别的选择而非全量授权
别名: 联系人级选择 · 全量通讯录 · limited contacts · contact picker
概念解释
邀请一位好友、填一个电话，人需要的是那几个联系人，不是整本通讯录。应优先用系统联系人选择器或「选取要分享的人」，让应用只拿到被点名的条目。一上来申请「允许访问通讯录」是全量授权：姓名、号码、关系、备注一次交出去。这条谈通讯录的选择粒度，不是相册，也不是把通讯录上传做好友匹配时服务器怎么留存。
机制
通讯录是一张高敏感的社会图，条目之间的关系比单个号码更值钱。全量授权的工程理由是「方便以后再找人」；对人，这是为一次邀请预付了整张图的代价。选择器把能力关在系统界面里：应用只获得结果行，没有枚举整表的 API。粒度失败时，拒绝全量的人连「选一个号码」都做不成，功能被绑在最宽的那一档上，通过率与隐私同时变差。
边界
设备管理、紧急联系人同步、用户明确要求「备份整本通讯录」的工具，全量是任务本身，应在说明里写「将读取全部联系人」并允许以后撤回。系统没有联系人选择器的旧平台，可退回为「手动输入号码」加可选的全量，而不是把全量当唯一入口。企业通讯录目录与个人通讯录不是同一张表，选人界面要标明来源。
怎么落地
- 默认入口是系统联系人选择器或可搜索的「选人」；产品路径在只需要少数条目时不请求全量通讯录权限。
- 需要多人时允许连续点选或一次多选，而不是因此升级成全量。
- 全量请求单独放在「同步 / 备份 / 匹配全部好友」这种真正要遍历的功能上，并写明将读取整本。
- 验证：完成「邀请一位好友 / 填一个电话」后，系统设置里通讯录权限应为未授权或仅所选。若变成全部访问，入口选错。拒绝全量后，选择器路径仍应可用。