这篇文章围绕 Pixel 8a（akita），系统梳理 AOSP / GKI 内核源码的获取方式、编译方法、镜像含义、刷机步骤，以及后续源码阅读与调试的常见工作流。
在付出一台Pixel 8a刷成砖的代价下，成功刷入了可以使用ebpf的内核。这篇博客原先只是我零散的笔记，今天让AI帮忙整理下，给有需要的人提供参考。

如果你符合下面任意一种情况，这篇文章会比较适合你：

在开始之前，先记住一句最重要的话：

AOSP 负责系统源码，GKI 负责通用内核基线，vendor 模块和设备树负责设备差异化。

如果你把这句话理解透了，后面的下载、编译、刷机、调试，基本都会顺很多。

很多“编不过”“刷不开机”“不知道该拉哪个仓”的问题，本质上都不是命令问题，而是概念没对齐。

AOSP（Android Open Source Project）是 Android 系统源码本身，主要包括：

你如果想看 SystemServer、AMS、PackageManager、Binder Framework、Java Framework 这些内容，主要是在 AOSP 里。

GKI（Generic Kernel Image）可以理解为 Google 主导维护的 Android 通用内核基线。

它的目标是：

设备最终运行的并不只是“通用 GKI 内核”这一层，还包括：

所以，真正落到设备侧，看到的是一套 GKI + vendor 模块 + dtbo + 多种 boot 分区 的组合，而不是传统时代那种“一个厂商大内核打包进 boot.img”这么简单。

如果你是第一次接触 repo 管理的大仓，这一部分建议先看清楚。

default.xml 来自 platform/manifest 仓库。执行 repo init -u ... 之后，会同步到本地：

这也是 repo 实际展开整棵源码树时所依赖的核心清单文件。

kernel/superproject 不是某一棵具体内核源码树，它更像一个 聚合型 superproject，用于做多内核仓库的统一组织、索引和版本管理。

可以把它理解成“内核仓库世界里的总入口”，但不是你真正写代码、改配置、编译内核的那棵源代码目录。

例如下面这个分支名：

可以拆成四部分理解：

平台源码 manifest：

内核源码 manifest：

Android 12 之前，很多设备更接近“厂商自己维护整棵设备内核”的模式；Android 12 之后，Google 通过 GKI（Generic Kernel Image） 把通用内核基线收拢起来，厂商则更多把差异化能力放到 vendor 模块 和 设备树 里。

这一步非常关键。

实际工作里，很多人会把下面三类内容混为一谈：

所以，先按目标拆开处理。

Pixel 8a OTA 页面：

例如：
这里选择和你手机系统相同版本的ota全量包
我的手机设置里的build版本是 BP4A.260105.004.E1,这里就选择相应的包

提示：如果下载页面打开出现风控，就去找一个有 Google 人机验证的网站，先完成验证再返回下载页面即可。

解包后你通常会拿到：

这些镜像后面刷机会直接用到。

示例版本信息：

拉取命令：

参考：

拉取命令：

由于我们有全量OTA包，驱动可以不下载，这里仅记录

这一部分只聚焦内核本身。aosp的编译网上教程很多，这里就不再赘述了

我是为了使内核支持ebpf,所以增加了一些全局配置
新建以下文件:
//private/devices/google/akita/akita_gki.fragment

在private/devices/google/akita/BUILD.bazel中新增

关于bazel的使用方法，大家可以问AI，这里直接给出可以完全编译出内核的命令

例如，确认 CONFIG_FTRACE_SYSCALLS 是否开启：

如果能查到对应配置，说明最终生成的内核镜像里已经包含该配置。

这部分务必认真看。

编译出的内核产物在此目录下：

另外一部分是我们从ota中解出的产物，原则是运行刷机流程时，如果遇到了没有编译出的镜像，就用oat解出的产物

强烈建议先刷对应版本的厂包或全量 OTA，确保 A/B 分区上的 bootloader 版本一致。

需要特别注意的是：

这一步不是“保险起见”，而是 Pixel 实机刷机时非常关键的前置条件和保险措施。

进入 recovery 后：

执行：

完成后再重启设备，验证是否成功进入系统。

如果你不是只改内核配置，而是要自己编译一个可加载模块，可以参考下面的方式。

具体模块代码可以在我的仓库中找到
f6fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6F1N6h3!0W2L8W2)9J5c8X3E0W2M7X3&6W2L8q4)9#2k6X3#2G2k6s2g2D9k6i4x3`.

到此基本上内核就刷入完成了，如果需要root可以用Magisk等工具来替换ota包中的镜像
pixel 8a 替换的是 init_boot.img

这一部分建议结合刷机一起理解。

从 Android 13 开始，Pixel 系列把原来放在 boot.img 里的通用 ramdisk 拆分到了 init_boot.img。

boot.img 现在主要承载的是 GKI 通用内核镜像，可以理解为：

这是厂商专用 ramdisk，通常包含：

这是 GKI 架构下非常关键的一个分区，常见承载内容包括：

这个分区不要随意替换。

刷写错误可能导致：

ramdisk 是内核启动早期挂载的根文件系统的一部分，常见内容包括：

在 Tensor SoC（Pixel 6 / 7 / 8）体系上，一般可以这样理解：

如果你在分析 ABI、检查可导出符号、验证某个接口是否仍在 KMI 集合内，这一部分会用得上。

特点：

通常用于列出一些基础公共符号，例如：

例如：

如果你的重点是 framework / system 层，建议先把阅读环境搭起来。

生成产物：

可按需调整权限：

这两个文件的作用分别是：

通常如果你只看 framework，可以优先保留：

在 Android Studio 中打开 Project Structure，配置：

必要时删除多余的 class path / source path，减少误跳转。

一般保留下面两类就够了：

如果手动加入 frameworks/base 等目录依赖，建议把它放在 Module Source 之上，否则代码跳转时可能优先跳到生成目录而不是源码目录。

在 Project 视图设置里取消勾选：

在：

删除不必要的目录管理，只保留你真正需要操作的源码路径。

编辑 /etc/sysctl.conf，加入：

然后执行：

在 Android Studio 中进入：

适当把 heap size 调大，否则索引大仓时很容易卡顿甚至 OOM。

调试流程通常是：

如果按钮点击没有反应：

如果你更偏爱轻量工作流，可以直接走 VS Code。

检查输出：

VS Code 的 .vscode/settings.json 可以这样配置：

如果还要阅读 Java 代码，可以补充：

VS Code 配置：

这部分不是本文重点，但作为后续工作流的衔接，保留几个常用模板。

设备端：

主机端：

启动：

适用场景：已经把可执行文件 main push 到设备，希望在主机端远程调试。

设备端：

主机端：

如果程序已经运行，也可以 attach：

注意：

预期输出：

方式 A：

方式 B：

调试时常用命令：

如果你读到这里，建议把整件事重新串成下面这条主线：

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！