📚 课程目录第2章开发环境搭建

2. 开发环境搭建：AOSP源码下载与编译、模拟器与真机调试环境配置

说实话，做车载系统开发，环境搭建往往是第一个坑。我见过不少团队，方案选型时信心满满，结果卡在源码下载和编译上，一卡就是一两周。这一章，我把这些年踩过的坑、总结的经验，一次性给你讲透。

2.1 AOSP源码下载：别让网络成为瓶颈

下载AOSP源码，说白了就是跟Google的服务器较劲。国内开发者尤其头疼。我个人的习惯是，先确认网络环境，再决定用哪种方式。

2.1.1 环境准备

你需要一台Linux机器，Ubuntu 18.04或20.04是我用得最顺手的。硬件方面，我建议：

CPU：至少8核，16核以上更佳
内存：32GB起步，64GB不嫌多
磁盘：SSD，400GB以上剩余空间

注意： 我曾经用机械硬盘编译过一次AOSP，等了整整12个小时还没完。后来换了NVMe SSD，时间直接缩短到2小时以内。磁盘IO是编译速度的关键瓶颈，别在这上面省钱。

2.1.2 使用repo工具同步代码

Google官方推荐用repo工具来管理AOSP的多仓库结构。基本流程如下：

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

# 创建工作目录
mkdir aosp
cd aosp

# 初始化仓库（以android-13.0.0_r41为例）
repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_r41

# 同步代码
repo sync -j8 -c

这里有个坑：repo sync如果中途断了，重新执行就行，它会断点续传。但如果你网络不稳定，我建议加个--force-sync参数，避免一些奇怪的冲突。

小技巧： 国内开发者可以用清华或中科大的镜像站，速度能快不少。比如把https://android.googlesource.com换成https://mirrors.tuna.tsinghua.edu.cn/git/AOSP。我团队的项目一直用清华源，基本没出过问题。

2.2 AOSP编译：从源码到镜像

代码下完了，接下来就是编译。嗯，这一步才是真正的考验。

2.2.1 初始化编译环境

source build/envsetup.sh
lunch

执行lunch后，你会看到一系列编译目标。对于车载系统，我们通常选择aosp_car_x86_64-userdebug或aosp_car_arm64-userdebug。前者用于模拟器，后者用于真机。

2.2.2 开始编译

make -j$(nproc)

-j参数指定并行编译的线程数，一般设为CPU核心数的1.5到2倍。比如16核的机器，可以用-j24或-j32。

我的经验： 第一次编译AOSP，别指望一次成功。常见的错误包括：

Java版本不对（需要OpenJDK 11）
Python版本过低（需要Python 3.8+）
磁盘空间不足（编译过程中会生成大量中间文件）

遇到错误别慌，看日志定位问题，大部分都能在Stack Overflow上找到答案。

2.3 模拟器环境：Cuttlefish与QEMU

做车载开发，模拟器是必不可少的调试工具。Google官方推荐的是Cuttlefish，它比传统的QEMU模拟器更接近真机体验。

2.3.1 Cuttlefish的使用

Cuttlefish是Android官方推荐的虚拟化方案，支持ARM和x86架构。启动方式很简单：

# 编译Cuttlefish镜像
make -j$(nproc) cuttlefish

# 启动模拟器
launch_cvd --daemon

# 查看模拟器状态
cvd status

# 停止模拟器
stop_cvd

Cuttlefish启动后，你可以通过ADB连接它：

adb connect 10.0.2.15:6520

为什么用Cuttlefish？ 我对比过QEMU和Cuttlefish，Cuttlefish在图形渲染、传感器模拟、网络性能方面都明显优于QEMU。特别是做仪表盘融合开发时，Cuttlefish能更真实地模拟多屏显示场景。

2.3.2 QEMU的补充使用

虽然Cuttlefish是主流，但QEMU在某些场景下仍有价值，比如调试底层驱动或测试特定硬件特性。启动QEMU模拟器：

emulator -avd my_avd -qemu -m 2048 -smp 4

参数说明：

参数	含义
`-avd`	指定AVD名称
`-m`	分配内存大小（MB）
`-smp`	模拟CPU核心数

2.4 真机调试环境配置

模拟器再方便，最终还是要上真机。真机调试的配置，我总结为三步：

解锁Bootloader：不同厂商方法不同，但核心都是进入fastboot模式后执行fastboot flashing unlock
刷入编译好的镜像：fastboot flashall -w（-w会清除数据）
验证连接：adb devices确认设备已识别

警告： 解锁Bootloader会清除设备所有数据，并可能失去保修。我建议准备一台专门的开发机，别拿主力机折腾。

2.5 ADB与fastboot调试技巧

ADB和fastboot是Android开发的左膀右臂。这里分享几个我常用的技巧：

2.5.1 ADB常用命令

命令	用途
`adb logcat -b all`	查看所有日志缓冲区
`adb shell dumpsys`	查看系统服务状态
`adb shell am start -n`	启动指定Activity
`adb shell input keyevent`	模拟按键事件

2.5.2 fastboot刷机技巧

刷机时，我习惯用fastboot flash逐个分区刷写，而不是用flashall。这样更可控：

fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot reboot

避坑指南： 我曾经在一次刷机中，因为flashall自动刷写了不兼容的radio分区，导致设备基带损坏，花了三天才救回来。从那以后，我坚持手动分区刷写，虽然麻烦点，但安全。

2.6 本章知识体系

下面这张图，帮你梳理本章的核心脉络：

环境搭建是基础，也是门槛。把这些搞定了，后面的开发才能顺利推进。记住，别怕踩坑，每个坑都是经验。我当年第一次编译AOSP，整整折腾了一周才跑起来，但现在回想起来，那些坑反而让我对系统理解得更深。