Android 通用核心

AOSP 通用核心 (也稱為 Android 通用核心或 ACK) 是 kernel.org 核心的下游，包含 Android 社群感興趣的修補程式，但這些修補程式尚未合併至主線或長期支援 (LTS) 核心。這些修補程式可能包括：

• Android 功能所需的上游功能反向移植和挑選
• 適用於 Android 裝置，但上游仍在開發階段的功能
• 對其他生態系統合作夥伴有用的供應商/原始設備製造商 (OEM) 功能

android-mainline 是 Android 功能的主要開發分支。Linus Torvalds 發布版本或候選版本時，Linux 主線會併入 android-mainline。2019 年前，Android 通用核心是透過複製最近宣告的 LTS 核心，並加入 Android 專屬修補程式建構而成。這項程序在 2019 年有所變更，目的是要從 android-mainline 分支新的 Android 通用核心。這個新模型可逐步達成相同結果，因此不必費力轉送及測試 Android 修補程式。android-mainline 經過大量持續測試，因此發布時就包含高品質的 Kernel。

上游宣告新的 LTS 時，對應的通用核心會從 android-mainline 分支。合作夥伴可透過合併 android-mainline，在聲明 LTS 版本前開始專案。建立新的通用核心分支後，合作夥伴就能順暢地將合併來源變更為新分支。

其他常見的 Kernel 分支會定期從相關聯的 LTS Kernel 進行合併。這些合併作業通常會在 LTS 版本發布後立即完成。舉例來說，Linux 6.1.75 發布後，會併入 6.1 通用核心 (android14-6.1)。強烈建議合作夥伴更新核心，確保 LTS 和 Android 專屬錯誤修正程式保持在最新狀態。

ACK KMI 核心分支版本

GKI 核心具有穩定的核心模組介面。KMI 是由核心版本和 Android 平台版本唯一識別，因此分支機構的名稱為 ANDROID_RELEASE-KERNEL_VERSION。舉例來說，Android 14 的 6.1 GKI 核心名稱為 android14-6.1。Android 15 導入了 GKI 核心 android15-6.6。

功能和啟動核心

在 Android 15 之前，裝置啟動時可使用最近三種核心的任一版本。從 Android 15 開始，裝置發布時可使用最近兩個核心版本。Android 15 的啟動核心為 android15-6.6 和 android14-6.1。

由於更新平台版本時不需要升級核心，因此即使核心缺少平台版本的最新功能，仍可用於啟動裝置。因此，即使將平台版本升級至 Android 15，裝置仍可使用專為 Android 14 設計的內核 (例如 android14-6.1)。

常見的 Kernel 階層

從 android-mainline 分支

圖 1 顯示通用核心階層的頂層。

圖 1. 從 android-mainline 核心建立通用核心

請注意，新的 Android 通用核心 android14-6.1 已於 2022 年從 android-mainline 分支。2023 年，當下一個 LTS 宣告時， android15-6.6 會從 android-mainline 分支。

如圖 1 所示，每個核心版本都可以做為兩個 GKI 核心的基礎。舉例來說，兩個 v5.15 核心分別是 android13-5.15 和 android14-5.15，兩者都是各自平台版本的特徵核心。5.10 也是如此；在宣告 LTS 時建立 android12-5.10，並在 2021 年春季的 Kernel 功能完成里程碑，從 android12-5.10 分支 android13-5.10，以便開發 Android 13 的功能。自 Android 15 (2024 年) 起，每個核心版本只會有一種新的 GKI 核心 (沒有 android15-6.1 核心)。

ACK KMI 分支生命週期

ACK KMI 分支的生命週期如圖 2 所示。

圖 2. 6.6 ACK KMI 分支生命週期

為釐清開發流程和分支生命週期，圖 2 著重於 6.6 的 ACK KMI 分支。

每個 ACK KMI 分支都會經歷三個階段，如圖 2 所示，每個分支會以不同顏色表示。如圖所示，無論階段為何，LTS 都會定期合併。

開發階段

建立完成後，ACK KMI 分支就會進入開發階段 (在圖 2 中標示為「dev」)，並開放為下一個 Android 平台版本貢獻功能。在圖 2 中，當 6.6 宣告為新的上游 LTS 核心時，系統會建立 android15-6.6。

穩定階段

ACK KMI 分支宣告功能完成後，就會進入穩定階段 (在圖 2 中標示為「stable」)。我們仍接受合作夥伴功能和錯誤修正，但會啟用 KMI 追蹤功能，偵測影響介面的任何變更。在這個階段，系統會接受 KMI 破壞性變更，並依預先定義的頻率 (通常每兩週一次) 更新 KMI 定義。如要瞭解 KMI 監控的詳細資料，請參閱 GKI 總覽。

KMI 凍結階段

在將新平台版本推送至 AOSP 前，ACK KMI 分支會凍結，且在分支的生命週期內維持凍結狀態。也就是說，除非發現嚴重安全性問題，且必須影響穩定 KMI 才能解決，否則我們不會接受任何會導致 KMI 損壞的變更。為避免 KMI 損壞，如果 Android 裝置不需要修正，從 LTS 合併的部分修補程式可能會遭到修改或捨棄。

ACK KMI 分支凍結後，只要現有的 KMI 通用核心未損壞，即可接受錯誤修正和合作夥伴功能。只要不影響目前 KMI 的介面，即可使用新的匯出符號擴充 KMI。KMI 新增介面後，會立即進入穩定狀態，日後變更也不會中斷。

