Pixel 8a（akita:6.1-android16内核支持ebpf）AOSP / GKI 内核源码获取、编译与刷机实战指南

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

这篇文章适合谁

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

• 想拉取 AOSP 源码 和 Pixel GKI 内核源码
• 想自己编译 Pixel 8a 内核
• 想搞清楚 Android 12 之后 GKI 的交付形态
• 想在 Android Studio / VS Code 中阅读 AOSP 或内核源码
• 想弄明白 Pixel 上各类镜像分区到底分别负责什么

阅读前先建立整体认知

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

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

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

1. 先搞清楚：AOSP、GKI、设备内核分别是什么

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

1.1 AOSP 是什么

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

• framework
• system
• packages
• libcore
• build system
• 一部分通用工具链与平台代码

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

1.2 GKI 是什么

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

它的目标是：

• 把 Android 内核的公共部分收敛到 Google 统一维护
• 保持 ABI / KMI 稳定
• 让厂商尽量把差异化逻辑放到 vendor 模块里，而不是持续维护一棵完整私有内核

1.3 设备内核又是什么

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

• 具体设备相关配置
• 厂商设备树
• vendor kernel modules
• 某些 SoC / 机型相关的 boot 镜像拆分方式

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

2. AOSP 仓库结构与 manifest 是怎么组织的

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

2.1 AOSP 仓库结构

2.2 default.xml 在哪里

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

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

2.3 kernel/superproject 是什么

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

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

2.4 内核分支名怎么看

例如下面这个分支名：

可以拆成四部分理解：

• common：Android 通用内核线（ACK）
• android14：目标 Android 版本
• 6.1：基于 Linux 6.1 LTS
• 2025-09：该时间窗口对应的发布线或维护线

2.5 常用 manifest 仓库

平台源码 manifest：

内核源码 manifest：

3. Android 内核交付方式：Android 12 前后到底变了什么

3.1 一句话理解

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

3.2 整体分层

3.3 Android 12 前后最核心的区别

4. 下载源码前，先明确你要拉的是哪一类代码

这一步非常关键。

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

1. AOSP 平台源码：主要看 framework / system / app / build system
2. Pixel GKI 内核源码：主要看 Pixel 对应分支的 kernel 编译链路
3. 驱动或设备相关发布包：用于补充设备端闭源或发布产物

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

5. 获取 Pixel 8a OTA、AOSP 和 GKI 源码

5.1 下载全量 OTA 包

Pixel 8a OTA 页面：

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

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

5.2 OTA 解包

解包后你通常会拿到：

• boot.img
• init_boot.img
• vendor_boot.img
• vendor_kernel_boot.img
• dtbo.img
• vbmeta*.img
• system_dlkm.img
• vendor_dlkm.img

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

5.3 拉取 AOSP 平台源码

示例版本信息：

拉取命令：

5.4 拉取 Pixel GKI 内核源码

参考：

拉取命令：

5.5 驱动下载页面

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

6. 开始编译：Pixel 8a GKI 内核怎么编

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

6.1 新增自定义配置 fragment

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

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

6.2 编译命令

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

6.3 编译后如何验证结果

例如，确认 CONFIG_FTRACE_SYSCALLS 是否开启：

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

7. 刷机前必须先知道的风险点

这部分务必认真看。

7.1 先准备好编译产物

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

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

7.2 刷机前的核心原则

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

需要特别注意的是：

• 你要刷入的厂包 / OTA 版本，必须 大于等于 当前手机版本
• 否则可能触发反回滚保护
• 严重时会导致设备无法恢复
• 一旦遇到刷入后重新启动的情况，请立即停止任何动作，使用8.1的步骤重新刷入ota包

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

8. Pixel 8a 内核镜像刷入流程

8.1 先进入 recovery 并 sideload 匹配版本 OTA

进入 recovery 后：

1. 选择 ADB sideload 模式
2. 如果屏幕显示机器人和 No command：
   • 按住电源键
   • 再按一次音量加键
   • 进入 Recovery 菜单

执行：

8.2 刷入内核相关镜像

8.3 进入 fastbootd，刷入 dlkm 镜像

8.4 回到 bootloader，刷入 vbmeta

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

9. 编译内核模块（.ko）

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

9.1 编译命令

9.2 hello 模块示例 BUILD.bazel

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

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

以下就是一些其他的资料和笔记

10. GKI 编译产物里，这些镜像分别是什么

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

