安卓内核编译实战：从源码到boot.img的完整流程与避坑指南

手机到手之后，我第一个想动的地方就是内核。这话听起来很geek，但对于玩安卓的人来说，编译内核算是一道绕不过去的门槛。最近在整理一套坚果R1配魔趣MK100（Android 10）系统的构建环境时，我把整个流程重新走了一遍，从源码拉取、交叉编译到打包刷机，零零散散折腾了不少时间。这篇文章就拿这套组合当样板，把一条可以直接复现的路线给你讲透，顺便说说那些文档里不会写的坑。

先说清楚这篇文章适合谁：如果你的设备刚好是骁龙845这一档的机器，或者你手里的手机有对应的开源内核分支，那这篇文章可以直接给你当操作手册；如果你只是想搞清楚安卓内核是怎么从源码变成boot.img的，同样可以拿这套流程当解剖样本。我会尽量把背后的原理也讲明白，不是给你一堆命令让你照着按，而是让你知道每一步为什么要这么做。

1. 编译前的整体设计与方案选型

1.1 为什么要自己编译安卓内核

大多数普通用户根本不需要碰内核，原厂固件里那颗内核完全够用。但一旦你遇到下面几种情况，自己编译内核就变成刚需：

• ROM合入的驱动补丁没跟上官方内核版本，导致某些模块加载不了，比如Wi-Fi掉速、指纹偶尔失灵。
• 你手上这台机器被官方“放养”了，系统更新停了，但内核里的老Bug还在，比如某个CPU调频策略在特定负载下明显卡顿。
• 你想把内核裁剪到只剩自己需要的驱动，减少不必要的耗电和攻击面。
• 你想给内核加一些第三方功能，最常见的例子是加入新的网络调度器、文件系统支持，或者自定义的TCP拥塞控制算法。

我这次编译的动机很简单：魔趣MK100（Android 10）在某些场景下对触摸响应和温控策略有修改需求，我需要一套能自己维护、自己迭代的内核，而不是只能等别人适配。魔趣这个开源项目的内核分支比较干净，版本对应关系也清楚，拿来做基础再合适不过。

1.2 版本匹配：坚果R1、MK100与Linux内核的关系

编译内核最忌讳的就是“版本不对齐”。很多人在第一步就栽了，拉了源码直接编，刷进去才发现开不了机，或者开机后基本功能罢工。

坚果R1用的是骁龙845平台，这颗SoC在高通产品线里属于比较成熟的一档，配套的Linux内核版本基线一般是4.9。魔趣MK100虽然把用户空间升级到了Android 10，但内核并没有跟着大跨步升级，仍然沿用4.9这条线，只是合入了大量高通的平台补丁和魔趣自己的改动。这一点非常关键，它决定了你选源码分支时不能乱选。

我用的匹配关系是这样的：

• 设备：坚果R1（对应设备代号在MK100的device配置里能看到，常见的是基于sdm845平台）
• ROM版本：魔趣MK100，也就是Android 10的发布线
• 内核基线：Linux 4.9
• 编译系统：面向Linux主机的AOSP交叉编译环境

这里有个判断技巧：打开手机设置里的“内核版本”一栏，看到“4.9.x”字样，基本就能确认你的设备在这条内核基线上。魔趣的版本号里也会直接写明“MK100”，和Android版本对应得很好。

1.3 硬件与系统环境准备

编译安卓内核不是一件吃内存的活，但磁盘和CPU线程数乐观一点会舒服很多。以这次项目为例，我的编译主机是普通桌面Linux机器，双核四线程的CPU，16GB内存，机械硬盘，算很寒碜的配置了。整个单次编译大概十几分钟到半个多小时，取决于你改动了多少代码。

推荐环境：

• 操作系统：Ubuntu 20.04或22.04 LTS，其他发行版也可以，但依赖包名略有差异。
• 磁盘空间：源码解压后约10GB，编译中间产物再占10GB左右，建议预留30GB。
• 内存：4GB起步，16GB体验良好。
• 网络：需要能从源码仓库拉取代码，这是唯一的网络需求。

