安卓支持 AirDrop？一文为你详解谷歌如何真正「兼容苹果」 - 数码

Just Quick Just Quality

热门话题

白天

搜索

资讯

安卓支持 AirDrop？一文为你详解谷歌如何真正「兼容苹果」

22 小时前 / 阅读约14分钟

来源：36kr

Pixel10系列机型支持AirDrop，无需独立app、谷歌账号或同一Wi-Fi。谷歌通过兼容AWDL协议实现，主要兼容“所有人10分钟”模式。Pixel10利用BLE伪装苹果设备，实现文件传输。苹果或难封堵，因反垄断压力。

这才叫

兼容

在即将结束的 2025 年，如果说科技圈有什么贯穿始终的关键词，「强兼苹果」肯定算得上一个。

然而在这个多少带点恶心的营销词汇背后，其实是一个哭笑不得的事实：

各家手机厂商所谓的兼容苹果，大多都是依靠各自的互联 app，以实现信息和数据的快捷转发。

如果这也叫「兼容」的话，那我们老早之前就已经实现了 iOS 兼容 Android、Windows 兼容 macOS、Linux 兼容一切了。

那个兼容工具叫做微信……

▲ 图｜彭博社

反观谷歌这边，作为 Android 真正的「源头厂商」，虽然在今年上半年的兼容浪潮中没有什么动作，却在最近冷不丁扔了一枚重磅炸弹：

Pixel 10 系列机型，居然支持 AirDrop 了。

方案也极为优雅：

不需要什么独立的「谷歌互传」app

不需要登录相同的谷歌账号

甚至不需要两台设备连接到同一个（有互联网连接的） Wi-Fi……

Pixel 10 用 Android 16 自带的 Quick Share，里面完美兼容了 AirDrop「所有人 10 分钟」模式的双向收发。

在 iPhone 上，与一支 Pixel 手机进行 AirDrop 的体验，和 iPhone 没有任何区别——你甚至意识不到对方不是 iPhone 手机……

▲ 图｜彭博社

要知道，在此之前 AirDrop 是苹果拥有注册商标的绝对私有功能，从来都没有给任何第三方厂商开放的先例。

即使在 iOS 内也要求通过分享菜单才能调用，现在却被谷歌用苹果最擅长的「软硬件结合」给轻松绕了过去。

什么叫强行兼容？这才叫强行兼容。

▲ 谷歌现任 CEO Sundar Pichai｜Business Insider

AirDrop 的原理

在 Pixel 10 另辟蹊径实现兼容 AirDrop 的同时，我们也不免好奇：谷歌究竟是用什么方式突破苹果对于 AirDrop 的封锁的？这个功能有可能下放给其他 Pixel 机型、乃至其他 Android 设备吗？

▲ 图｜Android Police

其中，至少对于后一个问题，我们可以从谷歌 12 月 Pixel Feature Drop 的博文和谷歌安全博客有关 Quick Share 的功能介绍中见到一些侧面的回答——

在两份文章材料中，谷歌均使用了类似「将会首先应用在 Pixel 10 系列设备」的措辞，意味着这项功能还是比较有希望下放给前几代 Pixel 的。

至于其他 Android 设备，就得看厂商是否会及时跟进谷歌发布的补丁了——希望也是很大的，毕竟没有任何 Android 厂商，比中国手机军团们更执迷于「兼容苹果」这件事。

▲ 图｜PhoneArena

而要弄清楚谷歌究竟是通过何种方式破解了 AirDrop 的护城河、直捣 Tim Cook 黄龙的，我们就得先弄清楚苹果设备之间 AirDrop 的工作原理。

苹果设备之间的 AirDrop 工作流程，可以简化成下面这个最基础的流程：

利用低功耗蓝牙广播（BLE）吆喝「我有东西需要发送」，实现设备相互发现

接收方根据模式（所有人 10 分钟/仅联系人）检查发送方的身份哈希值

确认建链，基于 AWDL 协议同步跳转到高速信道

（仅联系人模式）进一步验证 Apple ID 签名和密钥，确认 Apple ID 真实性

