如何通过Google People API获取「其他联系人」的完整信息？

接口能力硬约束说明 #

首先需要明确两个无法通过参数配置绕过的服务端规则：

• otherContacts 系列所有接口（list、search）的返回字段限制是服务端硬编码逻辑，readMask参数仅支持emailAddresses、names、phoneNumbers三类字段，传入其他字段会直接返回参数错误，不存在调优空间。
• 「其他联系人」的资源命名空间与普通联系人完全隔离，接口返回的otherContacts/{id}格式的resourceName无法直接通过people.get接口查询，这类跨命名空间的查询会直接返回资源不存在的错误，是底层存储隔离逻辑决定的。

无永久数据污染的最优实现路径 #

基于上述约束，可在不产生用户可感知的通讯录变更的前提下，实现全量字段获取：

• 头像类字段无写入替代获取
  Google Contacts网页端展示的其他联系人头像，本质是基于联系人的邮箱/手机号，从Google账号体系实时拉取的用户公开资料头像，并非存储在「其他联系人」实体中的属性。拿到基础的邮箱、姓名字段后，可直接通过账号公开资料接口匹配对应头像，全程无数据写入操作，不会对用户通讯录产生任何影响，也不会返回姓氏首字母占位图。
• 全量属性的短窗口闭环操作
  目前公开API没有开放无写入前提下拉取其他联系人全字段的能力，可通过毫秒级窗口的临时操作实现无感知获取：
  • 分页拉取「其他联系人」列表的基础字段
  • 对需要拉取全量信息的条目，调用copyOtherContactToMyContactsGroup接口完成临时复制
  • 同步拉取该临时联系人的全量字段（包含地址、组织、生日、封面图等）
  • 拉取完成后立刻调用people.deleteContact接口删除临时生成的联系人
    整个流程的写入-删除操作窗口极短，用户完全无法感知通讯录的临时变动，也不会产生永久的存储占用。针对调用过程中易触发的每分钟180次调用限额问题，可通过提前申请更高接口配额、按分页大小批量预拉取的方式降低QPS压力，规避限流触发。
• 原分组中转方案的修正
  曾设计的自定义分组中转方案无法落地，核心是contactGroups.members.modify接口仅支持向系统内置分组添加成员，实际上不需要额外创建自定义分组做中转，临时复制到「我的联系人」分组后直接拉取字段、随即删除即可，不需要走分组成员修改的接口逻辑，整个操作链路比原设计方案缩短近1/3。

内容的提问来源于stack exchange，提问作者android developer