谷歌計劃對開發新版 Android 作業系統的方式進行重大變革。
在許多人眼中，Android 的開源屬性正是選擇這款系統的關鍵理由之一——三星等 OEM 廠商透過對 One UI 等皮膚版本的程式碼進行自主調整；而密切關注 Android 動向的朋友則往往能從谷歌對 Android 開源專案（Android Open Source Project，即 AOSP）的公開變更中，發現關於作業系統即將推出新功能的種種跡象。
過去，正是因為 Android 即時開放原始碼，才成就了全球數十億臺裝置的龐大生態系統，並催生了移動網際網路時代最具活力的創新模式。
然而，谷歌近日正式確認，從下週起，Android 未來的核心功能開發將轉入內部閉環，僅會定期向 AOSP 推送階段性成果，同時 AOSP 的更新頻率也將放緩。
雖然谷歌一再強調不會封閉原始碼，但這種悄悄地把技術控制在自己手裡的做法，正在讓本來開放的安卓生態系統越來越向谷歌靠攏，甚至進一步加強谷歌“一家獨大”的局面。
谷歌已確認，未來所有 Android 的開發工作都將在其內部進行。
AOSP 是一個由谷歌維護的開源作業系統開發專案，任何人都可以自由訪問、檢視程式碼，併為專案貢獻程式碼和修復。AOSP 包含了 Android 作業系統的核心元件，但並不包含谷歌及其合作伙伴開發的專有軟體，例如谷歌移動服務（GMS）。GMS 包含了 Play Store、谷歌雲訊息推送框架、Chrome 瀏覽器、Google 搜尋等應用。
Android 的一個顯著特點是其版本多樣性，這既是其優勢所在，也偶爾帶來挑戰。例如，三星的 One UI 甚至谷歌自家的 Pixel UI，都在核心 Android 體驗基礎上進行了定製，加入了獨特的功能和改進。這一切都得益於 AOSP 提供的通用基礎作業系統。
除了對公眾開放貢獻外，Android 開源專案還允許根據開源許可自由使用和修改。亞馬遜和三星等製造商可以自由地根據自身需求調整 AOSP，並開發出自己的衍生產品，例如完全不搭載谷歌服務的多功能 Amazon Fire OS。
這種開放性也為某些企業在受到貿易制裁後繼續開發基於 Android 的 EMUI 和 HarmonyOS 之類的作業系統提供了可能。比如，華為在面臨一些國際限制後，無法再獲得 GMS 許可，但可以繼續使用 AOSP，最終華為用 HMS 取代了 GMS 功能。也有觀點認為，這等於華為可以繼續使用 Android，但他們得不到谷歌的幫助。
值得注意的是，要讓 AOSP 成為一款功能齊全的智慧手機作業系統，往往需要進行大量調整——有時甚至是大規模修改。因為如果僅僅按照預設方式構建 AOSP 並將其安裝到裝置上，其功能遠遠達不到現代智慧手機的標準。許多使用者日常依賴的關鍵功能都將缺失，以至於執行純 AOSP 幾乎沒有實際意義。
但如今谷歌決定將核心功能轉入內部開發，可能會導致一些依賴 AOSP 進行定製的硬體廠商獲取新功能的時間延遲，從而影響產品競爭力。此外，開發者社群可能無法再提前看到程式碼變更，使其難以及時適配和最佳化應用。
谷歌過去的做法是頻繁更新公共 AOSP 分支，任何人都可以訪問 AOSP，但內部分支僅對谷歌和擁有谷歌移動服務 (GMS) 許可證的公司開放，例如三星、摩托羅拉等。
此前，一些元件，如構建系統、更新引擎、藍牙協議棧、虛擬化框架和 SELinux 配置，是 AOSP-first，即完全在公開環境下開發。
但從下週起，Android 的所有開發工作都將在谷歌的內部分支進行，只有當谷歌釋出新的分支時，相關原始碼才會對外開放。
這是 Google 使用的基於網路的程式碼審查系統 AOSP Gerrit 的螢幕截圖。
谷歌承諾將繼續釋出新 Android 版本的原始碼，比如在今年晚些時候釋出 Android 16 時，外界還能繼續獲得更新的原始碼。
此外，谷歌將繼續釋出 Android Linux 核心分支的原始碼，因為它是根據 GPLv2 授權的，該授權要求釋出原始碼，並且與 AOSP 是分開的。
AOSP 之前是基於 Apache 2.0 許可證發行，儘管谷歌也表示會繼續 release 原始碼，且一再強調這並非閉源，但對於谷歌將開發轉為 private 的行為，有網友評論說，“如果一個專案依賴於一家公司進行持續開發，那麼開源許可證就沒有任何意義。”
另外，也有人提到 OpenSolaris 的悲劇性轉折，這是由 Sun Microsystems 基於 Solaris 建立的開源作業系統，在 2010 年甲骨文收購了 Sun Microsystems 之後，OpenSolaris 便停止了自主開發。
當時，OpenSolaris 也是宣佈“我們將不再即時釋出整個 Solaris 作業系統的原始碼”。但從那一刻起，原始碼就再也沒有公開過。
當年甲骨文的決定徹底冰封了開源生態，而今 Android 似乎也正沿著相似的軌跡滑行，因此也有網友認為，對於 Android 來說，最終的目標很可能是僅滿足最低限度的開源要求，只發布那些受 Copyleft 約束、谷歌不擁有版權的程式碼，直到這些元件被封閉的替代方案取代。
如今，Android 的開發方式正逐漸轉向更加私有化，這並非一蹴而就的變化。回望過去，Android 的發展歷程與最初的開放姿態有著顯著的不同。
十八年前，也就是 2007 年 11 月，Android 開放原始碼專案（AOSP）正式釋出。就在幾個月前，第一代 iPhone 問世，迅速引起轟動，開啟了現代智慧手機時代。當時，谷歌預見到蘋果可能在移動領域佔據主導地位，而谷歌自身在該領域尚無立足之地。為了對抗 iPhone，Android 作為開源專案應運而生。
在 AOSP 成立之初，谷歌大力支援開源應用的開發，這些應用與免費的 AOSP 捆綁在一起。這種策略在當時是合理的，透過為 AOSP 投入開發精力和資源，谷歌在隨後的幾年裡成功地大幅提升了基於 Android/AOSP 裝置的市場份額。
Android 擁有了龐大的使用者基礎，也意味著其擁有海量的應用程式。如果一家公司選擇分叉 Android，那麼這個作業系統本身就與數百萬個應用程式相容。該公司只需建立自己的應用商店，並將所有應用上傳即可。理論上，幾乎在一夜之間，你就能擁有一個擁有大量應用程式的非谷歌作業系統。
因此，一個成功的替代 Android 版本，將是對谷歌主導地位的真正威脅。谷歌也一直在採取措施防範這種替代品的出現。
谷歌意識到需要對其公共原始碼擁有更多的控制權，畢竟更少的開原始碼意味著 Google 的競爭對手需要做更多的工作。
隨著時間的推移，谷歌將 Android 功能從 AOSP 轉移到閉源軟體包中。例如，谷歌用自家的閉源版本取代了 AOSP 版的日曆和訊息應用，並在此過程中停止了對開源版本的維護。由於谷歌是這些應用的主要開發者，這一變化實際上扼殺或極大地阻礙了這些應用的開源 AOSP 版本的開發。
這些舉措同時也讓更新核心元件變得更加容易，而無需進行完整的作業系統更新。
Android 的所有重要且實用的部分早已被遷移到閉源元件中。結果就是，Android 變成了一座龐大的“開源”程式碼庫，但缺少了讓其真正執行所需的關鍵部分。AOSP 已經成為它過去形態的“空殼”，並且正逐步被進一步掏空。如今，Android 正在從“集市”模式轉向“教堂”模式（指由開放開發變為封閉開發）。至於谷歌何時會發布“新版本”的 AOSP 原始碼，誰也說不準。
我希望他們乾脆把 Android 變成閉源，並儘可能地為股東賺錢——畢竟，這才是他們的職責。他們為什麼還要免費提供這個系統？他們已經透過宣稱開源、建立社群成功佔領了市場，現在只需要讓它變成專有軟體，而舊的開源版本會逐漸衰落、變得不穩定。然後，他們就可以像微軟那樣，對作業系統收費——但這次是在手機上，對數百萬、甚至數十億臺裝置收費，$$$$$。（顯然我並不認同這種做法）。
目前，大多數 Android 開發都在內部分支中進行，但少陣列件（如藍牙和核心）是在公開分支中開發的。在新系統下，它們將轉移到內部分支。
這一變化無疑將使谷歌團隊的開發工作更加輕鬆，但它可能會限制我們在新版本正式釋出之前對 Android 的瞭解程度。有時，AOSP 中出現的花絮可能會指向即將推出的裝置、功能刪除或應用程式支援的變化。
我們可能再也無法獲得這些見解，因此，在谷歌推出不受歡迎的更改之前，開發者和使用者將沒有那麼多機會挑戰谷歌。
根據谷歌的說法，他們做出這一改變是為了簡化流程，並借鑑了最近對基於主幹的開發所做的改變。
由於谷歌同時長期維護著兩個獨立 AOSP 分支——一個為公共分支，一個是內部分支。任何人都可以檢視公共分支，但只有谷歌自身、Android OEM 廠商乃至其他簽訂了谷歌移動服務（GMS）許可協議的企業才能訪問到內部版本。這兩個分支在功能和 API 支援方面並不同步，這迫使谷歌不得不在每次釋出時都費力地合併分支。谷歌聲稱，透過專注於內部分支，它可以簡化釋出流程，讓每個人的工作都更輕鬆。
AOSP 專家 Mishaal Rahman 指出，AOSP 的大部分開發工作都是由谷歌在內部完成的。就是說哪怕是在此番正式變更之前，更新主體也一直只會出現在內部分支上。第三方可以向公共分支提交程式碼變更，但谷歌保留在確定 Android 新版本併發布原始碼之前，拒絕一切此類變更的最終決定權。
總的來說，無論是在今天的新聞釋出之前還是之後，以上事實均保持不變。公共 AOSP Gerrit 仍然可用，第三方提交結果也依舊公開可見。谷歌也將繼續釋出最終原始碼——只是在開發過程中，該公司將大部分 AOSP 變更由原本的閉門開發正式定性為不公開進行。
AOSP Gerrit
根據 Rahman 的解釋，這一變化主要是為了幫助谷歌內部團隊提升效率。以往，在公共 AOSP 分支與單獨的內部興建和管理開發進度，往往會產生大量不必要的開銷。
由於 AOSP 的公共分支往往落後於內部版本，所以在需要將二者的程式碼進行合併時，谷歌工程師們經常會遇到合併衝突——不同程式碼版本間的衝突往往需要耗費額外時間和精力方可解決。
透過將所有活躍開發工作轉移至內部分支，谷歌認為此舉可以消除上述衝突並簡化其工作流程。值得注意的是，這並不意味著公共 AOSP 程式碼倉庫會由此消失——谷歌將繼續在公共分支中釋出最終原始碼，第三方也仍可以透過公共 Gerrit 提交貢獻。總而言之，此番調整隻是正式確定了谷歌工程師在開發週期中該在哪裡進行日常編碼。
Android 開源專案仍然非常活躍
至少從功能角度來看，此舉造成的最大問題，就是為 AOSP 貢獻程式碼的第三方開發者可能將難以跟蹤 Android 即將迎來的變更。這可能會阻礙開發者們的持續貢獻熱情，因為谷歌在內部也許正在進行同樣的開發與探索。
此前還有報道說，谷歌近期正在轉向 Trunk Stable 開發流程（即所有人為同一程式碼版本做貢獻，確保谷歌能夠更快、更穩定地構建整個系統），希望藉此加快 Android 的釋出速度——特別是打算將今年年內的 Android 16 時間表儘量提前。
參考連結:
https://www.androidauthority.com/google-android-development-aosp-3538503/
https://news.ycombinator.com/item?id=43485950
https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/
宣告：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。
今日好文推薦
智慧編碼工具層出不窮，究竟怎麼選、如何用？3 月 5 日 -28 日，InfoQ 極客傳媒將發起「智慧編碼系列」直播，邀請阿里、百度、騰訊、位元組、商湯、思碼逸等企業一起線上 Coding，與所有開發者直觀感受和評測數款國內外線上編碼工具在企業真實生產場景中的表現。歡迎掃碼或點選按鈕一鍵預約直播、查看回放