#0 说在前面

本系列文章以非C语言开发者的角度编写，且假设你已经会内核编译的基本流程，后续内容随缘更新。本文当前为第3版，更新于2025-05-10。

#0.5 战斗准备

开始战斗前的物质准备：

硬件：一台多核性能不是太差的电脑
Linux环境：单独安装或WSL均可
Clang编译器：推荐最新Neutron Clang，ZyC Clang 21会导致小米系统无法正常显示内核版本，故建议避雷
AOSP GCC交叉编译器：默认最新（在这里找最新标签，标签格式为“android-xx.x_rxx”）
git相关使用方法（多分支管理、rebase、cherry-pick等）

以及3个小提示！

为了方便后期进行cherry pick等操作，强烈建议在条件允许的情况下，以git clone的方式将内核源码复制到本地，而非通过下载内核源码的压缩包。
即使源码只能以压缩包形式获取，也建议通过git init命令将其初始化为一个git仓库。
为了方便我们在工作时敲代码或校对或解决冲突或写出规范commit，推荐使用VSCode。

当然，最重要的，是一颗沉静得下去的耐心。

#1 寻找可编译成功的内核源码

此处“可编译成功”指编译过程中不会因为源码的bug而中止，且编译后的内核可以正常开机。

确定哪些源码能用

首先我们打开手机设置，在“关于本机”中确认内核的大版本号——Linux的版本号（即数字部分）为x.y.z结构，但它并不遵守语义化规则。其中x.y在本系列文章中规定为“大版本号”或“主线版本号”，z规定为“小版本号”或“基线版本号”。

举个栗子，有个手机打开系统设置后查询到内核版本如下：

则可以确定其大版本号为5.15。

大版本号 ≥ 5.10的内核为支持GKI 2.0的内核，以下为方便简称GKI内核；大版本号<5.10的内核不支持GKI或仅支持GKI 1.0，以下简称非GKI内核。

首先，不管是什么情况下，首选手机厂商提供的内核源码。

小米&红米：MiCode/Xiaomi_Kernel_OpenSource (GitHub)
一加：OnePlusOSS (GitHub)
oppo：oppo-source (Github)
真我：realme-kernel-opensource (GitHub)
华为：Huawei Open Source Release Center
vivo：vivo Open Source
荣耀：opensource - HONOR
中兴ZTE：Opensource

但是部分厂商在开源时移除或修改了部分源码，使编译无法顺利完成，或编译后无法引导系统（OPPO及子品牌系列将dtbo换为官方的即可开机）。考虑到本文读者应该不具备修复相关bug的能力，此处就需要另寻仓库。对于大版本为5.10及以上的高通机型，可以直接选择来自高通的源码。

5.10：clo/la/kernel/msm-5.10 - CodeLinaro
5.15：clo/la/kernel/msm-5.15 - CodeLinaro
6.1及以上：clo/la/kernel/qcom - CodeLinaro

（注：高通的内核源码是以tag（即标签）的形式发布的，命名规则请参考#6）

对于其它GKI设备，也可以使用谷歌官方的通用源码，不过问题就是如此会失去SoC厂商和手机厂商的优化。

谷歌通用内核：kernel/common - Git at Google

当然，还有一个全版本通用的方法——在GitHub上找寻设备的第三方源码。不过这样找到的源码仓库，其性能和续航表现全部依赖于维护者本人的技术水平。

第三方内核的搜索关键词是：“kernel_<手机厂商名>_<设备代号>/<SoC代号>"。比如搭载骁龙8 Gen 2的小米13 Pro，手机的代号为nuwa，SoC的代号为sm8550，就需要搜索“kernel_xiaomi_nuwa”或“kernel_xiaomi_sm8550”。

对于非GKI设备的第三方内核，这些内核中有的只能供类原生（即OSS vendor的系统）使用，有的只能供官方系统（即官方vendor的系统）使用，一般会标注在项目简介内，可根据自己需要去选择。

开始编译！

接下来就是内核编译的过程，网上教程很多，这里暂不赘述。看到控制台输出这个，就说明编译成功~

本图仅作参考，我们一般平时编译的Android内核是面向ARM64设备的，绝大部分内核编译产物是一个Image.gz-dtb或Image.lz4文件

至于如何刷入内核，可以参考：[基础教程2]如何使用AnyKernel 3打包内核

#2 了解commit规范

安卓内核既然也是Linux内核的一种，那么其commit规范也会受到约束。~~（虽然你不遵守规范也没人追究）~~一般情况下，一条标准的Linux内核的Git commit消息应当如下所示。