如果用的是Windows，我不建议直接在原生环境里搞，最省事的方法是开一台虚拟机装Ubuntu，或者用WSL2。但WSL2里处理USB直通刷机较麻烦，所以刷机阶段还是准备一个真机Linux环境或者把刷机放到Windows下的fastboot工具里做。这个后面章节再细说。

2. 源码获取与处理

2.1 从开源仓库拉取MK100对应的内核源码

魔趣的内核源码仓库维护了多个分支，分支命名通常会带版本信息。我这次用的是对应MK100的4.9分支，大概的拉取流程是这样：

git clone https://github.com/MoKee/android_kernel_sdm845.git -b mk100 cd android_kernel_sdm845

这个命令里的-b mk100可以理解成“把分支切到MK100相关的维护线”。实际分支名可能会带具体设备后缀，比如sdm845或者nuty之类的代号，你需要在仓库的Branch列表里找到和MK100对应的那条。

这里有一个值得注意的点：源码拉下来后，不要急着编。先看一眼根目录下的Makefile，确认版本号：

head -n 4 Makefile

如果你看到类似下面的内容：

VERSION = 4 PATCHLEVEL = 9 SUBLEVEL = 253 EXTRAVERSION =

就说明你拿到的确实是4.9内核，和MK100的设备端预期一致。如果这里显示的是5.x甚至6.x，那你就要警惕是不是分支选错了，或者仓库已经切换到更新版本的适配线。版本不对的话，后面编译和刷入就会出现各种电源管理、传感器驱动不匹配的问题。

2.2 提取设备当前内核配置

安卓内核和桌面Linux内核一样，编译前需要一个.config文件，里面记录了成千上万个内核功能开关。直接在手机上用defconfig是可行的，但更稳妥的办法是从当前运行的内核里把配置原封不动提取出来，这样能保证你编出来的内核至少能继承原来具备的所有功能。

操作前提是手机已经开启了USB调试，并且系统本身支持配置导出。魔趣系统默认是支持CONFIG_IKCONFIG_PROC的，所以你可以直接在adb shell里这样拿：

adb shell zcat /proc/config.gz > kernel_config

如果你的ROM不支持/proc/config.gz，还可以通过下面的方式拿到等效配置：

adb pull /sys/kernel/config # 并非所有设备都有

更通用的替代方案是：把你当前用的boot.img解包，从解出来的kernel二进制里提取config。但那样需要额外的逆向工具，比较麻烦。所以我在实际操作中更推荐先检查/proc/config.gz，90%以上的第三方开源ROM都会打开这个开关。

拿到kernel_config之后，把它替换到源码根目录的.config：

mkdir -p out cp kernel_config .config make ARCH=arm64 mrproper cp kernel_config .config

这里的mrproper是内核构建系统里的“彻底清理”目标，它会把之前所有残留的中间文件清掉。先清理再放入提取的配置，可以避免旧配置残留选项对这次构建造成干扰。

2.3 确认驱动模块与内建选项

配置提取搞定后，先别急着编，建议做一步检查：打开.config，确认你要用的核心驱动确实是=y（内建）或者=m（模块）。

以安卓手机最常用的几个功能为例：

• CONFIG_DEVTMPFS=y：/dev目录的临时文件系统，安卓启动必需。
• CONFIG_ANDROID=y和CONFIG_ANDROID_BINDER_IPC=y：Binder通信机制，Android的基础设施。
• CONFIG_FB_MSM=y或对应的显示驱动项：屏幕显示相关，骁龙平台上通常是高通显示驱动。
• CONFIG_TOUCHSCREEN_*：触摸屏驱动，不同模组有不同选项。

一般情况下，从/proc/config.gz提取的配置已经包含了这些正确选项，你只需要在改动功能时注意别把某些依赖项误关掉。我自己习惯在改动前先备份一份kernel_config_original，万一编出来的内核有问题，还能回头比对到底改了什么。

3. 交叉编译环境与工具链

3.1 用Clang还是GCC：Android 10的默认选择

