文章圖片
文章圖片
文章圖片
文章圖片
今年早些時候 ， 谷歌曾宣布將完全獨立開發Android操作系統 ， 以簡化其開發流程 。 谷歌將精力集中在一個內部分支上 ， 旨在精簡此前分散的工作 。 這一消息最初在Android開發社區引起了一些關注 ， 但爭議很快就平息了 。 這是因為谷歌此前已主導開發大部分Android系統核心功能 ， 且始終承諾發布源代碼 ， 因此開發者們暫時把提起的心放回了肚子里 。
然而 ， 谷歌最近的舉動再次引發了人們對其可能停止共享新Android版本源代碼的擔憂 。 谷歌已聲明這些擔憂毫無根據 ， 但其他新變化使得自定義Android ROM的發展變得更加困難 。 這也引起了開發者群體對谷歌逐漸“扎緊口袋”的擔憂 ， 尤其是那些長期依賴“魔改”Android來獲取廣告和App分發收益的三大中國手機廠商（OVM） 。
AOSP會消失嗎？谷歌表示（暫時）不會谷歌今年依然兌現承諾 ， 本周發布了Android 16的源代碼 ， 允許獨立開發者自行編譯新操作系統 。 與往常一樣 ， 該源代碼已根據寬松的Apache 2.0許可證上傳至Android開源項目 (AOSP) 。
然而 ， 多位開發者很快注意到Android 16源代碼版本中存在一個明顯的缺陷：Pixel設備的設備樹缺失 。 谷歌也未能為每臺Pixel設備上傳新的驅動程序二進制文件 ， 并且發布的內核源代碼的提交歷史記錄被壓縮了 。 由于谷歌多年來一直分享設備樹、驅動程序二進制文件和完整的內核源代碼提交歷史記錄 ， 因此新版本中出現這樣的缺失令人擔憂 。
這些遺漏導致有人猜測谷歌正邁出停止AOSP計劃的第一步 。 對此 ， 谷歌副總裁兼Android平臺總經理Seang Chau專門現身辟謠 。 他在一篇帖子中回應了這一猜測 ， 并表示“AOSP不會消失” 。
他還確認 ， 省略Pixel設備樹是有意為之 ， 并表示“AOSP需要一個靈活、可配置且價格合理的參考目標——獨立于任何特定硬件 ， 包括谷歌的硬件 。 ” 谷歌將不再支持在Pixel設備上構建 AOSP ， 而是支持虛擬Android 設備“Cuttlefish”作為其參考目標 。 Cuttlefish在PC上運行 ， 允許谷歌和平臺開發者測試新的硬件功能 。 谷歌還將繼續支持GSI目標 ， 這些是通用系統映像 ， 幾乎可以在任何Android設備上安裝 。
這種邏輯聽起來似乎完全合理 。 谷歌希望不再使用Pixel作為AOSP的參考設備 ， 并正在為此做出改變 。 正如Seang Chau所指出的 ， “AOSP 建立在為設備實現、SoC供應商和指令集架構提供開放平臺的基礎之上 。 ”從這個角度來看Cuttlefish是一個更合適的參考目標 ， 因為它不像Pixel手機那樣是高度定制的消費級硬件 。 然而 ， Cuttlefish作為一款虛擬設備 ， 無法完全覆蓋真實硬件的兼容性測試場景 ， 這也導致依賴實體設備調試的開發者面臨挑戰 。
這些變化如何影響自定義ROM開發？【AOSP并未消亡，但谷歌明顯扎緊了國產手機廠商的脖子】然而 ， 更重要的問題是 ， 這一決定將對那些構建自定義ROM（AOSP 愛好者分支）的開發者產生影響 。 LineageOS項目的長期貢獻者和審閱者Nolen Johnson表示 ， 為Pixel手機構建這些ROM的過程將變得“痛苦” 。
此前 ， 谷歌曾簡化了開發者為Pixel設備構建AOSP的流程 ， 但如今這項支持已不復存在 。 過去 ， 開發者只需“拉取谷歌創建的配置” ， 添加自定義配置 ， 然后進行構建即可 。 然而 ， 現在他們需要使用谷歌為Android 15發布的舊設備樹 ， 并“盲目地從預先構建的二進制文件中猜測和逆向工程 ， 以確定每個月需要進行哪些更改” 。
這是因為 ， 為設備構建完整的Android版本（而不僅僅是GSI）需要設備樹 。 設備樹是一組內核配置文件 ， 用于定義硬件布局、外設參數、驅動加載規則及專有文件路徑 ， 是內核適配特定硬件的核心配置文件 。 雖然谷歌之前已經處理了這項工作 ， 但現在開發者必須自行創建設備樹 ， 而無法訪問必要的專有源代碼 。
此外 ， 谷歌壓縮內核源代碼提交歷史的決定也阻礙了定制開發 。 Pixel的內核源代碼通常被用作“其他設備獲取功能、錯誤修復和安全補丁的參考點” ， 但隨著內核源代碼的提交歷史記錄被壓縮合并 ， 多個增量更新被整合為單一提交 ， 這種做法已不再可行 。
雖然從商業意義上來講 ， 谷歌沒有義務發布設備樹、提供驅動程序二進制文件或分享完整的內核提交歷史記錄（事實上 ， 它是少數幾家一直這樣做的“有良心”的手機制造商之一） ， 但它多年來一直這樣做 。 谷歌這樣做的原因是 ， Pixel被視為AOSP的參考平臺 ， 因此開發者需要一種便捷的方法來為其構建應用 。
谷歌決定停止將Pixel作為AOSP參考設備 ， 這令人遺憾 ， 因為這等于剝奪了Lineage OS和Graphene OS等為Pixel設備構建Android系統的開發者的權利 。 這些開發者仍然可以為Pixel設備構建AOSP ， 但現在會比以前更加困難和痛苦 ， 因為他們需要從頭開始構建自己的設備樹 。 這也使得Pixel 的開發難度增大 ， 因為開發者不得不構建自己的設備樹、提取二進制文件 ， 并處理在其他設備上壓縮的內核源代碼提交歷史記錄 。
值得慶幸的是 ， Pixel仍然非常容易解鎖引導加載程序（老刷機用戶都懂得 ， 只需啟用開發者選項 ， 然后在開發者選項中啟用OEM 解鎖和USB調試） ， 但這肯定會增加開發人員為獲得穩定的自定義ROM體驗所需做的工作 。
對中國手機廠商影響深遠谷歌調整AOSP開發模式 ， 雖然表面上僅對Lineage OS等定制ROM開發者造成直接困擾 ， 但對于中國手機廠商定制Android系統的影響更為深遠 ， 畢竟市面上的頭部Android廠商只剩三星和OVM了 。
在技術層面 ， 由于缺乏設備樹 ， 廠商要自己想辦法解決硬件配置的問題 ， 過去谷歌提供的設備樹就像硬件說明書 ， 現在只能依靠逆向工程去拆解二進制文件 ， 比如分析芯片參數或者驅動接口 ， 不僅費時還容易出錯 。
在驅動適配來看 ， 過去谷歌提供的驅動直接能用 ， 將來可能必須向芯片廠商要或者自己開發 ， 中小廠商如果技術儲備不夠 ， 驅動適配可能就跟不上系統更新 ， 導致硬件功能出問題 ， 比如攝像頭優化不到位或者續航異常 。
而且 ， 虛擬設備 Cuttlefish雖說是參考目標 ， 但它模擬的硬件環境跟真實手機不一樣 ， 像5G信號處理、散熱測試這些場景 ， 虛擬環境無法測出真實效果 ， 廠商必須額外用實體機做測試 ， 進一步增加開發成本 。
從開發模式來看 ， 谷歌把核心開發放在內部閉源分支 ， 廠商只能等正式發布后才能拿到源代碼 ， 這就導致定制化的節奏被打亂 。 過去可以跟隨谷歌的開發進度同步調整 ， 現在只能被動等 ， 比如小米的定制UI ， 得等Android 16源代碼放出來才能開始改 ， 新功能上線可能就比谷歌原生系統晚兩三個月 。 而且開源社區的協作也變難了 ， 過去廠商遇到底層問題能在AOSP社區找解決方案 ， 現在第三方開發者貢獻變少 ， 代碼審查又因為提交歷史被壓縮變得麻煩 ， 中小廠商可能就不敢做太復雜的定制 ， 因為會擔心兼容性問題 。
雖然谷歌還支持通用系統映像 GSI ， 但廠商的硬件比如高刷屏、多攝系統這些定制化配置 ， GSI可能兼容不了 ， 必須額外調試 ， 等于又多了一道工序 。
在生態和商業層面 ， 中國手機廠商靠定制系統內置廣告和應用商店賺取額外收益 ， 比如OPPO應用商店、小米內置廣告 ， 隨著谷歌限制系統定制深度 ， 廣告加載效率可能就受影響 ， 應用分發渠道也可能被壓縮 。 而且簽署了GMS協議的廠商必須遵守谷歌的兼容性要求 ， 不得隨便改系統底層 ， 如果谷歌協議條款逐漸收緊 ， 廠商合規成本就會增加 。
地緣關系也是不得不考慮的因素 ， 萬一谷歌將來用代碼閉源來卡脖子 ， 依賴Android的廠商可能會面臨系統更新斷供的風險 ， 這也是逼著他們加快自主系統的布局 。
長遠來看 ， 頭部廠商其實已經在做準備了 。 現在很多廠商采取雙軌制 ， 一邊維護現有的Android分支 ， 一邊研發自主技術 ， 比如OPPO投資做跨平臺編譯工具 ， 小米聯合展訊開發RISC-V架構 ， 都是為了以后能減少對谷歌的依賴 。 雖然現在調整期廠商會遇到開發成本增加、適配難度變大的問題 ， 但從長期看 ， 這其實加速了整個產業往自主化方向走 ， 以后的核心競爭力可能就看誰家的底層技術更扎實、生態建得更好了 。