身份验证无误，开始传输数据

而 AirDrop 作为苹果私有功能护城河之一，重点就在于这个特殊的 AWDL 协议。

AWDL 协议的全称为 Apple Wireless Direct Link，作为苹果摆脱早期 AirDrop 仅限局域网分享的标志，AWDL 是现在所有苹果产品参与 AirDrop 的基石：它允许设备在保持互联网连接的同时，建立高带宽的设备间直连链路。

▲ 目前 AirDrop 的最新形式，就是 NameDrop「碰一碰」｜AppleInsider

虽然 AWDL 的网络基础和传输协议并不复杂，就是常见的 IPv6 TCP/UDP 传输，但它真正的技术壁垒在于上面提到的「同时性」——如何让收发的两台设备同时进入高速传输通道。

为了解决这个问题，苹果在 AWDL 中采用了一种非常取巧的「高速跳频」方案。

以 iPhone 为例，一台 iPhone 往往只有一个 Wi-Fi 射频前端，用来处理正常上网时候的基础网络连接（在网工中被称为 Infrastructure）。

但 AirDrop 服务并不使用上述基础网的信道，而是会根据国家地区法律选择一些特殊的、干扰少的「社交信道」，用来处理临近设备的高速数据传输——比如 2.4GHz 的信道 6，以及 5Ghz 的信道 11 和信道 149 等等。

▲ 「连续互通相机」也会使用 AWDL｜Youtube @Wireless Lan Professionals

这样一来，AirDrop 服务只会间歇占用设备 Wi-Fi 芯片的一小部分工作时间——保证搜索设备顺利、传输文件速度快，而且不占用过多的背景网络资源。

同时，AWDL 还为所有苹果设备预置了一个隐秘的「心跳」，负责让一个范围内所有苹果设备按照极其精准的节奏（比如每 100ms 中的 16ms）同时跳转到社交信道上，进行验证签名、传输数据的工作。

而为了让 AWDL 集群中的每一台新旧设备都保持毫秒级的时钟同步，苹果开发了一个特殊的时钟算法，会根据 MAC 地址、电量以及性能等综合指标选出一个主节点——通常是 Mac 或者 iPad Pro ——作为本地时钟的标准。

而主节点除了提供基础的时钟同步之外，也会周期性地广播 PSF 帧，其中包含了当前的时间戳和下一个可用窗口的偏移量，相当于不断给周围的设备广播：

现在是本地时间 XX:XX:XX:XX，27 毫秒之后咱们统一跳转到社交信道 149，对齐颗粒度、找好赋能抓手、实现 iOS 生态的闭环……有需要 AirDrop 的在信道 149 上吆喝一声。

除此之外，由于 AirDrop 还需要区分「所有人 10 分钟」以及「仅联系人」两种模式，单纯依靠 BLE 发现、收听 AWDL 频率、同步跳转社交信道，在安全性上还有所欠缺。

事实上，当两台苹果设备遵循 AWDL 的「心跳」同步调频到相同的社交信道之后，并不会马上开始传输文件，而是会「互换名片」、互传各自的 Apple ID Validation Record ——

这是一份由苹果根证书机构（Apple Root CA）签发的数字证书，里面包含了用该机构私钥加密的 Apple ID 信息，同时也是 AirDrop 能够显示对方姓名的原理，以及安全性的核心。

▲ 这些设备名称都是通过 Apple ID Validation Record 传输过来的

当 iPhone 收到 Apple ID Validation Record 之后，它会用系统自带的公钥去解密这份证书，将解码出来的 Apple ID 联系信息和你的通讯录比较，唯有匹配上了联系人，才会唤醒 AirDrop 接收弹窗：

▲ 已知联系人传送

如果解码出来的 Apple ID 信息和 iPhone 通讯录无法对应的话，就会被当作「噪声」，iPhone 不会显示任何东西。除非接收者打开「所有人 10 分钟」模式，这些来自陌生人的 AirDrop 申请才会被显示出来：

▲ 陌生人传送（甚至不会显示预览）

