Android跨设备交互三大API：CDM、Jetpack Telecom与Quick Share

跨设备体验：从边缘场景到日常刚需

在 Android Dev Summit 的这场分享中，Hanrui、Yaxin 和 Natraj 三位工程师系统梳理了 Android 平台上跨设备交互的现状与解决方案。他们指出，连接早已不只是"蓝牙耳机连手机"这么简单——用户平均拥有三到四台设备，涵盖手机、手表、耳机、平板、折叠屏乃至 Chromebook 和车载系统。

数据印证了这一趋势：全球 IoT 设备约 220 亿台，同比增长 14%，其中 Wi-Fi 占三分之一、蓝牙占四分之一。同时，超过 40% 的通话通过 VoIP 网络进行，其中 71% 发生在 Android 设备上。每天有超过 140 亿张照片和视频在社交与消息应用中分享。这些数字说明，跨设备能力不再是锦上添花，而是 app 的基础设施。

然而，多数开发者仍依赖底层的网络与蓝牙 API 自行搭建跨设备功能，由此带来三重挑战：电池与内存开销（后台扫描和常驻服务持续耗电）、延迟不可控（实时通话与数据同步被拖累）、连接摩擦（发现、配对、重连的复杂度极易破坏体验）。针对这些问题，Android 团队在三个方向提供了专用 API。

Companion Device Manager：让蓝牙外设连接不再常驻后台

四类伴侣设备与四个核心需求

CDM 面向的是"手机 + 蓝牙外设"场景，典型设备包括医疗设备（血糖仪、生命体征监测）、可穿戴设备（手表、手环、耳机）、车载套件（数字车钥匙、免提通话）。这些场景共同依赖手机与外设之间的可靠连接，医疗设备甚至关乎生命安全。

开发者的诉求集中在四点：设备管理（在众多邻近设备中精准找到目标并配对）、存在感知（设备靠近或离开时唤醒 app）、连接维护（断连后自动重连，即使 app 未运行）、数据同步与传输（传感器读数、固件更新、设置下发）。

传统方案 vs CDM

传统实现依赖前台服务：声明蓝牙扫描与连接权限、前台服务权限及 connected device 类型、通知权限，再运行常驻服务保持进程存活。这套方案确实有效，但代价是服务始终运行——即便设备根本不在附近。

CDM 的改变在于：系统根据设备存在状态唤醒 app，设备在范围内时保持进程存活，无需前台服务；同时引入 device profile，用户一次点击即可授予 app 所需的全部权限，替代冗长的权限对话框链，显著提升转化率。手表 profile 始于 Android 12，眼镜始于 Android 14，Android 17 新增医疗设备与健身追踪器两个 profile。

代码路径与限制

以医疗设备为例：声明权限（均为安装时授予的普通权限，无弹窗）、构建带设备过滤器的关联请求、调用 associate，CDM 负责扫描；在 onAssociationPending 中启动系统关联对话框，用户点击一次即完成关联与权限授予，甚至可绕过勿扰模式——这对关键警报至关重要。获得 association ID 后调用 startObservingDevicePresence 并实现 CompanionDeviceService，设备进入范围时系统绑定服务并回调 BLE_APPEARED，离开时回调 BLE_DISAPPEARED。

分享者坦承 CDM 的局限：多数特性在 Android 12/13 落地，核心改进在 Android 16、新 profile 在 Android 17，需做版本回退；目前支持后台扫描但不支持后台广播；采用低功耗扫描模式，实时响应性有所取舍，不应期待即时唤醒；不支持 payload 预筛，无法针对特定特征或广播数据注册。鉴于内存压力持续上升，团队强烈建议 app 尽快从前台服务迁移到 CDM。

device profile 是 CDM 中按设备品类预设的一组能力与权限模板。开发者声明目标 profile（如医疗设备、健身追踪器、手表、眼镜）后，系统便知道该 app 需要哪些权限、需要感知哪类设备的存在，并在关联时一次性打包授予。这避免了逐条申请蓝牙扫描、连接、通知等权限所造成的多次弹窗，也让系统能在设备出现时按 profile 语义唤醒 app。profile 与 Android 版本绑定，新品类往往需要较新的系统版本才可用，因此跨版本仍需回退到传统权限路径。

Jetpack Telecom：把 VoIP 通话接入系统通话体系

自行搭建的三个坑

Natraj 用一个典型场景开场：用户瞥一眼手表看到来电者信息，用手表接听，插入耳机继续通话，上车后通话无缝切换到车厢音响。这已是用户的日常预期，而非高端体验。

但自行实现会撞上三堵墙。蓝牙 socket 碎片化：系统不知道你的 app 正在通话，你只能自建蓝牙 socket 与媒体会话，才能把通话投射到手表或 Android Auto。音频焦点：直接操作底层 AudioManager 与蓝牙 API 导致音频泄漏，且 VoIP 通话在系统优先级中靠后，蜂窝来电会抢占音频；更糟的是蜂窝通话结束后焦点未必归还。状态同步：手表上点了静音，手机 UI 仍显示未静音；从车机方向盘挂断，手机仍显示通话中。

