Google 工程師提議：讓 Android 核心迴歸 Linux 主線

Android 裝置是基於 Linux 核心的，但從一開始，這些裝置就沒有執行主線核心。這期間，那些裝置上的樹外程式碼量一直被視為一個問題，為減少這樣的程式碼已經投入了大量的資源。

在 2018 年Linux Plumbers 大會上，谷歌工程師 Sandeep Patil 談了這個問題以及如何解決這個問題。在 Android 裝置上執行主線核心的夢想還沒有實現，但它可能比很多人認為的來得要快。

他表示，Android 核心起初是一個來自主線的長期穩定（LTS）版本；這些版本結合 Android 核心的專有程式碼構成了Android 公共核心版本 。供應商選擇一個公共核心，然後新增更多的樹外程式碼，從而建立一個特定於片上系統（SoC ）的核心，並提供給裝置製造商。最終，這些 SoC 核心中的其中一個被凍結，可能加入了另外一些樹外程式碼，作為一個特定裝置模型的核心。現在，只需要幾周就可以把一個 LTS 版本合併到 Android 公共核心中，但它仍然需要幾年才能成為裝置核心。這就是為什麼 Android 裝置總是執行古老的核心。

這一過程存在很多問題。Android Core 必須準備好在一系列舊的核心上執行，這個限制使它很難使用新核心的特性。核心更新緩慢，或者更常見的是根本不更新。大量樹外程式碼（如數百萬行）的使用使得要合併新的穩定更新變得很難，即使可以這樣做，把結果提供給使用者也會讓供應商感到害怕，因而這種做法並不常見。Android 核心沒有持續整合過程，不可能把 Android 系統執行在主線核心上。總之，Android 核心的開發和管理方式從一開始就消除了使用 Linux 帶來的許多優勢，但是，解決其中許多問題的工作正在進行之中。

至於舊核心：Oreo 版本需要使用 3.18、4.4 或 4.9 版本的核心——與以前的版本相比，這是一個進步，之前根本沒有核心版本的要求。Pie 版本進一步縮小了範圍，要求裝置必須提供 4.4.107、4.9.84 或 4.14.42（或更高的穩定版本）。Android 開發人員正試圖“更上一層樓”，強制併入穩定更新。這改善了現狀，但基本核心仍然是兩年（甚至更久）之前的，Android Core 仍然需要在 3.18 版本的核心上工作。

Patil 指出，一些人擔心穩定更新會導致退化，但是，這兩年裡，併入那些穩定更新僅使 Android 專案遇到一次退化。特別是 4.4.108 造成了破壞，這就是為什麼現在不需要 4.4.107 之後的東西。否則，他說，對於 Android 系統，穩定更新已被證明是高度可靠的。

其中一個原因可能是持續整合測試的情況正在改善；例如，LKFT 現在正在 LTS、‑rc 和 Android 公共核心上執行功能測試。有更多的測試正通過KernelCI 進行，Android 開發人員也在為Linux 測試專案 做出貢獻。核心補丁在一個名為Cuttlefish 的模擬裝置上進行預提交測試，它既可以執行 Android，也可以執行主線核心。SoC 供應商正在進行更多的測試，到目前為止，還沒有人報告 LTS 核心更新的問題。他們確實遇到了樹外程式碼合併衝突，但這並不奇怪。

即便如此，對 Android 廠商來說，核心升級仍然是一個大問題，他們擔心向已部署的裝置傳送大量的更改。因此，裝置通常不會在交付後升級核心——這很糟糕，但這比之前要好，那會，SoC 釋出後，其核心無法升級。不過，谷歌計劃繼續推動供應商釋出更新，最終甚至在裝置釋出後也會強制更新到較新的 LTS 版本。在某些時候，LTS 版本會包含在 Android 安全公告中，因為獲得所有 Bug 修復是很有價值的。Patil 呼應了 Greg Kroah-Hartman 的說法，即不存在此類“安全漏洞”；“只是有一些 Bug”應該被修復。

裝置無法執行主線核心的問題仍然存在；當然，問題是所有那些樹外程式碼。儘管如此，Android 公共核心中的程式碼數量已經大大減少了，這主要是為了在上游進行更改。現在，Android 公共核心中只有大約 30 個補丁，需要增加大約 6500 行程式碼才能啟動 Android。最終的計劃是將其變為零，但是仍然有許多問題需要處理，包括解決繫結器中的優先順序繼承問題、將能耗感知排程引入主線以及將 SDCardFS 檔案系統橋接移到上游。

他說，Treble 專案 推出了一個新的“供應商介面”API，它實現了一種硬體抽象層。和這個介面同時提出的還有通用系統映像 （GSI）的概念，它是 Android 開源專案的一個構建，可以在任何 Android 裝置上啟動。如果 GSI 可以在特定裝置上引導，那麼製造商就正確地實現了供應商介面。

目前，核心被認為是供應商介面的一部分——供應商必須將其作為底層實現的一部分提供。不過，Android 的計劃是提供一個基於主線的通用核心映像。裝置將按預期執行這個核心；為了實現這一點，供應商將提供一組核心模組來新增必要的硬體支援。要做到這一點，除了其他方面外，還需要把核心符號名稱空間 移到上游。

這種設計顯然不會消除樹外程式碼問題，因為在許多或大多數情況下，這些模組不是來自主線。但是，這裡仍然有一個重要的變化：特定於供應商的程式碼將被降級為可載入模組，因此就不會更改核心核心。例如，供應商提供自己的 CPU 排程程式的日子應該結束了；所有樹外程式碼都必須藉助常規模組來使用通用核心映像。這將迫使程式碼做好進入上游的準備，這是朝著正確方向邁出的一步。

最後，Patil 說，Android 核心團隊現在正積極地嘗試在釋出前把程式碼移到上游。他們恢復了主動報告漏洞和其他問題的工作，並與上游合作解決這些問題。除此之外，該專案還有許多目標，包括從 staging 樹中去除 ashmem 和 ion 模組、改進 Android 對裝置樹的使用等等。工作進展順利；總有一天，“安卓問題”可能會離我們遠去。

檢視英文原文：https://lwn.net/SubscriberLink/771974/ade4e5fb18058302/