2、开发环境准备：Linux系统要求、JDK与依赖工具安装、磁盘分区与内存配置、虚拟机与Docker方案

AOSP（Android Open Source Project）的编译是一个对硬件资源、操作系统版本、工具链版本高度敏感的工程过程。很多初学者在编译AOSP时遇到的第一道坎，往往不是代码本身，而是开发环境配置不当导致的编译中断、磁盘空间耗尽或JDK版本不匹配。本章将系统梳理AOSP编译对Linux系统的硬性要求、JDK与依赖工具的安装细节、磁盘分区与内存配置策略，以及虚拟机与Docker两种隔离环境的搭建方案。理解这些底层约束，是后续进行ROM定制、内核编译和系统移植的前提。

2.1 Linux系统要求与发行版选择

核心原理：为什么AOSP对Linux版本如此敏感

AOSP的构建系统（Soong/Make）深度依赖Linux内核提供的inotify文件系统事件通知机制、符号链接处理方式以及GNU工具链的特定行为。Google官方长期以Ubuntu LTS作为主要开发和验证平台，这意味着AOSP的构建脚本、预编译工具链（如clang、gcc）和宿主工具（如m4、flex、bison）都针对Ubuntu的glibc版本和系统库布局进行了充分测试。使用非官方支持的发行版（如Arch Linux或Fedora）虽然理论上可行，但往往需要额外修补构建脚本或手动安装兼容库，显著增加排障成本。

官方支持矩阵与推荐配置

操作流程：Ubuntu 22.04 LTS 基础环境配置

# 1. 更新软件源并安装基础工具
sudo apt update && sudo apt upgrade -y
sudo apt install -y git-core gnupg flex bison build-essential zip curl zlib1g-dev \
  libc6-dev-i386 libncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev \
  libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

# 2. 安装Python 3.9+ 与 pip
sudo apt install -y python3 python3-pip python3-venv

# 3. 安装Repo工具
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=~/bin:$PATH

常见误区与复盘

误区1：盲目追求最新Ubuntu版本（如24.04）。AOSP构建脚本可能尚未适配最新glibc或libstdc++，导致编译到一半出现"undefined reference"错误。误区2：使用32位系统。AOSP从Android 6.0起已完全放弃32位宿主支持。误区3：忽略语言环境变量。某些AOSP工具链对locale敏感，建议在~/.bashrc中设置export LC_ALL=C以避免因UTF-8编码差异导致的解析错误。

2.2 JDK与依赖工具安装

核心原理：JDK版本与AOSP版本的绑定关系

AOSP的构建系统使用Java编写了大量核心工具（如Jack编译器、D8 dex编译器、R8混淆器等），这些工具对JDK的API和字节码版本有严格限制。例如，Android 10及更早版本强制要求OpenJDK 8，因为其构建工具链尚未适配JDK 11的模块化系统（JPMS）。而Android 12+则要求JDK 11，因为R8/D8工具链已迁移到更新的Java特性。使用错误的JDK版本通常会在构建初期就抛出UnsupportedClassVersionError或NoSuchMethodError。

操作流程：多版本JDK共存管理

# 安装OpenJDK 17（Android 14+默认）
sudo apt install -y openjdk-17-jdk

# 安装OpenJDK 11（Android 12-13需要）
sudo apt install -y openjdk-11-jdk

# 安装OpenJDK 8（旧版本AOSP需要）
sudo apt install -y openjdk-8-jdk

# 配置默认JDK版本（update-alternatives）
sudo update-alternatives --config java
sudo update-alternatives --config javac

# 验证当前版本
java -version
javac -version

案例拆解：JDK版本不匹配导致的编译失败

背景：某开发者在Ubuntu 22.04上编译Android 13（AOSP 13），系统默认安装了OpenJDK 17。现象：执行source build/envsetup.sh && lunch aosp_arm64-userdebug后，运行m -j16编译，在构建core-libart模块时抛出大量java.lang.UnsupportedClassVersionError: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream has been compiled by a more recent version of the Java Runtime错误。分析：Android 13的构建系统虽然支持JDK 17作为宿主JDK，但其部分预编译的Java库（如commons-compress）仍以JDK 11字节码为目标。使用java -version确认当前JDK为17后，通过sudo update-alternatives --config java切换到JDK 11。结果：重新编译后错误消失，构建顺利完成。复盘：在开始编译前，务必查阅build/soong/soong_ui.bash中的JDK版本检查逻辑，或直接查看build/make/core/main.mk中的JAVA_VERSION_REQUIREMENTS变量。

依赖工具清单与验证

2.3 磁盘分区与内存配置

核心原理：AOSP编译的I/O特征与空间消耗

AOSP完整编译过程涉及数万个源文件的读取、中间对象文件的写入以及最终镜像文件的生成。其I/O模式以大量小文件随机读写为主，这对磁盘的IOPS（每秒输入输出操作数）和寻道时间极为敏感。机械硬盘（HDD）的随机读写性能通常在1-5MB/s级别，而SSD可达100-500MB/s，差距可达两个数量级。此外，AOSP源码树（.repo目录）在同步后约占用30-50GB，编译产物（out目录）在debug版本下约占用80-150GB，user版本约占用60-100GB。若同时保留多个构建变体，空间需求会线性增长。

磁盘分区方案设计