[scope]: [subject]

[description]
(可选，对于个人项目，确实写不出来或没必要可以不写
但如果要贡献给Linux或AOSP上游，则要越详尽越好)

[signature]

比如linux@3cc4e13：

请注意，对我们而言，规范的commit信息的最主要的意义在于让我们在后期的优化时读懂别人在干什么，同时也要让别人读懂我们在干嘛。

scope

此处scope即作用域，表示修改的地方，如某个特定的功能。若无法确定，则一般情况下取作出的修改所在的目录即可，且一般不超过两层。如上图的commit仅修改了cgroup控制组，则scope为“cgroup”。

如果有多个scope，则需要用英文逗号隔开，如linux@c6f53ed的scope就是“mm, memcg”。

如果修改的是编译配置（保存在arch/<架构>/configs目录），则scope应为对应的defconfig，如kerneltoast/android_kernel_google_zumapro@3bd1027的scope就是“zumapro_defconfig”，而该机型的架构为“arm64”，代号刚好为“zumapro”。

如果修改覆盖的范围较广，或修改内容涉及很多方面，则scope应为"treewide: "，如kernel_common@dab2144。

如果该commit是从上游（即主线或更高版本的基线）移植下来的，即反向移植（backport），则scope前应加上“UPSTREAM: ”，如kernel_common@0c24e4d。

如果该commit的内容来源于非Linux官方仓库，则scope前应加上“FROMGIT: ”，如kernel_common@489cecd。

subject

此处subject可理解为简述，即将所做的更改用一句简短的话表达出来，记得首字母大写2333~

signature

由于我们只是进行个人项目的开发，故signature部分仅保留署名（即sign-off）部分即可。在VSCode的设置中搜索“sign off”，打开“Always Sign Off”即可在每次提交时自动署名。

如果该commit还有他人参与，别忘了在最末尾加上个Co-authored-by。

#3 自定义内核本地版本号

既然知道了commit规范，那么我们先来改改本地版本号练练手吧！

本地版本号说白了就是给内核版本加后缀，使其具有辨识度，这也是很多第三方安卓内核所会做的。咱可以从手机设置里查阅，或和Linux发行版一样通过在终端输入uname命令查询内核版本：

u0_a240@localhost ~ > uname -r
5.15.148-android13-8-00004-ge488687c12ef-ab11838684

在这个例子中，“android13-8-00004-ge488687c12ef-ab11838684”这个后缀就是内核的本地版本。

而这个后缀可以通过.config或defconfig（文件位置见scope处）这2个文件中的1个进行修改，它们都是编译的配置文件。像编译时间或内核版次等经常变动的字串，建议在.config文件中修改，以防止原defconfig被git追踪带来的麻烦；而像内核名称之类的固定内容则建议在defconfig中修改。

注：此处.config仅指在编译前执行make xxx_defconfig后在根目录产生的.config配置文件。

直接查找文件中的CONFIG_LOCALVERSION条目，有就修改，没有就加上，记得值用英语的双引号包起来就行。

# defconfig 部分配置
CONFIG_LOCALVERSION="-Rudeus"

# 修改并直接编译后内核运行uname -r命令结果
5.15.148-Rudeus-android13-8-00039-g36ed888b10-dirty

为毛我们自定义的“-Rudeus”本地版本后边还有一串呢？在CONFIG_LOCALVERSION配置下边还有一个CONFIG_LOCALVERSION_AUTO，这个条目开启后可以在编译开始时检测当前版本控制工具（如git、svn等），通过它追踪编译时的版本（即该commit所对应的独一无二的hash值）并将版本写入到内核版本中。如果你的修改没有提交给Git，还会再加上一个“-dirty”后缀。喜欢就加上，不喜欢就关掉，例如我使用以下defconfig配置：

# 此处关掉了默认打开的CONFIG_LOCALVERSION_AUTO
CONFIG_LOCALVERSION="-Rudeus"
# CONFIG_LOCALVERSION_AUTO is not set

# uname -r 命令运行结果
5.15.148-Rudeus

接下来，提交你对defconfig的修改。

git commit -m "defconfig: Rename kernel to Rudeus" --signoff

大功告成！恭喜你已经自己做出了第一个commit！

#4 集成KernelSU

为方便演示，此处以官方分支的KernelSU举例，其它分支同理。部分KernelSU分支可能会有其它要求，以其文档为准。