10.1 init_boot.img

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

10.2 boot.img

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

• 包含 kernel Image
• 不再负责完整厂商差异化逻辑
• 厂商扩展更多通过 vendor 模块完成

10.3 vendor_boot.img

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

• 设备专属驱动加载脚本
• SoC 早期初始化内容
• vendor 相关服务
• 某些依赖的 init 配置

10.4 vendor_kernel_boot.img

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

• vendor kernel modules 的 early 部分
• 厂商补充的内核能力
• GKI 与 vendor 之间的接口衔接层

这个分区不要随意替换。

刷写错误可能导致：

• kernel panic
• 直接进入 fastboot
• 无法正常启动系统

10.5 ramdisk 到底是什么

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

• /init
• early init scripts
• sepolicy
• ueventd.rc
• fstab
• 一些早期启动所需的配置或注入内容

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

• 通用 ramdisk 在 init_boot.img
• vendor ramdisk 在 vendor_boot.img

11. GKI / KMI 符号表在哪里看

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

11.1 常见位置

11.2 主文件 abi_gki_aarch64.stg

特点：

• 体积较大
• 是 GKI ABI 的主定义文件
• 包含类型信息、函数签名、结构体布局、符号定义等

11.3 基础符号列表 abi_gki_aarch64

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

• module_layout
• __put_task_struct

11.4 厂商相关符号列表

例如：

• abi_gki_aarch64_qcom
• abi_gki_aarch64_pixel
• abi_gki_aarch64_mtk
• abi_gki_aarch64_exynos

11.5 查询示例

12. 如何阅读 AOSP 源码

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

12.1 Android Studio 导入 AOSP

第一步：编译 idegen

生成产物：

• android.ipr
• android.iml

第二步：打开项目之前先做裁剪

可按需调整权限：

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

• android.ipr：Android Studio 打开项目时选择的入口文件
• android.iml：模块描述文件，可以裁剪无关目录，减少索引压力

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

• frameworks
• packages
• libcore
• system

第三步：配置 SDK

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

• Java SDK
• 对应版本的 Android API

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

第四步：删除不必要依赖

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

• <Module source>
• Android API Platform

第五步：调整源码优先级

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

第六步：显示被排除文件

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

第七步：清理版本控制目录

在：

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

12.2 额外优化建议

提高 inotify 限制

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

fs.inotify.max_user_watches=524288

然后执行：

调大 Android Studio 堆内存

在 Android Studio 中进入：

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

12.3 Android Studio 调试 AOSP

调试流程通常是：

1. 连接设备并开启 USB 调试
2. 在源码处打断点
3. 点击 Attach Debugger to Android Process
4. 勾选 Show all processes
5. 选择目标进程，例如 system_process

如果按钮点击没有反应：

• 点击 Add Configuration...
• 左上角点 +
• 选择 Android App
• 保存后重新尝试

13. 如何用 VS Code + clangd 阅读 AOSP / GKI

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

13.1 AOSP：生成 compile_commands.json

检查输出：

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

{
  "clangd.arguments": [
    "--compile-commands-dir=.",
    "--background-index",
    "--all-scopes-completion"
  ]
}

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

{
  "java.project.sourcePaths": [
    "frameworks/base/core/java",
    "frameworks/base/services/core/java",
    "frameworks/base/packages",
    "libcore",
    "system"
  ]
}

13.2 GKI：通过 bazel 生成 compile_commands.json

VS Code 配置：

{
  "clangd.arguments": [
    "--compile-commands-dir=${workspaceFolder}"
  ]
}

14. 常见调试方式示例

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

14.1 使用 LLDB 调试 servicemanager

设备端：

主机端：

启动：

14.2 使用 LLDB 调试 /data/local/tmp/main

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

设备端：

主机端：

(lldb) platform select remote-android
(lldb) platform connect unix-abstract-connect:///data/local/tmp/debug-main.sock
(lldb) target create ./main
(lldb) b main
(lldb) process launch --working-dir /data/local/tmp -- arg1 arg2

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

注意：

• 建议使用 -g -O0 编译，便于断点和变量显示
• 如果依赖自定义 .so，启动前设置 LD_LIBRARY_PATH=/data/local/tmp
• lldb 与 lldb-server 最好版本匹配

14.3 使用 GDB 远程调试 Android 64 位程序

前提要求