而当用户点击确认接受之后，已经同步在社交信道的两台 iPhone 就会正式启动高速的 TCP/UDP 传输，开始正式交换照片、视频或者文件数据。

实际上，上面提到的 Apple ID Validation Record 可能也是近几年 AirDrop 这么难用的原因之一：毕竟每启动一次 AirDrop，就得找苹果的服务器签个名，一旦根证书签名服务器过载，AirDrop 自然也会拥堵了。

谷歌又是怎么「偷袭老同志」的？

在理解过 AirDrop 原本是怎么工作的之后，我们就可以尝试拆解谷歌究竟是如何在这个过程中偷偷加塞、让自己也加入 AirDrop 了。

▲ 图｜TheVerge

先看基础设施：低功耗蓝牙广播、生成空白 Apple ID 的哈希值、建立TCP/UDP 传输等等——这些都是非常基础的功能，目前已经大部分内嵌在 Android 16 系统中了。

而一台 Android 设备想要「插足」AirDrop，主要的难点只在于两个：跟随 AWDL 的跳转频率，以及搞定苹果的安全证书。

其中，由于 Apple ID Validation Record 证书是完全由苹果的私钥生成的，哪怕谷歌也没有办法搞定，因此谷歌选择了一个简单粗暴的解决方法——

不能搞定 AirDrop 的「仅联系人」模式就不搞了，「所有人 10 分钟」模式允许这个证书验证不通过，Pixel 10 只兼容后者就行。

▲ 图｜Google Store

而 Pixel 10 兼容 AirDrop 真正的创举，其实在于对 AWDL「高频跳变」机制的兼容。

由于 AWDL 用于广播和跳变社交信道的时间窗口非常狭窄，对于同一个 AWDL 集群中的所有子设备监听来自主节点的同步帧、调整自身时钟和跳转社交信道的误差精度都在几毫秒以内，这些都离不开软硬件的协同开发。

在过去，对于零部件的高度控制、对于系统底层的修改能力，一直都是苹果的强项，这也是 AirDrop 事实上的技术护城河。

▲ 图｜Apple

而 Pixel 10 作为谷歌转向自研 Tensor 的第五代产品，至少在「网络工程」这一点上，目前来看是终于追平了苹果的脚步：Pixel 10 能够兼容 AirDrop，主要依靠的就是支持读取和跟随 AWDL 的跳变信号。

▲ 图｜Google

甚至 Pixel 10 并没有采用专门定制化的射频芯片，就实现了对 AWDL 的兼容，依然是一套来自博通（Broadcom）的解决方案，也是这个功能有希望通过软件下放给其他 Pixel 设备的原因。

而基于谷歌释出的部分技术细节和零星信息，我们可以还原出一台 Pixel 伪装自己加入 AWDL 集群，给 iPhone、iPad 甚至 Mac 发送 AirDrop 的流程了：

Pixel 10 发出低功耗蓝牙广播（BLE），通过在信号头添加苹果的厂商 ID「0x004C」将自己伪装成一台苹果设备

iPhone 捕捉到 BLE 信号，看到厂商 ID 确认是一个 AirDrop 服务请求，唤醒 Wi-Fi 芯片、启动 AWDL 服务搜寻附近主节点广播的同步帧，并跳转到社交信道上等待接收验证证书

与此同时，Pixel 10 也通过收听 AWDL 主节点的同步帧，在几毫秒的误差内控制 Wi-Fi 芯片跳转到对应的社交信道上，发送一个包含空白 Apple ID 的证书

由于谷歌预设了对方打开的是「所有人 10 分钟」模式，因此 iPhone 在收到来自 Pixel 的空白 Apple ID Validation Record 之后，虽然无法解码到有效的 Apple ID，但仍然会给用户弹窗提示

用户点击接收，iPhone 和 Pixel 在社交信道确认握手、建立高速连接，开始传输文件

此外，由于谷歌利用的是 AirDrop ——或者说 AWDL ——的现有工作机制，从目前的反应来看，苹果是不太好像之前封堵 RCS 转 iMessage 那样，封堵这个漏洞的。