KernelSU允许我们通过KPROBES以驱动的形式集成进内核中，所以需要事先在defconfig中启用它。

# defconfig 部分配置
# 如果已经有了的配置项请勿再写一次
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y

为了方便后期更新，以及托管平台的管理，我们不采用KernelSU提供的一键集成脚本，而是直接clone到本地。进入drivers/staging目录（要在外层也行，看你心情）克隆KernelSU。

cd drivers/staging
git clone https://github.com/tiann/KernelSU kernelsu

并将KernelSU设为本内核项目的子模块，在根目录创建.gitmodules，添加：

[submodule "drivers/staging/kernelsu"]
	path = drivers/staging/kernelsu
	url = https://github.com/tiann/KernelSU.git

接下来分别修改drivers/staging目录下的Makefile和Kconfig，添加KernelSU条目即可。（绿色背景色代码为需要在对应文件中添加的内容）

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index cc9d9fa0e1e38..ecfd48f4fa93 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -102,4 +102,6 @@
source "drivers/staging/wfx/Kconfig"

+source "drivers/staging/kernelsu/kernel/Kconfig"
+
endif # STAGING


diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index cc9d9fa0e1e38..ecfd48f4fa93 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -41,3 +41,4 @@
obj-$(CONFIG_QLGE)		+= qlge/
obj-$(CONFIG_WFX)		+= wfx/
+obj-y					+= kernelsu/kernel/

最后，提交commit，在编译时选择启用KernelSU，大功告成！

#5 合并AOSP上游代码

绝大多数情况下，同一个设备的Android内核因驱动迁移难度大，只能局限在一个LTS大版本内，所以我们通常需要将该大版本下对应的Linux上游合并进来，以使环境更安全、并获取更新的从新版内核特性。这就是“更新基线”或“合并上游”。

绝大多数情况下，只要保证大版本一致，进行合并后几乎不会遇到无法引导的情况。

首先添加AOSP的内核源码仓库，并且拉取你内核所在大版本（非GKI）或KMI版本（GKI，KMI版本是什么？）的对应的基线分支。以下是列出一些基线分支的名称。

4.4：deprecated/android-4.4-p
4.9：deprecated/android-4.9-q
4.14：deprecated/android-4.14-stable
4.19：deprecated/android-4.19-stable
5.4+：androidxx-y.z-lts（此处星号需要与你手机GKI内核的KMI版本匹配）

# 由于谷歌代码库在大陆访问不便，此处使用清华大学TUNA的AOSP镜像源
git remote add aosp https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/kernel/common.git

# 假设手机的内核是5.15.148-android13-8-...
# 那么需要拉取的分支是android13-5.15-lts
git pull aosp android13-5.15-lts

然后以AOSP的分支为基础，切换到一个新的分支，我自己一般命名为base-aosp，表示该分支的内容就是AOSP的基底/基线。

git switch aosp/android13-5.15-lts
git switch -c base-aosp

现在，AOSP基线的分支就处理好了。切回到原分支并合并它！

# 假设原分支名为dev
git switch dev
git merge aosp/android13-5.15-lts

如果合并时出现冲突，建议通过VSCode解决冲突，一般情况下全部选择传入。合并时的信息无需遵循commit规范，只用默认的“Merge 'xxx' into xxx”即可。

#6 合并SoC厂商上游

由于其它主流移动设备SoC厂商不直接开源或直接不开源上游，此处只讨论高通的情况。

这是一个可选项，但合并高通的内核源码也能让内核的驱动得到更新、调度得到优化。最重要的是，通过更新的设备树和bpf等，能使内核支持的Android版本得到提升。

确认源码标签

文中提到的标签具体数据可能因时间而变动，此处仅供参考，请以实际情况为准。

由于高通每次将发布源码发布至内核仓库的特定标签中，故需找到对应标签后再pull并merge。

对于非GKI内核，其tag命名格式为LA.UM.x.y.cz-abc00-平台名称.0（粗体部分为固定内容），x.y为平台版本号，z和abc也是版本号但意义不明，一般来说版本号越大，内核越新，内置驱动越新，优化越好，且越靠前优先级越高。

由于非GKI设备的内核不通用，故需要注意选择的tag所适用的平台是否与自己的设备匹配，如平台为SMx150的tag编译出来的内核只能在骁龙855（SM8150）或骁龙675（SM6150）上运行。

有遇到带QSSI后缀的tag，可暂时浅显理解为最高支持的安卓版本。

