安卓支持 AirDrop？一文為你詳解谷歌如何真正「兼容蘋果」｜硬哲學

安卓支持AirDrop了

愛范兒關注「明日產(chǎn)品」，硬哲學欄目試圖剝離技術和參數(shù)的外衣，探求產(chǎn)品設計中人性的本源。

在即將結束的2025年，如果說科技圈有什么貫穿始終的關鍵詞，「強兼蘋果」肯定算得上一個。

然而在這個多少帶點惡俗的營銷詞匯背后，其實是一個哭笑不得的事實：

各家手機廠商所謂的兼容蘋果，大多都是依靠各自的互聯(lián)app，以實現(xiàn)信息和數(shù)據(jù)的快捷轉發(fā)。

如果這也叫「兼容」的話，那我們老早之前就已經(jīng)實現(xiàn)了 iOS兼容 Android、Windows兼容 macOS、Linux 兼容一切了。

那個兼容工具叫做微信——

反觀谷歌這邊，作為 Android 真正的「源頭廠商」，雖然在今年上半年的兼容浪潮中沒有什么動作，卻在最近冷不丁扔了一枚重磅炸彈：

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

同時，谷歌的實現(xiàn)方案也極為優(yōu)雅：不需要什么獨立的「谷歌互傳」app、不需要登錄相同的谷歌賬號，甚至不需要兩臺設備連接到同一個（有互聯(lián)網(wǎng)連接的） Wi-Fi。

Pixel 10用 Android 16自帶的 Quick Share，完美兼容了 AirDrop「所有人10分鐘」模式的雙向收發(fā)。

Pixel 10與蘋果手機互傳信息

要知道，在此之前 AirDrop 作為蘋果擁有注冊商標的絕對私有功能，從來都沒有給任何第三方廠商開放的先例，即使在 iOS 內也要求通過分享菜單才能調用，現(xiàn)在卻被谷歌用蘋果最擅長的「軟硬件結合」給輕松繞了過去。

什么叫強行兼容？這才叫強行兼容。

圖為谷歌現(xiàn)任 CEO Sundar Pichai｜Business Insider

AirDrop 的原理

在 Pixel 10另辟蹊徑實現(xiàn)兼容 AirDrop 的同時，我們也不免好奇：谷歌究竟是用什么方式突破蘋果對于 AirDrop 的封鎖的？這個功能有可能下放給其他 Pixel 機型、乃至其他 Android 設備嗎？

其中，至少對于后一個問題，我們可以從谷歌12月 Pixel Feature Drop 的博文和谷歌安全博客有關 Quick Share 的功能介紹中見到一些側面的回答——

在兩份文章材料中，谷歌均使用了類似「將會首先應用在 Pixel 10系列設備」的措辭，意味著這項功能還是比較有希望下放給前幾代 Pixel 的。

至于其他 Android 設備，就得看廠商是否會及時跟進谷歌發(fā)布的補丁了——畢竟沒有任何 Android 廠商，比中國手機軍團們更執(zhí)迷于「兼容蘋果」這件事。

而要弄清楚谷歌究竟是通過何種方式破解了 AirDrop 的護城河、直搗 Tim Cook 黃龍的，我們就得先弄清楚蘋果設備之間 AirDrop 的工作原理。

蘋果設備之間的 AirDrop 工作流程，可以簡化成下面這個最基礎的流程：

蘋果設備之間的 AirDrop 工作流程

• 利用低功耗藍牙廣播（BLE）吆喝「我有東西需要發(fā)送」，實現(xiàn)設備相互發(fā)現(xiàn)
• 接收方根據(jù)模式（所有人10分鐘/僅聯(lián)系人）檢查發(fā)送方的身份哈希值
• 確認建鏈，基于 AWDL 協(xié)議同步跳轉到高速信道
• （僅聯(lián)系人模式）進一步驗證 Apple ID 簽名和密鑰，確認 Apple ID 真實性
• 身份驗證無誤，開始傳輸數(shù)據(jù)

而 AirDrop 作為蘋果私有功能護城河之一，重點就在于這個特殊的 AWDL 協(xié)議。

AWDL 協(xié)議的全稱為 Apple Wireless Direct Link，作為蘋果擺脫早期 AirDrop 僅限局域網(wǎng)分享的標志，AWDL 是現(xiàn)在所有蘋果產(chǎn)品參與 AirDrop 的基石：它允許設備在保持互聯(lián)網(wǎng)連接的同時，建立高帶寬的設備間直連鏈路。

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

雖然 AWDL 的網(wǎng)絡基礎和傳輸協(xié)議并不復雜，就是常見的 IPv6 TCP/UDP 傳輸，但它真正的技術壁壘在于上面提到的「同時性」——如何讓收發(fā)的兩臺設備同時進入高速傳輸通道。

為了解決這個問題，蘋果在 AWDL 中采用了一種非常取巧的「高速跳頻」方案。