安卓内核的编译方式和桌面Linux不太一样，它一定要用交叉编译工具链，也就是在x86主机上编出arm64架构的二进制。早些年大家都用GCC，工具链是从android-ndk里抽出来的aarch64-linux-android-4.9。但从Android 10开始，谷歌在官方内核编译流程里默认使用Clang，并且强制要求很多配置项必须由Clang处理，GCC的地位基本退居到“备用”和“某些厂商分支残留”的位置。

所以这次编译我选定的是Clang工具链，具体版本我用了AOSP预编译的clang-r365727。这个版本和Android 10的官方构建时间线匹配，是编译4.9内核时经过充分验证的选择。太新或者太老的Clang都可能报奇怪的错误，比如unsupported option或者inline asm语法不兼容。

你可以从AOSP的prebuilts/clang/host/linux-x86仓库拉取，也可以直接找对应版本的压缩包解压，命令行大约是这样：

wget https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/master/...

实际下载地址用仓库里的对应路径即可，这里不展开碎碎念了。如果不想折腾Clang版本，直接用发行版自带的clang也大概率能编过，只是要小心版本太新导致的汇编级兼容问题。

3.2 配置环境变量

交叉编译环境的核心就是环境变量。下面这套是我在bash里export的配置：

export ARCH=arm64 export SUBARCH=arm64 export CC=clang export CROSS_COMPILE=aarch64-linux-gnu- export CROSS_COMPILE_ARM32=arm-linux-gnueabihf- export PATH=$PATH:/path/to/aarch64-linux-android-4.9/bin:/path/to/clang-r365727/bin

解释一下几个变量的含义：

• ARCH=arm64：告诉内核构建系统，目标平台是64位ARM架构。
• SUBARCH=arm64：和ARCH保持一致，某些脚本会区分宿主架构和目标架构。
• CC=clang：指定编译器为Clang，这是Android 10内核编译的关键。
• CROSS_COMPILE=aarch64-linux-gnu-：指定交叉编译工具链前缀，链接器、汇编器、objcopy等工具都会自动加上这个前缀。
• CROSS_COMPILE_ARM32：因为32位辅助进程或某些驱动还需要32位工具，所以一并配上。

提示：这里必须有32位交叉工具链，因为内核编译过程中可能要处理ARM32的compat相关代码，没有它会在链接阶段报arm-linux-gnueabihf-ld: cannot find -lgcc之类的错误。

依赖包也别漏，Ubuntu下直接装：

sudo apt install git build-essential flex bison libncurses-dev libssl-dev libelf-dev

其中libncurses-dev是给make menuconfig用的，libssl-dev是编译内核模块时处理模块签名需要的，libelf-dev则服务于那些需要解析ELF文件的内核工具。

3.3 一个容易被忽略的细节：LLVM=1

Android 10时代的内核编译，很多时候不仅要给CC=clang，还需要给上LLVM=1，让构建系统知道连汇编器、链接器也全部使用LLVM工具链里的对应程序。比如：

export LLVM=1 export LLVM_IAS=1 export LD=ld.lld

这样设置的好处是避免了GNU工具链和Clang混用时的版本错位问题。特别是在高版本Clang编译老内核时，使用GNU的GAS汇编器有时会因为语法解析差异冒出莫名错误，直接统一成LLVM工具链反而更省心。

但这里有个变数：如果你用的Clang版本比较老，它内嵌的LLVM_IAS（集成汇编器）对4.9内核的某些汇编语法支持不到位，反而需要用GNU汇编器。我的建议是：优先保持“Clang + 对应版本的AOSP GCC工具链”这套官方组合，编译过程中遇到汇编错误再考虑是否切LLVM=1，不要一上来就全栈LLVM。

4. 内核配置与编译

4.1 生成最终配置

如果你从手机上提取的.config在版本上完全可用，理论上可以直接编译。但为了稳妥，我建议执行一次配置刷新流程：

make ARCH=arm64 O=out oldconfig

O=out是指定输出目录，把编译产物和源码分开，这样源码目录始终保持干净，想重新编译时直接清理out即可。oldconfig会根据新的源码自动检查已有.config，如果某些选项在新源码里被删掉或者改了默认值，它会逐个询问你。

这里要注意，在非交互环境下，oldconfig可能会卡在某个提示上等你输入。如果你不想一个个选，可以直接：