# 推荐分区布局（以500GB SSD为例）
# /dev/sda1: /boot    1GB   (ext4)
# /dev/sda2: /        100GB (ext4, 系统与工具)
# /dev/sda3: /home    200GB (ext4, 用户数据)
# /dev/sda4: /aosp    199GB (ext4, 专门存放AOSP源码与输出)

# 挂载优化：使用noatime减少写放大
sudo mount -o remount,noatime /aosp

# 在/etc/fstab中添加：
# /dev/sda4  /aosp  ext4  defaults,noatime,nodiratime  0  2

内存与交换分区配置

AOSP编译过程中，Soong构建系统会启动多个并行任务（默认与CPU核心数相同），每个任务需要约1-2GB内存。16GB内存的机器在m -j8时可能勉强够用，但若使用-j16则极易触发OOM Killer。推荐配置如下：

• 最低配置：16GB物理内存 + 8GB交换分区（仅适合编译Android 9以下版本）
• 推荐配置：32GB物理内存 + 16GB交换分区（可流畅编译Android 12+）
• 最佳配置：64GB物理内存 + 32GB交换分区（支持同时编译多个目标）

# 创建交换文件（以16GB为例）
sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 永久生效：在/etc/fstab中添加
# /swapfile  none  swap  sw  0  0

案例拆解：磁盘空间不足的排障过程

背景：开发者使用256GB SSD编译Android 14，源码同步后剩余空间约180GB。现象：编译进行到约40分钟时，out/target/product/generic/system.img生成阶段报错No space left on device。分析：使用df -h查看发现/aosp分区已用98%，du -sh out/显示out目录已占用120GB。进一步检查发现out/host目录下残留了多个版本的host工具链（约30GB），且out/target/product/generic/obj/PACKAGING目录存在大量临时zip包。操作：执行make clean清理所有输出，然后重新配置export OUT_DIR=/aosp/out_android14将输出目录指向独立分区，并删除out/host/linux-x86/下旧版本clang残留。结果：重新编译后空间占用降至90GB，编译成功。复盘：建议在build/envsetup.sh中设置export OUT_DIR_COMMON_BASE=/aosp/out，将不同版本的输出目录分离，避免相互覆盖和空间浪费。

2.4 虚拟机与Docker方案

核心原理：虚拟化与容器化的隔离差异

虚拟机（如VirtualBox、VMware）通过Hypervisor模拟完整硬件层，提供独立的操作系统内核，隔离性最强，但性能损耗约10%-20%（主要来自磁盘I/O和内存访问）。Docker容器则共享宿主内核，仅隔离用户空间，性能损耗极低（约1%-3%），但要求宿主Linux内核版本和配置满足AOSP需求。对于AOSP编译这种CPU密集型任务，Docker在编译速度上明显优于虚拟机，但Docker无法解决Windows/macOS宿主上的内核兼容问题——此时仍需依赖虚拟机或WSL2。

VirtualBox虚拟机配置要点

Docker方案实战：构建AOSP编译镜像

# Dockerfile 示例
FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive

RUN apt update && apt install -y \
    git-core gnupg flex bison build-essential zip curl zlib1g-dev \
    libc6-dev-i386 libncurses5-dev x11proto-core-dev libx11-dev \
    lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig \
    openjdk-17-jdk python3 python3-pip \
    && rm -rf /var/lib/apt/lists/*

# 创建非root用户
RUN useradd -m -s /bin/bash aosp && echo "aosp ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
USER aosp
WORKDIR /home/aosp

# 挂载源码目录（运行时指定）
# docker run -v /host/aosp:/home/aosp/src -v /host/out:/home/aosp/out aosp-builder

CMD ["/bin/bash"]

案例拆解：Docker与虚拟机方案对比测试

背景：某团队需要在macOS M1 Pro（16GB内存）上编译Android 13，面临虚拟机与Docker两种方案选择。测试条件：使用同一份AOSP源码（约35GB），执行m -j8编译aosp_arm64-userdebug。结果对比：VirtualBox 7.0（Ubuntu 22.04虚拟机，分配8GB内存）总耗时约2小时15分钟；Docker Desktop（使用QEMU模拟x86_64）总耗时约1小时50分钟；原生Linux（对比基准）约1小时20分钟。分析：Docker Desktop在macOS上仍依赖轻量级虚拟机（QEMU），性能优势不明显，但环境配置和团队协作效率更高。复盘：对于macOS用户，如果追求极致性能，建议使用云服务器（如AWS EC2 c5.2xlarge）或远程Linux工作站；如果追求便捷性，Docker Desktop配合docker-compose管理依赖是更优选择。

常见误区与总结

误区1：在虚拟机中分配超过物理内存的RAM。这会导致宿主频繁使用交换分区，反而拖慢编译速度。误区2：Docker容器内使用AUFS或OverlayFS存储驱动。AOSP构建需要大量硬链接操作，OverlayFS2在部分内核版本上存在硬链接限制，建议使用--storage-driver=vfs或ext4后端。误区3：忽略CPU架构差异。在ARM架构的Mac上通过Docker运行x86_64容器，会因QEMU模拟导致编译速度下降40%-60%。

开发环境的搭建质量直接决定了后续AOSP编译的效率与稳定性。建议读者在开始编译前，先使用df -h检查磁盘空间、free -h检查内存、java -version确认JDK版本，并记录一份环境配置清单。当编译遇到问题时，优先排查环境因素而非代码问题，这能节省大量排障时间。