以 iPhone 為例，一臺 iPhone 往往只有一個 Wi-Fi 射頻前端，用來處理正常上網(wǎng)時候的基礎網(wǎng)絡連接（在網(wǎng)工中被稱為 Infrastructure）。

但 AirDrop 服務并不使用上述基礎網(wǎng)的信道、和用戶搶網(wǎng)，而是會根據(jù)國家地區(qū)法律選擇一些特殊的、干擾少的「社交信道」，用來處理臨近設備的高速數(shù)據(jù)傳輸——比如2.4GHz 的信道6，以及5Ghz 的信道44和信道149等等。

「連續(xù)互通相機」也會使用 AWDL｜Youtube @Wireless Lan Professionals

這樣一來，AirDrop 服務只會間歇占用設備 Wi-Fi 芯片的一小部分工作時間——保證搜索設備順利、傳輸文件速度快，而且不占用過多的背景網(wǎng)絡資源。

同時，AWDL 還為所有蘋果設備預置了一個隱秘的「心跳」，負責讓一個范圍內所有蘋果設備按照極其精準的節(jié)奏（比如每100ms 中的16ms）同時跳轉到社交信道上，進行驗證簽名、傳輸數(shù)據(jù)的工作。

而為了讓 AWDL 集群中的每一臺新舊設備都保持毫秒級的時鐘同步，蘋果開發(fā)了一個特殊的時鐘算法，會根據(jù) MAC 地址、電量以及性能等綜合指標選出一個主節(jié)點——通常是 Mac 或者 iPad Pro ——作為本地時鐘的標準。

蘋果開發(fā)了一個特殊的時鐘算法

而主節(jié)點除了提供基礎的時鐘同步之外，也會周期性地廣播 PSF 幀，其中包含了當前的時間戳和下一個可用窗口的偏移量，相當于不斷給周圍的設備廣播：

現(xiàn)在是本地時間 XX:XX:XX:XX，27毫秒之后咱們統(tǒng)一跳轉到社交信道149，對齊顆粒度、找好賦能抓手、實現(xiàn) iOS 生態(tài)的閉環(huán)……有需要 AirDrop 的在信道149上吆喝一聲。

除此之外，由于 AirDrop 還需要區(qū)分「所有人10分鐘」以及「僅聯(lián)系人」兩種模式，單純依靠 BLE 發(fā)現(xiàn)、收聽 AWDL 頻率、同步跳轉社交信道，在安全性上還有所欠缺。

事實上，當兩臺蘋果設備遵循 AWDL 的「心跳」同步調頻到相同的社交信道之后，并不會馬上開始傳輸文件，而是會「互換名片」、互傳各自的 Apple ID Validation Record ——

這是一份由蘋果根證書機構（Apple Root CA）簽發(fā)的數(shù)字證書，里面包含了用該機構私鑰加密的 Apple ID 信息，同時也是 AirDrop 能夠顯示對方姓名的原理，以及安全性的核心。

這些設備名稱都是通過 Apple ID Validation Record 傳輸過來的

當 iPhone 收到 Apple ID Validation Record 之后，它會用系統(tǒng)自帶的公鑰去解密這份證書，將解碼出來的 Apple ID 聯(lián)系信息和你的通訊錄比較，唯有匹配上了聯(lián)系人，才會喚醒 AirDrop 接收彈窗：

已知聯(lián)系人傳送

如果解碼出來的 Apple ID 信息和 iPhone 通訊錄無法對應的話，就會被當作「噪聲」，iPhone 不會顯示任何東西。除非接收者打開「所有人10分鐘」模式，這些來自陌生人的 AirDrop 申請才會被顯示出來：

陌生人傳送（甚至不會顯示預覽）

而當用戶點擊確認接受之后，已經(jīng)同步在社交信道的兩臺 iPhone 就會正式啟動高速的 TCP/UDP 傳輸，開始正式交換照片、視頻或者文件數(shù)據(jù)。

有意思的是，上面提到的 Apple ID Validation Record 可能也是近幾年 AirDrop 這么難用的原因之一：畢竟每啟動一次 AirDrop，就得找蘋果的服務器簽個名，一旦基礎網(wǎng)不好、連接不上服務器，或者根證書簽名服務器過載，AirDrop 自然也會擁堵了。

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

在理解過 AirDrop 原本是怎么工作的之后，我們就可以嘗試拆解谷歌究竟是如何在這個過程中偷偷加塞、讓自己也加入 AirDrop 了。

先看基礎設施：低功耗藍牙廣播、生成空白 Apple ID 的哈希值、建立 TCP/UDP 傳輸?shù)鹊取@些都是非?；A的功能，目前已經(jīng)大部分內嵌在 Android 16系統(tǒng)中了。

而一臺 Android 設備想要「插足」AirDrop，主要的難點只在于兩個：跟隨 AWDL 的跳轉頻率，以及搞定蘋果的安全證書。

其中，由于 Apple ID Validation Record 證書是完全由蘋果的私鑰生成的，哪怕谷歌也沒有辦法搞定，因此谷歌選擇了一個簡單粗暴的解決方法——