make ARCH=arm64 O=out defconfig

但defconfig是设备默认配置，不一定和你提取的config一致。更好的做法是确定好需要保留的改动后，手动用menuconfig去调：

make ARCH=arm64 O=out menuconfig

menuconfig是文本图形界面的配置工具，用方向键、空格和回车就能勾选模块。我通常用它检查三类配置项：

• Device Drivers下的传感器、显示、触摸、音频驱动。
• Networking support下有没有我需要的网络功能。
• Kernel Features下的Preemption Model等调度相关选项。

菜单界面比较适合人类阅读和修改，但大量配置项还是要靠文件级diff来管理。总之一句话：extracted_config是保底，menuconfig是微调，oldconfig是对齐版本差异。

4.2 开始编译：从零到Image.gz-dtb

配置就绪后，进入编译环节。如果你是第一次跑4.9内核，建议先把并行度调低一点，比如-j4，确认整个流程能走通后再提高。

make ARCH=arm64 O=out CC=clang CROSS_COMPILE=aarch64-linux-gnu- -j4

如果环境变量已经export过，命令行可以精简为：

make O=out -j4

编译过程中，屏幕上会滚动输出大量编译日志，你会看到类似下面的行：

CC init/main.o CC kernel/printk/printk.o LD init/built-in.o CHK include/config/kernel.release

第一次编译4.9内核，如果配置项比较多，耗时可能在10到40分钟之间。编译完成后，最关键的两个产物在out/arch/arm64/boot/下：

• Image.gz：压缩过的内核镜像。
• Image.gz-dtb：内核镜像拼接设备树（Device Tree Blob）后的完整镜像。

刷机包里的kernel基本就是这个Image.gz-dtb。如果只生成Image.gz没有看到dtb项，可能是设备树的配置目标没编进去，需要检查CONFIG_OF=y以及高通的设备树编译规则是否启用。

编译内核模块的命令是：

make O=out modules make O=out INSTALL_MOD_PATH=./modules modules_install

但安卓启动时通常会把必要驱动编成=y，不太依赖/system/lib/modules下的外部模块。所以我这次没有单独处理模块安装，保持内核内建即可。

4.3 编译期间的经验笔记

几个值得记下来的点：

第一，不要开着-j超过物理核心数太多。4.9内核的某些汇编文件在并行编译时偶尔会出现竞态问题，表现为“随机”报错，但重编又好了。用-j$(nproc)已经足够，无需加倍。

第二，老内核对高版本主机的兼容性是个大坑。我遇到过一个典型问题：Ubuntu 22.04自带的binutils版本过高，导致objcopy生成的镜像在手机端无法启动。后来单独拉了一套AOSP的aarch64-linux-android-4.9/bin，问题立刻消失。所以如果你用的是很新的发行版，不要吝啬，把官方工具链目录放到PATH最前面。

第三，编译日志建议留档。我个人习惯是这样：

make O=out -j4 2>&1 | tee build.log

后面如果刷机出问题，通过搜索build.log里的warning和error能快速定位是不是编译阶段就埋了雷。

5. 打包boot.img与刷入

5.1 boot.img的结构拆解

安卓设备的boot分区存放的不光是内核本身，而是一个复合镜像。标准结构大致是这样：

• 头部（boot header）：存放内核大小、ramdisk大小、页面大小、命令行等元数据。
• 内核镜像：就是上一步编译出来的Image.gz-dtb。
• ramdisk：一个gzip或lz4压缩的根文件系统镜像，里面装着init、init.*.rc等启动脚本。
• 有时还有第二阶段的ramdisk或者额外的DTB，这要看设备方案。

所以你不能直接把Image.gz-dtb扔进fastboot flash boot。正确的做法是：把原boot.img解包，替换里面的内核部分，再重新打包成新的boot.img。

网上常说的“fastboot flash boot boot.img”，boot.img指的就是这个打包完成后的复合文件。

5.2 用unpack_bootimg和mkbootimg完成打包

我处理的流程大致是这样。先准备两个工具，一个是解包用的unpack_bootimg，一个是打包用的mkbootimg，在AOSP源码的system/tools/mkbootimg目录下可以找到，也可以单独编译。