• Android 设备已 root
• 目标程序已推送到 /data/local/tmp/
• ELF 为 aarch64
• 主机安装 gdb-multiarch，或使用 NDK 提供的 GDB
• 主机与设备可通过 adb 通信

步骤 1：推送程序

步骤 2：设备端启动 gdbserver64

预期输出：

步骤 3：主机端做端口转发

步骤 4：主机端启动 GDB

方式 A：

方式 B：

步骤 5：连接目标并调试

target remote :1234
file ~/linux-6.7.12/LinuxLearn/exp/uaf/pwn_uaf1
break main
continue

调试时常用命令：

• next / step
• print var
• info registers

常见问题

一键脚本模板

15. 总结

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

1. 先区分 AOSP 与 GKI：一个是系统源码，一个是内核基线
2. 再确认设备对应分支：尤其是 Pixel 机型与 Android 版本要匹配
3. 拉源码：平台源码和内核源码分别拉
4. 编译 GKI 内核：必要时加自定义 fragment
5. 理解镜像职责：特别是 boot、init_boot、vendor_boot、vendor_kernel_boot、vendor_dlkm
6. 按正确顺序刷机：先保证版本对齐，再刷相关镜像
7. 最后建立阅读和调试环境：Android Studio 或 VS Code，各取所需

参考资料

• 592K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2L8X3c8J5L8$3W2V1i4K6u0W2k6$3!0G2k6$3I4W2M7$3!0#2M7X3y4W2i4K6u0W2j5$3!0E0i4K6u0r3M7r3I4S2N6r3k6G2M7X3#2Q4x3V1k6E0j5h3&6A6k6X3g2K6N6l9`.`.
• f8dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2L8X3c8J5L8$3W2V1i4K6u0W2k6$3!0G2k6$3I4W2M7$3!0#2M7X3y4W2i4K6u0W2j5$3!0E0i4K6u0r3K9$3g2J5L8X3g2D9i4K6u0r3L8h3q4F1K9h3k6W2M7%4c8Q4x3V1j5`.
• 42eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6K6L8%4g2J5j5$3g2Q4x3X3g2S2L8X3c8J5L8$3W2V1i4K6u0W2j5$3!0E0i4K6u0r3k6r3!0U0M7#2)9J5c8Y4y4W2N6s2g2H3i4K6u0r3j5Y4g2A6L8r3c8Q4x3V1k6T1N6h3W2D9k6r3W2F1k6#2)9J5k6s2m8A6P5r3g2D9i4K6u0V1K9$3g2J5L8X3g2D9M7#2)9J5x3%4m8A6P5r3g2D9i4K6u0V1k6$3E0A6i4K6u0V1K9$3g2J5L8X3g2D9i4K6u0V1j5Y4u0S2L8X3y4Z5k6i4x3`.
• 246K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1k6i4k6W2L8r3!0H3k6i4u0K6i4K6u0W2k6$3!0G2k6$3I4W2i4K6u0W2j5$3!0E0i4K6u0r3j5h3&6V1M7X3!0A6k6q4)9J5c8X3!0@1j5g2)9K6c8W2)9J5x3$3q4C8K9i4c8S2
• 71bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1k6i4k6W2L8r3!0H3k6i4u0K6i4K6u0W2k6$3!0G2k6$3I4W2i4K6u0W2j5$3!0E0i4K6u0r3j5h3&6V1M7X3!0A6k6q4)9J5c8X3c8J5K9i4k6W2M7Y4y4Q4x3@1k6Z5L8q4)9K6c8s2A6Z5i4K6u0V1j5$3^5`.
• 7d8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8&6N6h3q4F1i4K6u0W2j5$3!0E0i4K6u0r3x3U0l9I4z5q4)9J5c8U0l9$3i4K6u0r3x3o6u0Q4x3V1k6S2L8X3c8J5L8$3W2V1i4K6u0V1j5Y4m8Q4x3V1j5`.
• f94K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0L8X3u0D9L8$3N6K6i4K6u0W2j5$3!0E0i4K6u0r3P5h3!0F1k6$3k6W2L8X3N6F1K9h3y4W2i4K6u0r3M7q4)9J5c8U0p5^5x3U0b7$3x3o6M7#2
• 381K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6B7N6h3g2B7K9h3&6Q4x3X3g2U0L8W2)9J5c8Y4m8G2M7%4c8Q4x3V1j5%4x3e0x3&6y4K6M7K6z5o6t1K6x3e0p5$3y4U0b7H3x3U0j5K6

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