第1章：开发环境搭建——AOSP源码下载、编译环境配置（Ubuntu）、搭建车载模拟器、使用真机调试
做车载Android系统定制，第一步就是搭环境。这事儿说难不难，说简单吧，坑是真不少。我这些年带过不少新人，十有八九都卡在环境搭建这一步。今天我就把压箱底的经验掏出来，带你把这关过了。
1.1 AOSP源码下载——别让网络成了拦路虎
下载AOSP源码，说白了就是跟Google的服务器打交道。国内网络环境你懂的，直接repo sync大概率会超时。我建议你这么做：
核心思路：用清华或中科大的镜像站，速度能快10倍不止。
先安装repo工具：
mkdir ~/bin
PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo然后初始化AOSP仓库：
mkdir aosp-car
cd aosp-car
repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest -b android-13.0.0_r30这里我选了Android 13的tag。为什么选这个？因为车载系统通常需要比较新的内核和HAL层支持，13的稳定性在车机上已经验证过了。
同步代码：
repo sync -c -j8-j8表示8个线程并行下载。你机器核多可以调大，但别超过16，否则磁盘IO会成为瓶颈。我在项目上遇到过有人开32线程，结果硬盘直接跑满100%，反而更慢。
小技巧：如果中途断了，再跑一次repo sync就行，它会断点续传。我曾经连着下了三天才搞定全套代码，中间断了十几次，别慌。
1.2 编译环境配置——Ubuntu 20.04是最稳的选择
编译AOSP对系统有要求。我踩过不少坑，最后发现Ubuntu 20.04 LTS是最省心的。18.04的gcc版本太老，22.04又太新，有些依赖包还没适配好。
安装必要依赖：
sudo apt-get update
sudo apt-get install -y git-core gnupg flex bison build-essential \
zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 \
libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev \
lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig嗯，这里要注意，不同Android版本依赖包会有差异。Android 13需要Python 3.8以上，而系统自带的可能是3.6。我建议用pyenv管理Python版本：
curl https://pyenv.run | bash
pyenv install 3.9.10
pyenv global 3.9.10Java环境也别忘：
sudo apt-get install -y openjdk-11-jdk为什么不用JDK 17？Android 13的构建系统对JDK 17支持还不完善，我试过，编译到一半会报错。老老实实用JDK 11最稳。
避坑指南：我曾经在Ubuntu 22.04上折腾了整整两天，就为了搞定一个libncurses5的兼容性问题。后来发现20.04根本不会有这个问题。所以，听我一句劝，别在系统版本上搞创新。
1.3 搭建车载模拟器——没有真车机也能调试
车载模拟器和普通手机模拟器不一样。它需要模拟车载特有的硬件环境，比如CAN总线、多屏显示、方向盘按键等。
Google官方提供了Automotive模拟器镜像，但说实话，不太好用。我推荐用Cuttlefish，它是AOSP自带的虚拟化方案。
编译Cuttlefish镜像：
source build/envsetup.sh
lunch aosp_car_x86_64-userdebug
make -j8编译完成后启动：
cvd start你会看到一个车载系统的模拟器窗口弹出来。第一次启动会比较慢，因为要创建磁盘镜像。之后启动就快多了。
核心配置：模拟器默认是单屏，车载系统通常需要双屏甚至三屏。修改device/google/cuttlefish/shared/config/vehicle_config.pb可以增加屏幕数量。
我个人习惯在模拟器里先验证UI逻辑和基本功能，等稳定了再烧到真机上。这样能省不少时间，毕竟真机刷机一次要十几分钟。
1.4 使用真机调试——从刷机到logcat
真机调试是绕不开的。车载开发板常见的有Renesas R-Car、Qualcomm SA8155、NXP i.MX8等。我以R-Car为例说说流程。
刷机前先解锁bootloader：
fastboot flashing unlock
fastboot oem unlock然后刷入编译好的镜像：
fastboot flash bootloader u-boot.bin
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot reboot刷完后用adb连接：
adb devices
adb logcat -b all这里有个坑：车载设备通常通过USB转串口连接，adb可能识别不到。你需要先确认驱动装好了。在Ubuntu上，可以这样检查：
lsusb | grep "Qualcomm\|Renesas\|NXP"如果看不到设备，多半是udev规则没配。创建一个/etc/udev/rules.d/51-android.rules文件，写入：
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"然后重启udev服务：
sudo service udev restart调试技巧：车载系统经常遇到休眠唤醒的问题。用adb shell dumpsys power可以查看电源状态，用adb shell dumpsys car_service可以查看车载服务状态。这两个命令我几乎天天用。
1.5 本章知识体系总览
下面这张图把整个开发环境搭建的流程串起来了。你跟着这个路线走，基本不会迷路。
这张图把整个流程分成了五个阶段。你会发现，模拟器和真机调试是并行的两条路。我个人的建议是：前期用模拟器快速迭代UI和逻辑，中期用真机验证硬件相关功能，后期两者结合做回归测试。
1.6 常见问题与解决方案
| 问题 | 原因 | 解决方案 |
|---|---|---|
| repo sync超时 | 网络不稳定或GFW干扰 | 使用清华/中科大镜像，或设置HTTP代理 |
| 编译报错"missing libncurses5" | 系统版本过高，依赖包不兼容 | 安装libncurses5-dev，或换Ubuntu 20.04 |
| 模拟器启动黑屏 | 缺少GPU加速或内存不足 | 启用KVM，分配至少4GB内存 |
| adb识别不到设备 | udev规则未配置或驱动问题 | 配置51-android.rules，重启udev服务 |
| 刷机后设备无限重启 | bootloader版本不匹配 | 确认u-boot版本与内核一致，重新烧录 |
重要提醒：车载开发板和普通手机不一样，有些板子有硬件加密芯片，刷机前一定要备份原始镜像。我曾经手快把一台R-Car H3的bootloader刷坏了，花了三天才从厂家要到恢复工具。嗯，血的教训。
好了，环境搭建这部分就讲到这里。你跟着步骤走，应该半天内就能把整套环境跑起来。下一章我们会深入AOSP的目录结构，看看车载系统到底改了哪些东西。
公众号:蓝海资料掘金营，微信deep3321