先解包原boot.img：

unpack_bootimg --boot_img original_boot.img --out boot_unpacked

解包后目录里应该有：

• kernel：原始的内核镜像。
• ramdisk：ramdisk目录或压缩文件。
• bootimg.cfg：记录了原始的cmdline和分区参数。

关键一步：备份并替换kernel：

cp boot_unpacked/kernel kernel_old.bak cp out/arch/arm64/boot/Image.gz-dtb boot_unpacked/kernel

然后重新打包：

mkbootimg --kernel boot_unpacked/kernel \ --ramdisk boot_unpacked/ramdisk \ --cmdline "xxxxxx" \ --base 0x00000000 \ --pagesize 2048 \ --dtb boot_unpacked/dtb \ --dtb_offset 0x01f00000 \ --os_version 10 \ --os_patch_level 2020-01-05 \ --header_version 2 \ --output new_boot.img

里面的参数不能想当然写，必须从bootimg.cfg里原样抄：

cat boot_unpacked/bootimg.cfg

我遇到过一些人随手填了--base 0x10000000，结果刷进去直接黑屏，因为高通平台的ramdisk加载地址和tags地址全都不对。务必用原boot.img的参数。

如果bootimg.cfg里没有记录dtb_offset，但解包目录里有dtb文件，默认可以给一个经验值0x01f00000，或者直接从设备的fstab和dtsi里查。但最保险的方式还是先原样打包一个“只替换内核、其他完全不变”的boot.img，保证首次能开机，再逐步调整。

5.3 刷入前的备份和刷入操作

刷内核是有风险的操作，我一般遵循“三个备份”原则：

1. 备份当前系统的所有用户数据：adb backup或者用系统自带备份，确保万一要回退时不至于丢数据。
2. 备份原boot.img：adb shell dd if=/dev/block/by-name/boot of=/sdcard/boot_original.img，或者用adb pull到电脑。
3. 备份当前/proc/config.gz：方便回退时重新提取配置。

如果手机解锁了bootloader，那刷入操作就是一条命令的事：

fastboot flash boot new_boot.img fastboot reboot

刷完后第一时间验证内核版本：

adb shell cat /proc/version

正常情况下应该能看到类似：

Linux version 4.9.253-xxx (你的用户名@机器名) (clang version ... )

这里有一个细节值得注意：/proc/version里显示的字符串包含了编译时用的用户名、机器名、工具链版本。如果你看到它显示的还是原来的旧信息，说明你刷进去的内核没有生效，很可能是刷错了分区或者boot.img里的内核部分没替换成功。

5.4 首次开机的验证清单

刷完开机后，别急着激动，先按下面这个清单过一遍，能过滤掉90%的明显问题：

• 屏幕显示正常，触摸可响应。
• WiFi能搜到网络并连接。
• 蓝牙能开关。
• 移动数据有信号。
• 相机能打开。
• 指纹识别能用。
• 传感器（陀螺仪、光线感应）有反应。

我编的第一个自定义内核，其他都正常，唯独WiFi打不开，当时排查了大半天，最后发现是.config里少了一个高通WiFi平台驱动选项，而这个驱动默认不开启，必须在menuconfig里手动选上。这种问题从报错日志里很难看明白，最容易栽跟头，所以验证清单务必一项项走。

6. 常见问题与排查技巧实录

6.1 常见报错与解决速查表

我把这次编译和刷机过程中遇到的高频问题整理成表格，方便你直接对照排查。

6.2 卡在开机Logo的排查思路

这是最让人头疼的问题，因为它在设备端不给你任何日志。我的排查路径可以给你参考：

第一步，先确认是不是原来的boot.img本身就能开机。如果原包能开，你替换内核后不能开，那问题大概率出在内核配置或者设备树匹配上，而不是打包流程。

第二步，尽可能抓内核日志。这需要设备端支持，通常我们可以在fastboot模式下用：

fastboot boot new_boot.img

这条命令不会写入分区，而是临时引导一次。虽然有些机器不支持这个模式，但只要支持，就能快速确认是不是内核本身的问题，而且不会破坏现有系统。