注册一次，系统协调一切

Jetpack Telecom 的思路是让 app 通过 CallsManager 注册通话，由库充当系统级通话协调器：负责投射到手表、Android Auto 等远程界面，管理音频焦点，并且一路兼容回 Android 8。硬件事件（手表静音、方向盘挂断、耳机双击）统一以回调形式汇聚到 ControlScope，app 只需监听并更新通话引擎，状态同步交给库完成。

额外收益来自 Kotlin：添加通话时开启协程作用域，恰好存活至通话结束，通话相关任务自动清理，不会留下游离 job。接入只需三步：声明依赖与 MANAGE_OWN_CALL 权限、实例化 CallsManager 并以能力（视频通话、通话流式传输）注册；构建 CallAttributes 携带显示名、地址、方向、通话类型等元数据并调用 addCall；在 CallControlScope 中收集 muted、currentCallEndpoint 等 Flow，需要切换设备时调用 requestEndpointChange。

Jetpack Telecom 1.1.0 带来统一通话记录——VoIP 通话原生显示在系统拨号器中，用户可一键回拨；同时也支持通过 isLogExcluded 标志选择性不记录。另一项新特性是 5G 网络切片：在支持的运营商网络上，通话自动享有低延迟、无干扰的专用切片，开发者无需写一行代码，也可通过 capability 标志退出。Google Meet、WhatsApp、Kakao、Zoho 等全球通信应用已接入该库。

音频焦点（audio focus） 是 Android 用于仲裁多路音频竞争的机制：同一时刻通常只有一路音频持有焦点，其他音源需暂停、降低音量或等待。VoIP 通话若自行操作 AudioManager 而不参与焦点协商，就容易出现声音混叠、被蜂窝来电静默抢占且结束后不归还等问题。Jetpack Telecom 将通话注册为系统级通话后，由系统按通话优先级统一申请与释放焦点，并在设备切换（手表、耳机、车机）时协调音频路由，从而减少泄漏与抢占。

Quick Share：把点对点文件分享嵌进你的 app

云中转的体验债

Yaxin 指出，文件分享长期依赖云中转：拍照、上传、对方下载。两个人在同一房间却要绕道云端，邀请协作者得手动输入用户名或邮箱。社交与消息应用还会为性能和存储压缩图片，在高端屏幕上显得像素化。而文件本身越来越大——单张照片轻松 10MB，五分钟视频约 500MB，上传下载耗时漫长；网络不佳时传输可能中断或超时。

本地网络 + 系统级抽象

Quick Share 作为系统能力已内置在分享面板中，自动在两台设备间选择最佳协议（蓝牙或 Wi-Fi），覆盖 Marshmallow 及以上版本，并已扩展到 Chromebook、Google Books 与 Windows，覆盖超过 30 亿台设备。Pixel 11 引入的 Tap to Share 借助 NFC 完成发现，两台设备轻碰即可分享，无需手动选设备。

面向开发者，Quick Share SDK 将随之下放：端到端加密、本地网络全速传输、必要时自动创建热点、支持 Wi-Fi Direct，图片保持原始分辨率。由于走本地网络，在地铁深处或飞机上依然可用，同时为用户节省流量、为服务端省下存储与带宽成本。

接入约 20 行代码：初始化 Quick Share client、附加文件、启动会话，即弹出预览底部面板；对敏感内容可开启屏幕防截屏。接收端同样简单。Tap to Share 还解锁了新玩法——接收方 app 无需打开，文件传完后自动拉起并收到 URI，可直接做端上处理或展示内容，UI 可通过 Kotlin Flow 响应传输事件。

Wi-Fi Direct 是一种不经过路由器、由设备之间直接建立 Wi-Fi 连接的技术，也称 Wi-Fi P2P。其中一台设备充当组主（group owner）承担类似热点的角色，其余设备作为客户端加入，从而获得远高于蓝牙的吞吐量，适合大文件传输。Quick Share 在双方无共同网络时会自动创建热点或启用 Wi-Fi Direct，使点对点传输在离线环境下仍能全速进行，这是其不依赖云端的关键底层能力。

如何选择：三条清晰的边界

三位讲者给出的选型逻辑相当直接：需要与自有蓝牙外设持续交互，用 Companion Device Manager；app 内存在任何 VoIP 通话能力——哪怕只是客服通话入口——用 Jetpack Telecom；涉及点对点文件分享或借助 Tap to Share 拉起 app，用 Quick Share。三套 API 的共同取向是把系统级的连接、音频与传输复杂性收归平台，让开发者把精力留给业务本身。

对于仍在维护前台服务的老项目，迁移到 CDM 的收益最为直接：更低的电量和内存占用、更顺畅的权限授予、以及系统托管的连接生命周期。