1. Android 16 AOSP 编译报错全景解读1.1 为什么 Android 16 的编译门槛又抬高了Android 16 的 AOSP 源码树在构建系统层面做了不少调整最直观的感受就是以前在 Android 14 上能一把过的编译命令到了 Android 16 上大概率会在某个阶段卡住。这不是你的环境坏了而是 Google 在 Soong 构建系统、Kotlin 编译链、APEX 模块化以及 Java 版本要求上都往前推了一步。我这次拿到的是一个典型的编译报错场景在 Ubuntu 环境下拉取 Android 16 AOSP 源码后执行source build/envsetup.sh和lunch选好目标跑make -j或者m的时候报错信息五花八门。有人卡在soong_build阶段有人卡在ninja链接阶段还有人直接死在jack或者kotlin编译上。这些报错看起来零散但背后其实有几条共性的线索。先说结论Android 16 AOSP 编译报错九成以上集中在四个方向——Java/JDK 版本不匹配、依赖包缺失或版本过旧、磁盘与内存资源不足、源码同步不完整或分支选错。把这四类问题吃透大部分报错都能自己定位。这篇文章适合谁看如果你正在搭建 Android 16 的编译环境或者已经跑了一半被报错拦住又或者你是刚接触 AOSP 编译的新手想搞清楚“为什么别人能编过我却不行”那这篇内容就是给你准备的。我会从整体思路讲到具体报错再到排查技巧尽量让你看完能直接动手。1.2 编译报错的典型分类与快速定位思路在动手解决之前先建立一个分类意识。AOSP 编译报错按发生阶段大致可以分成下面几类每一类的排查入口不一样报错阶段典型关键词常见根因环境初始化envsetup、lunch失败shell 环境、Python 版本、目标配置错误Soong 解析soong_build、Android.bp报错源码不完整、分支不匹配、依赖模块缺失Ninja 构建ninja: build stopped、链接错误内存不足、并行度过高、工具链缺失Java/Kotlin 编译javac、kotlinc、error: cannot find symbolJDK 版本不对、classpath 混乱打包镜像mkbootimg、avbtool、apex相关工具缺失、签名配置、分区大小超限定位的核心思路是先看报错最后 20 行找到第一个error:或FAILED:再往上翻上下文。很多人一看到满屏红字就慌其实真正有用的信息往往只有一两行。Ninja 的报错尤其如此它会先打印一堆正在执行的任务最后才告诉你哪个目标失败了。还有一个经验编译报错要按“从早到晚”的顺序解决。如果 Soong 解析阶段就挂了你后面看到的 ninja 报错都是连锁反应没有意义。先把最早的错误解决掉再重新编译往往后面的报错会跟着消失。2. 编译环境准备与核心依赖梳理2.1 Ubuntu 版本与基础依赖包的取舍Android 16 AOSP 官方推荐用 Ubuntu 22.04 或更高版本。我实测下来Ubuntu 20.04 也能编但会遇到一些库版本偏旧的问题比如libncurses和libtinfo的兼容性。如果你还在用 18.04建议直接升级不然会在依赖上浪费大量时间。基础依赖包的安装是第一步也是最容易漏的一步。官方文档给的包列表很长我把它整理成一张更实用的表按用途分组用途关键包说明编译工具链git-core、gnupg、flex、bison、build-essential缺一不可flex/bison缺失会导致内核编译失败压缩与归档zip、unzip、curl、zlib1g-dev拉取和解析源码时用到库依赖libc6-dev-i386、lib32z1-dev、libncurses532 位库在编译 host 工具时需要网络与证书libssl-dev、ca-certificates源码同步和签名相关Python 相关python3、python-is-python3Android 16 已全面转向 Python 3安装命令可以这样写sudo apt update sudo apt install -y git-core gnupg flex bison build-essential zip unzip curl \ zlib1g-dev libc6-dev-i386 lib32z1-dev libncurses5 libssl-dev \ python3 python-is-python3注意libncurses5在 Ubuntu 22.04 上可能需要从旧源安装如果提示找不到可以换成libncurses-dev但某些 host 工具仍会依赖旧版本遇到具体报错再针对性处理。这里有个坑我踩过不要用apt install openjdk-8-jdk去编 Android 16。Android 16 的很多模块已经要求 JDK 17 甚至更高用 JDK 8 会在 Kotlin 编译阶段报一堆Unsupported class file major version的错误。正确的做法是装 JDK 17并确保JAVA_HOME指向它。2.2 JDK 版本选择与切换的实操细节JDK 是 Android 16 编译报错的高发区。AOSP 不同版本对 JDK 的要求不一样Android 16 主要依赖 JDK 17。你可以用下面的命令确认当前版本java -version javac -version如果输出是1.8.0_xxx那就需要换。安装 JDK 17sudo apt install -y openjdk-17-jdk装完之后用update-alternatives切换默认版本sudo update-alternatives --config java sudo update-alternatives --config javac选编号对应 JDK 17 的那一项。然后重新确认java -version # 应输出 openjdk version 17.x.x提示AOSP 编译过程中会用到多个 JDK比如 host 工具可能用 JDK 17而某些旧模块仍指定 JDK 11。如果报错提示某个模块找不到特定 JDK可以在prebuilts/jdk/目录下确认预置的 JDK 版本必要时通过环境变量ANDROID_JAVA_HOME指定。我遇到过一个很隐蔽的问题系统里装了 JDK 17但JAVA_HOME还指向 JDK 8 的路径导致soong在解析时用了错误的javac。排查方法是在编译前打印环境变量echo $JAVA_HOME which javac两者必须一致否则就会出现“明明装了新 JDK 却还是报旧版本错误”的情况。2.3 磁盘空间与内存的硬性门槛Android 16 的源码树加上编译产物磁盘占用非常可观。源码本身大约 100GB 起步编译产物再占 100GB 到 150GB所以至少预留 250GB 到 300GB 的可用空间。我见过有人用 200GB 的虚拟机编到一半提示No space left on device那种绝望感很难受。检查磁盘df -h内存方面官方建议 16GB 起步但实际编译时如果并行度高16GB 很容易触发 OOM内存溢出。我的建议是物理机 32GB 以上虚拟机 24GB 以上。如果内存不够可以通过降低并行度来缓解make -j4-j后面的数字是并行任务数一般设为 CPU 核心数的 1 到 1.5 倍。核心多但内存少的时候宁可把-j调低也不要让它 OOM。因为 OOM 导致的报错往往很隐晦比如Killed或者signal 9新手很难联想到是内存问题。还有一个容易被忽略的点swap 分区。如果物理内存不足swap 能救急但编译速度会明显下降。我一般会配 16GB 到 32GB 的 swap作为兜底。3. 源码同步与分支选择的避坑指南3.1 repo 初始化与分支标签的正确姿势Android 16 的源码同步用repo工具。初始化命令看起来简单但分支选错是编译报错的一大来源。正确的流程是mkdir aosp16 cd aosp16 repo init -u https://android.googlesource.com/platform/manifest -b android-16.0.0_r1 repo sync -c -j8 --no-tags这里有几个关键点-b android-16.0.0_r1是分支标签必须和你要编的版本对应。如果写成了main或者别的标签可能拉到不完整的代码。-c表示只拉当前分支节省时间和空间。--no-tags跳过标签加快同步。-j8是并行数根据网络情况调整太大容易断。注意repo sync中途断网是常事重新执行repo sync即可它会断点续传。但如果反复失败可以加--force-sync强制覆盖本地改动。同步完成后进入源码根目录执行source build/envsetup.sh lunch aosp_arm64-userdebuglunch的目标选择也有讲究。aosp_arm64-userdebug是最常用的组合适合模拟器和真机调试。如果你想编特定设备比如 Pixel 系列需要选对应的aosp_device-userdebug。选错目标会导致后续编译找不到对应的 BoardConfig报错信息通常是No config file found for。3.2 源码不完整导致的典型报错源码不完整是 Soong 解析阶段报错的主要原因。典型表现是error: cannot find module xxx in Android.bp或者FAILED: out/soong/build.ninja遇到这类报错先确认源码是否完整。可以用repo status看有没有缺失的仓库或者重新跑一次repo sync。如果某个仓库反复同步失败可以单独进到那个目录执行git fetch和git reset --hard。我遇到过一次很典型的情况repo sync显示成功但编译时提示某个prebuilts目录下的工具缺失。排查后发现是同步时用了-c但某个仓库的分支没对上。解决办法是进到对应目录手动git checkout到正确的分支标签。还有一种情况是本地改动污染。如果你之前改过某些文件repo sync不会覆盖编译时就会用到旧代码。排查方法是repo diff如果有输出说明有未提交的改动。确认不需要后用repo forall -c git reset --hard清理再重新同步。4. 高频编译报错逐条拆解与解决4.1 Soong 与 Ninja 阶段的报错处理Soong 是 Android 的构建系统负责把Android.bp解析成 Ninja 文件。这个阶段报错通常和模块定义、依赖关系有关。常见的报错有报错一soong_build: error: ... duplicate module name这说明有两个模块重名。原因可能是源码里有重复的Android.bp或者你本地改动引入了冲突。解决方法是根据报错路径找到对应的Android.bp检查name字段是否重复。报错二ninja: error: unknown target xxx这通常是lunch目标选错或者某个模块没有在当前目标下启用。确认lunch选择正确后可以尝试m xxx单独编译该模块看具体报错。报错三ninja: build stopped: subcommand failed这是最笼统的报错真正的原因在它上面几行。往上翻找到第一个FAILED:那才是根因。比如FAILED: out/soong/.intermediates/.../xxx.o然后看这个目标对应的编译命令和错误输出。常见的是头文件找不到、符号未定义、编译器版本不匹配。实操心得Ninja 报错时可以用m -j1单线程编译这样报错顺序更清晰不会被并行输出冲乱。虽然慢但定位问题效率高。4.2 Java 与 Kotlin 编译报错实战Java 和 Kotlin 编译报错在 Android 16 上很常见尤其是涉及javac和kotlinc的模块。典型报错error: cannot find symbol import xxx;或者error: incompatible types: xxx cannot be converted to yyy这类报错的原因通常是JDK 版本不对前面说过Android 16 需要 JDK 17。如果用了 JDK 8 或 11会出现Unsupported class file major version。依赖模块未编译某个模块依赖的库没有先编译导致 classpath 缺失。解决方法是先m那个依赖模块或者直接全量编译。源码分支不匹配不同分支的 API 有差异混用会导致符号找不到。Kotlin 报错还有一个特殊点Kotlin 版本和 JDK 版本的兼容性。Android 16 用的 Kotlin 版本较新如果 JDK 太旧会报Kotlin could not find the required JDK tools。确认 JDK 17 后这个问题一般会消失。我遇到过一个很折腾的案例编译某个系统 App 时Kotlin 报cannot access class java.lang.xxx排查半天发现是JAVA_HOME指向了 JRE 而不是 JDK。JRE 里没有javac和完整的类库导致 Kotlin 编译器找不到符号。改成 JDK 路径后解决。4.3 资源与打包阶段的报错编译到后期会进入资源打包和镜像生成阶段。这个阶段的报错往往和工具、配置有关报错关键词可能原因解决方向aapt2: error资源文件格式错误、资源 ID 冲突检查res目录清理out重新编译mkbootimg: command not found工具未编译或路径不对确认prebuilts下工具存在重新mavbtool: error签名配置错误、分区大小超限检查BoardConfig.mk中的分区大小apex相关报错APEX 模块配置问题确认lunch目标支持 APEX检查Android.bp资源报错里aapt2的问题最多。常见的是资源文件里有非法字符或者两个模块定义了相同的资源 ID。解决方法是看报错里提到的文件路径逐个检查。如果实在找不到可以删掉out目录重新全量编译有时候是增量编译的缓存问题。提示删out目录是万能但费时的操作。建议先尝试m installclean或者只删对应模块的中间产物实在不行再全删。5. 常见问题速查与独家避坑技巧5.1 编译报错速查表把前面提到的报错整理成一张速查表方便你对号入座报错现象根因解决动作Unsupported class file major versionJDK 版本过低装 JDK 17切换JAVA_HOMENo space left on device磁盘不足清理空间预留 300GBKilled/signal 9内存不足 OOM降低-j并行度加 swapcannot find module源码不完整重新repo sync检查分支duplicate module name模块重名检查Android.bp的nameaapt2: error资源问题检查res清理outmkbootimg not found工具缺失重新编译 host 工具ninja: unknown targetlunch 目标错误重新lunch选正确目标5.2 我踩过的坑与独家经验坑一不要迷信-j越大越快。我一开始用-j32结果 16GB 内存的机器直接 OOM编译到一半进程被杀。后来改成-j8虽然慢一点但稳定跑完。并行度和内存的关系是每个编译任务大约占 1GB 到 2GB 内存-j乘以这个数不能超过可用内存。坑二repo sync成功不代表源码完整。有一次同步显示 100%但编译时提示某个external目录下的库缺失。后来发现是那个仓库的分支标签在同步时被跳过了。解决办法是进到对应目录手动git checkout到正确标签再repo sync一次。坑三环境变量污染。如果你之前编过其他版本的 AOSPshell 里可能残留了旧的TARGET_PRODUCT、TARGET_BUILD_VARIANT等变量。这些变量会干扰新的编译。建议每次编译前开一个新的终端或者用env -i bash起一个干净环境。坑四增量编译的缓存陷阱。改了代码后增量编译报错但全量编译就过。这种情况多半是中间产物不一致。可以先m installclean再m。如果还不行删掉out目录重来。虽然费时间但能省去排查缓存问题的时间。坑五网络问题导致的同步失败。repo sync对网络稳定性要求高断网后重新执行即可。如果某个仓库反复失败可以单独git clone那个仓库到对应目录再repo sync。另外repo sync的-j不要设太大网络带宽不够时反而容易断。5.3 编译成功后的验证与后续扩展编译成功后产物在out/target/product/device/目录下。你可以用模拟器验证emulator -verbose -show-kernel或者刷入真机。如果是userdebug版本还可以用adb root和adb remount调试系统分区。后续如果想定制系统可以从这几个方向入手修改device/vendor/device/下的配置文件添加或删除预置 App调整系统属性。每次改动后重新编译注意增量编译的缓存问题。编译 AOSP 是个体力活也是个技术活。报错不可怕可怕的是不知道从哪下手。把环境、源码、JDK、内存这几块守住大部分报错都能自己解决。我个人的体会是遇到报错先别急着搜先看报错最后几行找到第一个 error再往上翻上下文八成能定位到根因。搜的时候也要带着具体报错关键词搜不要只搜“AOSP 编译报错”那样出来的结果太泛反而浪费时间。