Android-10.0.0_r39编译blueline时build_image.py报错（Ubuntu20.04）

你遇到的是典型的设备分区配置不匹配问题——blueline（Pixel 3）在这个AOSP版本里的默认system分区大小设置比walleye（Pixel 2）紧凑，而userdebug版本的debug apex（比如com.android.runtime.debug.apex）体积较大，直接超出了分区容量限制。下面是几个可行的解决方法：

方法1：修改blueline的system分区大小配置 #

这是最直接的解决方案，通过调整设备配置文件扩大system分区的预留空间：

1. 找到blueline的BoardConfig文件，在你的源码目录中路径为：device/google/crosshatch/blueline/BoardConfig.mk
2. 打开文件后，找到BOARD_SYSTEMIMAGE_PARTITION_SIZE参数，它定义了system分区的总容量（字节单位）。默认值对应69MB左右，你可以将其修改为更充裕的值，比如180MB（对应字节数188743680）：

   BOARD_SYSTEMIMAGE_PARTITION_SIZE := 188743680
   

   也可以根据临时目录树的大小（146MB）设置200MB（209715200），避免后续其他文件占用空间导致再次溢出。
3. 保存文件后，清理之前的编译缓存：

   make clean
   

   或者更精准地清理systemimage相关中间文件：

   ninja -C out/target/product/blueline clean systemimage
   

4. 重新执行lunch和编译命令：

   lunch aosp_blueline-userdebug
   make -j$(nproc)
   

方法2：切换到user版本编译（如果不需要debug功能） #

如果你的开发需求不需要userdebug版本的debug特性，可以尝试编译user版本，它会使用体积更小的release版apex文件：

lunch aosp_blueline-user
make -j$(nproc)

这种方式不需要修改任何配置，就能避开debug apex带来的空间问题。

方法3：优化debug apex的编译配置（进阶） #

如果你必须使用userdebug版本，又不想修改分区大小，可以尝试调整apex的编译选项，禁用不必要的debug内容：

1. 找到build/make/target/product/debug_base.mk或者对应apex的配置文件（比如packages/modules/Runtime/apex/Android.mk）
2. 修改编译参数，关闭debug符号或启用编译优化，减少com.android.runtime.debug.apex的体积。不过这种方法需要对AOSP编译系统有一定了解，适合有经验的开发者。

补充说明：walleye编译正常是因为它的默认BOARD_SYSTEMIMAGE_PARTITION_SIZE配置更大，足以容纳debug版本的所有文件，而blueline的默认配置更紧凑，所以触发了空间溢出问题。

内容的提问来源于stack exchange，提问作者James Moore