对于GKI内核，其tag命名格式为KERNEL.PLATFORM.x.y.rz-0ab00-kernel.0，版本规则同上。但需要注意：x不同，适用的平台和内核大版本均会不同，但该大版本下所有SoC都可通用这套源码。

x=1 → 大版本号5.10，平台SMx450
x=2 → 大版本号5.15，平台SMx550
x=3 → 大版本号6.1，平台SMx650
......

实操步骤

首先将高通的内核源码拉取到本地并合并，这里以驱动骁龙8Gen2的5.15举例。

# 添加高通的5.15通用内核仓库
git remote add qc https://git.codelinaro.org/clo/la/kernel/msm-5.15.git

# 拉取高通代码到本地
git pull qc KERNEL.PLATFORM.2.0.r35-01100-kernel.0
git merge qc/KERNEL.PLATFORM.2.0.r35-01100-kernel.0

一般情况下，只要合并AOSP上游完成后，再合并高通上游，是不会出现冲突问题的，可放心食用。

#7 如何简略地优化内核？

由于专业知识的欠缺，所以我暂且把“性能优化”拎成几个小的方面：

简易的配置项修改（这也是我们为数不多能够自己参与的优化项目）
“援引”他人的优化类目

手动调整部分配置项目

ZRAM

简而言之，ZRAM技术是通过压缩算法（一般是LZ4）将内存中指定的数据进行压缩，其实质是以牺牲CPU性能来换取内存。

ZRAM的配置及实现源码在drivers/block/zram/zram_drv.c，然而对于基础知识尚且不足的我们，能够修改的只有ZRAM的大小。但是请注意，ZRAM的大小不要超过实际内存大小，否则可能会导致意外发生（逃

ZRAM大小的数据通常在上述文件中if (!disksize)的上一行。

@@ -1725,7 +1725,7 @@
int err;

-disksize = memparse(buf, NULL);
+disksize = (u64)6144 * SZ_1M;
if (!disksize)
    return -EINVAL;

像这样就是将ZRAM固定为6GB。

Swappiness

swap即交换分区，它是手机存储上开辟的一小块空间，在内存使用量达到一定值时临时充当内存的作用。而swappiness就是调整swap分区启用阈值的参数，则可以在mm/vmscan.c中通过vm_swappiness进行修改。

@@ -191,7 +191,7 @@
 * From 0 .. 200.  Higher means more swappy.
 */
-int vm_swappiness = 60;
+int vm_swappiness = 160;

static void;

“援引”他人优化类目

~~优化的核心是借鉴。——鲁迅根本没说过这句话~~

毕竟专业知识不足，使用他人造的轮子并非可耻之事。那么我们应如何使用他人的优化项目呢？

这就要提到我们后续进行绝大多数优化工作的工具——cherry pick——它能从其它分支中pick出你设定的commit到你所在分支上，我们可以通过它来拣选他人的优化commit并应用到自己的内核上。

首先将他人的内核仓库设置为远程仓库，pull下来即可

# 假设存在一个第三方内核项目，主开发分支为dev-14，优化commit从129ffd0到ec6caa5
git remote add miracle https://github.com/Project-Miracle/android_kernel_xiaomi_raphael
git pull miracle/dev-14
git cherry-pick 129ffd0...ec6caa5 -x

此时我们就可以看到，我们自己当前所在的分支上多出了几个commit，它们就是从另外那个分支上cherry pick下来的。

不过在实战情况下，建议以

替换或更新原内核的部分功能

注：此“模块”指实现特定功能的一系列单一功能的代码，并非“Linux内核模块”。

就拿经常被第三方内核拿来做ZRAM压缩的zstd举个栗子吧，它存放在lib/zstd目录下，而且绝大多数情况下不受Linux版本的影响。首先找一个zstd更新了的内核仓库，比如ferstar/xiaomi_xaga_kernel，先pull下来，同时再打开对应的目录的commit历史记录，只要不是AOSP或Linux官方的commit，均为优化或更新项。

按照cherry pick的方法一个一个pick就行，更新功能就这么简单。理论上来说，现在你的zstd肯肯定定能够正常编译成功了！其它相关的库大致也是这个样子。

更新内核部分驱动

高通将内核源码开源到CodeLinaro的同时，也开源了配套的Wi-Fi等驱动的源码。我们可以通过更新驱动来提高各部件工作的稳定性和性能。

🚧 施工中......

最后祝各位一路顺利！

好耶，终于写完第一篇了！（躺）（叹气）