不能搞定 AirDrop 的「僅聯(lián)系人」模式就不搞了，「所有人10分鐘」模式允許這個證書驗證不通過，Pixel 10只兼容后者就行。

而 Pixel 10兼容 AirDrop 真正的創(chuàng)舉，其實在于對 AWDL「高頻跳變」機制的兼容。

在谷歌12月20日向外媒 Android Authority 發(fā)布了一份拐彎抹角的聲明之后，目前技術領域的普遍看法是谷歌沒有簡單通過 Wi-Fi Aware 與 AirDrop 服務建立兼容層，而是真的對 AWDL 協(xié)議進行了逆向工程，并取得了一些破解成果——不然也就沒必要對實現(xiàn)方式如此含糊其辭了。

由于 AWDL 用于廣播和跳變社交信道的時間窗口非常狹窄，對于同一個 AWDL 集群中的所有子設備監(jiān)聽來自主節(jié)點的同步幀、調整自身時鐘和跳轉社交信道的誤差精度都在幾毫秒以內，這些都離不開軟硬件的協(xié)同開發(fā)。

在過去，對于零部件的高度控制、對于系統(tǒng)底層的修改能力，一直都是蘋果的強項，這也是 AirDrop 事實上的技術護城河。

而 Pixel 10作為谷歌轉向自研 Tensor 的第五代產(chǎn)品，至少在「網(wǎng)絡工程」這一點上，目前來看是終于追平了蘋果的腳步：Pixel 10能夠兼容 AirDrop，主要依靠的就是自家編寫的網(wǎng)絡驅動器支持讀取和跟隨 AWDL 的跳變信號。

甚至 Pixel 10并沒有采用專門定制化的射頻芯片，就實現(xiàn)了對 AWDL 的兼容，依然是一套來自博通（Broadcom）的解決方案，也是這個功能有希望通過軟件下放給其他 Pixel 設備的原因。

而基于谷歌釋出的部分技術細節(jié)和零星信息，我們可以嘗試還原出一臺 Pixel 偽裝自己加入 AWDL 集群，給 iPhone、iPad 甚至 Mac 發(fā)送 AirDrop 的流程了：

• Pixel 10發(fā)出低功耗藍牙廣播（BLE），通過在信號頭添加蘋果的廠商 ID「0x004C」將自己偽裝成一臺蘋果設備
• iPhone 捕捉到 BLE 信號，看到廠商 ID 確認是一個 AirDrop 服務請求，喚醒 Wi-Fi 芯片、啟動 AWDL 服務搜尋附近主節(jié)點廣播的同步幀，并跳轉到社交信道上等待接收驗證證書
• 與此同時，Pixel 10也通過收聽 AWDL 主節(jié)點的同步幀，在幾毫秒的誤差內控制 Wi-Fi 芯片跳轉到對應的社交信道上，發(fā)送一個包含空白 Apple ID 的證書
• 由于谷歌預設了對方打開的是「所有人10分鐘」模式，因此 iPhone 在收到來自 Pixel 的空白 Apple ID Validation Record 之后，雖然無法解碼到有效的 Apple ID，但仍然會給用戶彈窗提示
• 用戶點擊接收，iPhone 和 Pixel 在社交信道確認握手、建立高速連接，開始傳輸文件

此外，由于谷歌利用的是 AirDrop ——或者說 AWDL ——的現(xiàn)有工作機制，從目前的反應來看，蘋果是不太好像之前封堵 RCS 轉 iMessage 那樣，封堵這個漏洞的。

曾經(jīng)能讓 Android 發(fā)送 iMessage 的 Beeper 就被蘋果堵死了｜Droid Life

實際上，從谷歌11月20號最先在安全博客中公布這項功能，到前幾天的12月 Pixel Feature Drop 正式大范圍推送，蘋果都沒有做出非常明顯的反制動作。

更好的是，蘋果這次可能不太方便重拳出擊了。畢竟有歐盟的《數(shù)字市場法案》（Digital Markets Act, DMA）在前，目前蘋果和谷歌出于反壟斷的壓力，都在加緊相互的兼容工作——

歐洲區(qū) iPhone 開放第三方應用商店｜TechRadar

比如歐洲區(qū) App Store 開放第三方商店、iMessage 兼容 RCS 短信、iOS 26.3 Beta 中新增的遷移數(shù)據(jù)到 Android 都是 DMA 法案的結果。

雖然讓 Quick Share 與 AirDrop 融合不在 DMA 法案的范圍內，但也希望蘋果能不要那么快就封堵這個口子。

與此同時，谷歌這一次為 Pixel 10兼容 AirDrop 而給出的解題思路，希望也能成為全部國產(chǎn)手機廠商的一個學習案例——

從系統(tǒng)底層推進，從工作機制里入手，那才叫真正的兼容；所有需要額外下載 app 才能互傳的方案，都只能叫適配而已。