为什么昨天编译好好的没有问题今天早上突然就不行了我什么都没有改过我的环境是 Ubuntu 22.04.5 LTSjava17,python2.7.182026-08-25 10:31:48,741 - add_img_to_target_files.py - INFO : creating system.img... 2026-08-25 10:32:10,797 - build_image.py - INFO : The tree size of /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/tmprB6JEZ is 1178 MB. 2026-08-25 10:32:11,657 - verity_utils.py - INFO : CalculateMinPartitionSize(1253036032): partition_size 1273208832. 2026-08-25 10:32:11,657 - build_image.py - INFO : Allocating 1214 MB for /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/merge_target_files_w8Z2R_/output/IMAGES/system.img. Traceback (most recent call last): File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 174, in _run_module_as_main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 72, in _run_code File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/__main__.py, line 12, in module File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 174, in _run_module_as_main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 72, in _run_code File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1467, in module File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1463, in main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1311, in call_func_with_temp_dir File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1463, in lambda File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1262, in merge_target_files File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 975, in generate_images File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 1005, in main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 873, in AddImagesToTargetFiles File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 860, in add_partition File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 144, in AddSystem File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 432, in CreateImage File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/build_image.py, line 543, in BuildImage File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/verity_utils.py, line 481, in CalculateMaxImageSize verity_utils.BuildVerityImageError: Failed to calculate max image size: 2026-08-25 10:32:12,390 - post_process_target_files.py - WARNING : command /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files --framework-target-files /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/system_target_files.zip --vendor-target-files /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/other_target_files.zip --framework-item-list /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/system_item_list.txt --vendor-item-list /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/other_item_list.txt --framework-misc-info-keys /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/system_misc_info_keys.txt --output-target-files /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/merged_target_files.zip --rebuild_recovery --allow-duplicate-apkapex-keys -v returned 1: None command python /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/post_process_target_files.py --system-target-files out_sys/target/product/mssi_32_ago_h_ww/images/sys.target_files.zip --vendor-target-files out/target/product/项目名称/images/vnd.target_files.zip --kernel-target-files out/target/product/项目名称/images/krn.target_files.zip --vendor-dist-files out/target/product/项目名称/images/vnd.dist_files.zip --output-dir out/target/product/项目名称/merged --system-dist-files out_sys/target/product/mssi_32_ago_h_ww/images/sys.dist_files.zip --keep-images --vendor-otatools out/target/product/项目名称/images/otatools.zip returned 1: None #### split_build.py failed to build some targets #### command python out_sys/target/product/mssi_32_ago_h_ww/images/split_build.py --system-dir out_sys/target/product/mssi_32_ago_h_ww/images --vendor-dir out/target/product/项目名称/images --kernel-dir out/target/product/项目名称/images --output-dir out/target/product/项目名称/merged returned 1: None #### split_build_helper.py failed to build some targets ####这个电脑不知道什么情况动不动就这样弄了几个小时才解决这个大概说的就是Android 的verity_utils.py在这里实际上会调用avbtool的add_hash_footer / add_hashtree_footer --partition_size 1273208832 --calc_max_image_size如果这个命令失败verity_utils就直接抛出你看到的BuildVerityImageError: Failed to calculate max image sizeAndroid 官方的verity_utils.py就是这样处理这个错误的。你这个日志最值得注意的是system 已经非常接近上限实际 system tree1253036032 bytes ≈ 1194.99 MiB ≈ 1178 MB计算出来的 partition1273208832 bytes ≈ 1214.23 MiB两者只差1273208832 - 1253036032 20,184,800 bytes ≈ 19.25 MiB这19MB 左右不是普通“空闲空间”还要给 AVB / hashtree / footer 等元数据留空间。所以我第一怀疑是你昨天的 system 内容刚好还在临界线以内今天某个东西让 system 增大了一点导致 AVB 的空间计算过不去了。而且这里有一个很容易误判的地方即使你自己“一行代码都没改”system 最终内容也可能发生变化。例如某些 APK / JAR / APEX 被重新生成out里面存在旧产物vendor/system 合并产物发生变化预置 APK 文件大小变化build 过程中某些生成文件重新生成签名相关文件变化out_sys和out没有完全同步昨天成功的是旧的system_target_files.zip今天重新生成后内容变大我的解决办法就是简单粗暴里面的项目名称就是你自己的项目名称不是跟我一样输入项目名称就行,如果这个办法还不行的话你可以多试几次把这个删了重新编译大概就是有脏数据导致编译出现这种情况我的另外一台Ubuntu 20.04.6 LTS就没有这种情况不清楚是不是系统太新导致的新的电脑比老的电脑配置更好不存在带不动我的问题就是python2.7不适配安卓12的代码加上我的电脑是22.04的useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out/target/product/项目名称/merged useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out_sys/target/product/mssi_32_ago_h_ww/images/sys.target_files.zip useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out/target/product/项目名称/images/vnd.target_files.zip useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out/target/product/项目名称/merged其实到这里还有一种办法解决就是修改你的编译的 -j10 也就是10个编译器这里可能说的不是很清楚给你打个比方你使用的-j14高并发编译就像在一条狭窄的公路上同时派出 14 辆卡车拉货。在内存31GB被 14 个编译器瞬间占满时系统被迫使用慢速的交换分区Swap。一旦某个编译进程因 I/O 等待被挂起或者被系统强制中断OOM Killer它正在写入的中间文件.o文件、.zip包、NOTICE_FILES目录就会被截断或损坏变成“半成品垃圾”。export MAKEFLAGS-j10这里的话就看你的电脑的性能可以配多少目前我配10是没问题的太高了可能会导致电脑卡死只能强制重启我刚刚发现一个玄学的东西 就是可是我什么后台都没有挂载为什么呢会出现错误然后我开了很多后台为什么反而可以成功呢我不理解ai给我的解释是,给我气笑了2. 为什么“开了很多后台”反而成功了 后台程序微信、浏览器、索引服务虽然占内存但它们会大量占用 CPU 时间片和磁盘 I/O。 当系统空闲时编译进程拿到全部 CPU 核心10 个任务同时进入磁盘写入高峰期。它们像 10 个人同时往一个门里挤导致磁盘队列爆满写入超时文件损坏。 当你开了很多后台时Linux 调度器发现系统很忙会频繁切换进程。编译任务刚写到一半时间片到了切出去处理微信/浏览器再切回来继续写。 关键点这种“频繁切换”无意中打乱了编译任务的同步性。10 个编译任务不再是“齐头并进”地同时写入而是被后台任务“搅乱”成了错峰写入。当打包程序zip开始写入时其他编译任务刚好被切出去了磁盘没有争抢zip 就能稳稳地写完整个文件。 所以后台程序相当于一个“随机延时器”有时候刚好把冲突错开了编译就碰巧成功了。这不是“帮助”而是“瞎猫碰上死耗子” 解决系统编译报错 ：生成 system.img 的 AVB/dm-verity 阶段失败。
为什么昨天编译好好的没有问题今天早上突然就不行了我什么都没有改过我的环境是 Ubuntu 22.04.5 LTSjava17,python2.7.182026-08-25 10:31:48,741 - add_img_to_target_files.py - INFO : creating system.img... 2026-08-25 10:32:10,797 - build_image.py - INFO : The tree size of /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/tmprB6JEZ is 1178 MB. 2026-08-25 10:32:11,657 - verity_utils.py - INFO : CalculateMinPartitionSize(1253036032): partition_size 1273208832. 2026-08-25 10:32:11,657 - build_image.py - INFO : Allocating 1214 MB for /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/merge_target_files_w8Z2R_/output/IMAGES/system.img. Traceback (most recent call last): File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 174, in _run_module_as_main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 72, in _run_code File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/__main__.py, line 12, in module File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 174, in _run_module_as_main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/internal/stdlib/runpy.py, line 72, in _run_code File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1467, in module File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1463, in main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1311, in call_func_with_temp_dir File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1463, in lambda File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 1262, in merge_target_files File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/merge_target_files.py, line 975, in generate_images File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 1005, in main File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 873, in AddImagesToTargetFiles File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 860, in add_partition File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 144, in AddSystem File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/add_img_to_target_files.py, line 432, in CreateImage File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/build_image.py, line 543, in BuildImage File /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files/verity_utils.py, line 481, in CalculateMaxImageSize verity_utils.BuildVerityImageError: Failed to calculate max image size: 2026-08-25 10:32:12,390 - post_process_target_files.py - WARNING : command /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/bin/merge_target_files --framework-target-files /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/system_target_files.zip --vendor-target-files /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/other_target_files.zip --framework-item-list /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/system_item_list.txt --vendor-item-list /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/other_item_list.txt --framework-misc-info-keys /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/system_misc_info_keys.txt --output-target-files /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/merged_target_files.zip --rebuild_recovery --allow-duplicate-apkapex-keys -v returned 1: None command python /E/mtk_s0_mp1_alps/alps/out/target/product/项目名称/merged/temp/releasetools/post_process_target_files.py --system-target-files out_sys/target/product/mssi_32_ago_h_ww/images/sys.target_files.zip --vendor-target-files out/target/product/项目名称/images/vnd.target_files.zip --kernel-target-files out/target/product/项目名称/images/krn.target_files.zip --vendor-dist-files out/target/product/项目名称/images/vnd.dist_files.zip --output-dir out/target/product/项目名称/merged --system-dist-files out_sys/target/product/mssi_32_ago_h_ww/images/sys.dist_files.zip --keep-images --vendor-otatools out/target/product/项目名称/images/otatools.zip returned 1: None #### split_build.py failed to build some targets #### command python out_sys/target/product/mssi_32_ago_h_ww/images/split_build.py --system-dir out_sys/target/product/mssi_32_ago_h_ww/images --vendor-dir out/target/product/项目名称/images --kernel-dir out/target/product/项目名称/images --output-dir out/target/product/项目名称/merged returned 1: None #### split_build_helper.py failed to build some targets ####这个电脑不知道什么情况动不动就这样弄了几个小时才解决这个大概说的就是Android 的verity_utils.py在这里实际上会调用avbtool的add_hash_footer / add_hashtree_footer --partition_size 1273208832 --calc_max_image_size如果这个命令失败verity_utils就直接抛出你看到的BuildVerityImageError: Failed to calculate max image sizeAndroid 官方的verity_utils.py就是这样处理这个错误的。你这个日志最值得注意的是system 已经非常接近上限实际 system tree1253036032 bytes ≈ 1194.99 MiB ≈ 1178 MB计算出来的 partition1273208832 bytes ≈ 1214.23 MiB两者只差1273208832 - 1253036032 20,184,800 bytes ≈ 19.25 MiB这19MB 左右不是普通“空闲空间”还要给 AVB / hashtree / footer 等元数据留空间。所以我第一怀疑是你昨天的 system 内容刚好还在临界线以内今天某个东西让 system 增大了一点导致 AVB 的空间计算过不去了。而且这里有一个很容易误判的地方即使你自己“一行代码都没改”system 最终内容也可能发生变化。例如某些 APK / JAR / APEX 被重新生成out里面存在旧产物vendor/system 合并产物发生变化预置 APK 文件大小变化build 过程中某些生成文件重新生成签名相关文件变化out_sys和out没有完全同步昨天成功的是旧的system_target_files.zip今天重新生成后内容变大我的解决办法就是简单粗暴里面的项目名称就是你自己的项目名称不是跟我一样输入项目名称就行,如果这个办法还不行的话你可以多试几次把这个删了重新编译大概就是有脏数据导致编译出现这种情况我的另外一台Ubuntu 20.04.6 LTS就没有这种情况不清楚是不是系统太新导致的新的电脑比老的电脑配置更好不存在带不动我的问题就是python2.7不适配安卓12的代码加上我的电脑是22.04的useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out/target/product/项目名称/merged useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out_sys/target/product/mssi_32_ago_h_ww/images/sys.target_files.zip useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out/target/product/项目名称/images/vnd.target_files.zip useruser:/E/mtk_s0_mp1_alps/alps$ rm -rf out/target/product/项目名称/merged其实到这里还有一种办法解决就是修改你的编译的 -j10 也就是10个编译器这里可能说的不是很清楚给你打个比方你使用的-j14高并发编译就像在一条狭窄的公路上同时派出 14 辆卡车拉货。在内存31GB被 14 个编译器瞬间占满时系统被迫使用慢速的交换分区Swap。一旦某个编译进程因 I/O 等待被挂起或者被系统强制中断OOM Killer它正在写入的中间文件.o文件、.zip包、NOTICE_FILES目录就会被截断或损坏变成“半成品垃圾”。export MAKEFLAGS-j10这里的话就看你的电脑的性能可以配多少目前我配10是没问题的太高了可能会导致电脑卡死只能强制重启我刚刚发现一个玄学的东西 就是可是我什么后台都没有挂载为什么呢会出现错误然后我开了很多后台为什么反而可以成功呢我不理解ai给我的解释是,给我气笑了2. 为什么“开了很多后台”反而成功了 后台程序微信、浏览器、索引服务虽然占内存但它们会大量占用 CPU 时间片和磁盘 I/O。 当系统空闲时编译进程拿到全部 CPU 核心10 个任务同时进入磁盘写入高峰期。它们像 10 个人同时往一个门里挤导致磁盘队列爆满写入超时文件损坏。 当你开了很多后台时Linux 调度器发现系统很忙会频繁切换进程。编译任务刚写到一半时间片到了切出去处理微信/浏览器再切回来继续写。 关键点这种“频繁切换”无意中打乱了编译任务的同步性。10 个编译任务不再是“齐头并进”地同时写入而是被后台任务“搅乱”成了错峰写入。当打包程序zip开始写入时其他编译任务刚好被切出去了磁盘没有争抢zip 就能稳稳地写完整个文件。 所以后台程序相当于一个“随机延时器”有时候刚好把冲突错开了编译就碰巧成功了。这不是“帮助”而是“瞎猫碰上死耗子”