舉例來說，如果變更會將欄位新增至 KMI 介面使用的結構，則不允許變更，因為這會變更介面定義：

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

但新增函式則沒問題：

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

在 GKI 核心的生命週期內，系統會維持與使用者空間的回溯相容性，因此核心可安全用於裝置發布時搭載的 Android 平台版本。持續測試舊版，確保相容性。因此在圖 2 中，android15-6.6 核心可用於 Android 15 以上版本的裝置。由於 Android 平台版本也與舊版相容，因此 android14-6.1 核心可用於 Android 15 裝置的推出或升級。

KMI 產生編號

如果在穩定階段發生 LTS 合併，或之後發生安全性問題或其他事件，需要接受 KMI 變更修補程式，build.config.common 中記錄的 KMI 產生編號就會遞增。您可以使用 uname 指令找出目前的 KMI 生成作業：

$ uname -r
6.6.30-android15-6-g86d10b30f51f

平台版本後方的數字是 KMI 世代 (在本例中為 6)。

如果 KMI 生成作業有所變更，核心就無法與符合先前 KMI 生成作業的供應商模組相容，因此模組必須與核心同步重建及更新。KMI 凍結後，KMI 生成變更應該非常罕見。

核心之間的相容性

從新的 GKI 核心開始，同一 LTS 系列中核心的相容性規定將有所變更。

GKI 核心

GKI 核心會與支援該核心版本的所有 Android 平台版本保持回溯相容。此外，Android 平台版本與先前版本的 GKI 核心回溯相容。因此，您可以在搭載 Android 15 (2024 年) 的裝置上，安全地使用為 Android 14 (2023 年) 開發的 android14-6.1 核心。我們會持續對 GKI 核心進行 VTS 和 CTS 測試，確保與所有支援版本相容。

KMI 穩定性高，因此更新核心時，不需要在供應商映像檔中重建核心模組。

不同 GKI 核心之間不會維持 KMI 相容性。因此，舉例來說，如要將 android14-6.1 核心換成 android15-6.6 核心，就必須重建所有模組。

GKI 核心僅支援初始和後續版本。舊版不支援這項功能。因此，搭載 Android 14 (2023) 的裝置不支援 android15-6.6 核心。

相容性矩陣

下表列出各 Android 平台版本支援及測試的 Kernel 版本。

支援期限和安全性修補程式

ACK 會接收上游的 LTS 合併項目，以及 Android 專屬程式碼的錯誤修正。 這些修正程式包括每月 Android 安全性公告中提及的所有相關核心安全性修補程式。

ACK 的支援時間可能比 kernel.org 上對應的上游穩定版核心更長。在這種情況下，Google 會提供延長支援服務，直到本節顯示的終止日期為止。核心終止支援後，Google 不再提供支援，執行這類核心的裝置會被視為有安全漏洞。

自核心 6.6 起，穩定版核心的支援生命週期為 4 年。

下表列出支援的 ACK 的生命週期：

常見核心測試

除了供應商的下游測試外，常見的 Kernel 也會透過多個 CI 系統進行測試。

Linux Kernel 功能測試

Linux Kernel Functional Test (LKFT) 會在一組實體 arm32 和 arm64 裝置上啟動各種測試套件，包括 kselftest、LTP、VTS 和 CTS。您可以在 android-lkft 頁面查看最近的測試結果。

KernelCI 測試

每當有新修補程式提交至通用核心分支版本時，系統就會啟動 KernelCI 建構與啟動測試。我們在各種開發板上測試並啟動了數百種建構設定。如要查看 Android 核心的近期結果，請前往 KernelCL 網站。

Android 預先提交和提交後測試

預先提交測試可防止失敗導入 Android 通用核心。您可以在 Android 通用核心 Gerrit 中，程式碼變更的「Checks」分頁中找到測試結果摘要。

當新修補程式提交至 ci.android.com 的 Android 常見核心分支時，Android 會在 Android 常見核心分支中，對新發布的建構版本執行提交後測試。在 ci.android.com 中輸入 aosp_kernel 做為部分分支名稱，即可查看核心分支清單和可用結果。舉例來說，您可以在 android-mainline 的Android 持續建構整合 (Android CI) 資訊主頁中找到結果。按一下特定建構版本，即可在「Test Results」分頁中查看測試狀態。

Android 平台原始碼樹狀結構中，由 test-mapping 定義的測試 (測試群組為 kernel-presubmit)，會以 Android 核心分支的預先提交測試形式執行。舉例來說，test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING 中的下列設定會在 Android 通用核心程式碼簽入時，啟用 vts_kernel_proc_file_api_test 做為預先提交測試。

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

0-day 測試

0 天測試會在提交新修補程式時，對所有 Android 通用核心分支進行逐一修補程式測試。系統會執行各種開機、功能和效能測試。加入公開群組 cros-kernel-buildreports。

測試矩陣

為 Android 常見核心做出貢獻

一般來說，功能開發應在主線 Linux 上進行，而非 Android 通用核心。我們強烈建議您進行上游開發，開發內容通過審查後，即可視需要回溯移植到特定 ACK 分支。Android 核心團隊很樂意支援上游化工作，為 Android 生態系統帶來益處。

將修補程式提交至 Gerrit，並遵守這些貢獻規範。