第三步，检查设备树。骁龙845平台的设备树信息很多是编译进内核的，如果内核源码分支里的设备树和MK100的板级文件对不上，开机就会卡死。解决办法是回到仓库看arch/arm64/boot/dts/qcom/下的文件，找到和坚果R1对应的.dtsi。如果你不确定到底该用哪个，最稳妥的办法就是从原内核里提取DTB，再和编译出来的DTB做对比。如果差异很大，说明分支选错了。

6.3 编译环境与源码拉取时的小坑

源码拉取阶段最常见的坑有两个。

一个是仓库的分支名字看着像那么回事，拉下来发现版本和系统对不上。我的建议是先用git branch -a看一下远端全部分支，然后对照MK100的版本号选择。宁可多花五分钟确认，也不要编译完再后悔。

另一个是磁盘空间不够。安卓内核源码本身不算大，但加上repo同步时可能带进的工具链缓存，很容易在构建中途把磁盘塞满。编译时out目录默认就在源码下，建议直接du -sh检查剩余空间，或者用mount挂一块大分区专门放out，例如：

mkdir -p /data/kbuild mount --bind /data/kbuild kernel_source/out

这样可以有效避免因为磁盘不足导致No space left on device的尴尬。

7. 实操过程中我发现的重要原则

7.1 越少改动越容易成功

第一次自己编译内核，最大的错误就是“什么都想开”。实际上，每多开一个实验性配置，就意味着引入了更多未知风险。我在这个项目里的做法是：先原封不动用提取的配置编一版，刷进去确认能开机；然后做一个小改动，比如调整CPU调频策略，再编译刷入；确认稳定后，再继续下一个改动。

这种“小步快跑”的思路，方便你定位问题到底出在哪个改动上。如果第一次就一口气改了十几个选项，出了问题你根本不知道回退哪一个。

7.2 保留一个“原始内核对照包”

在项目目录里，一定要保留三个东西：

• original_boot.img：从手机完整导出的原始boot镜像。
• kernel_old.bak：解包后的原始kernel镜像。
• kernel_config_original：从手机提取的原始内核配置。

这三个文件在你后续折腾过程中就是“后悔药”。遇到诡异问题，随时可以拿它们把手机恢复到出厂内核状态，然后再重新开始实验。我见过有人刷完自定义内核发现WiFi挂了，又找不到原厂boot.img，只好整个系统重刷的人。这个代价完全可以避免。

7.3 学会用源码里的文档和提交记录

魔趣的内核仓库其实很值得读。不要只把它当成一行git clone的结果，多看看它的提交历史，你会发现哪些补丁是为了适配这台设备合入的，哪些是上游安全更新。我在排查触摸驱动问题时，就是在一次commit message里看到“touch: add init sequence for RM module”的描述，才找到需要开启的确切配置项。这种信息比任何论坛帖子都更贴近你的设备。

如果实在找不到对应的提交，也可以去设备树配置里翻。很多板级差异就藏在arch/arm64/boot/dts/qcom/*.dtsi里，看懂它，你基本就摸清了这台机器的硬件禀赋。

8. 这套流程还能怎么扩展

编译出一颗能开机的自定义内核，只是第一步。后续可以做的方向其实很多，我列几个常见的：

• 自定义内核命令行的cmdline参数，比如调整console输出级别、关闭某些安全模块。
• 开启特定的调度器或I/O调度器，针对日常使用做性能调优。
• 加入自己的内核模块，比如一个简单的字符设备驱动，用于读写特定硬件寄存器。
• 升级内核到更新的4.9补丁版本，合入上游安全修复。

这些方向都建立在“能编译、能打包、能刷入、能回退”这套基础能力上。你把这篇文章里的流程跑通一遍，后面再往里加功能，就只是改配置、改代码、重新编译的事。

我个人在实际操作中的体会是：编译安卓内核更像是一门“手艺活”，它的门槛不在命令有多难，而在于你对设备平台、内核版本和构建系统这三者的理解能不能对齐。第一次编过之后，你会发现后续所有折腾都变得可控起来。希望这篇拿坚果R1和魔趣MK100做例子整理的流程，能帮你少走一点弯路。