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

關注「明日產品」，硬哲學欄目試圖剝離技術和參數的外衣，探求產品設計中人性的本源。

贊助商廣告

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

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

各家手機廠商所謂的兼容蘋果，大多都是依靠各自的互聯 app，以實現資訊和數據的快捷轉發。

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

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

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

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

同時，谷歌的實現方案也極為優雅：不需要什麼獨立的「谷歌互傳」app、不需要登錄相同的谷歌賬號，甚至不需要兩台設備連接到同一個（有網際網路連接的） Wi-Fi。

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

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

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

AirDrop 的原理

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

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

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

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

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

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

• 利用低功耗藍牙廣播（BLE）吆喝「我有東西需要發送」，實現設備相互發現

• 接收方根據模式（所有人 10 分鐘/僅聯繫人）檢查發送方的身份哈希值

• 確認建鏈，基於 AWDL 協議同步跳轉到高速信道

• （僅聯繫人模式）進一步驗證 Apple ID 簽名和密鑰，確認 Apple ID 真實性

• 身份驗證無誤，開始傳輸數據

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

AWDL 協議的全稱為 Apple Wireless Direct Link，作為蘋果擺脫早期 AirDrop 僅限局域網分享的標誌，AWDL 是現在所有蘋果產品參與 AirDrop 的基石：它允許設備在保持網際網路連接的同時，建立高帶寬的設備間直連鏈路。

雖然 AWDL 的網路基礎和傳輸協議並不複雜，就是常見的 IPv6 TCP/UDP 傳輸，但它真正的技術壁壘在於上面提到的「同時性」——如何讓收發的兩台設備同時進入高速傳輸通道。

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

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

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

這樣一來，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 能夠顯示對方姓名的原理，以及安全性的核心。

當 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 了。

先看基礎設施：低功耗藍牙廣播、生成空白 Apple ID 的哈希值、建立 TCP/UDP 傳輸等等——這些都是非常基礎的功能，目前已經大部分內嵌在 Android 16 系統中了。

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

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

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

而 Pixel 10 兼容 AirDrop 真正的創舉，其實在於對 AWDL「高頻跳變」機制的兼容。

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

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

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

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

甚至 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 那樣，封堵這個漏洞的。

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

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

比如歐洲區 App Store 開放第三方商店、iMessage 兼容 RCS 簡訊、iOS 26.3 Beta 中新增的遷移數據到 Android 都是 DMA 法案的結果。

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

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

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