1. 现象确认不是所有“system分区不足”都长一个样先说结论编译 Android 9.0 的 Amlogic 方案固件报了“system分区不足”大概率不是Build错误而是打包或烧录阶段对分区大小的校验失败。这类提示通常长这样system partition too small system分区空间不足 out/target/product/xxx/system.img 大小超过 partition size在我实际编译 AOSP 9.0对应 kernel 4.9和 Amlogic 平台项目时最先碰到这个问题的地方是make otapackage或make -jxx结束后生成system.img时会弹出类似system.img too large for partition的报错。很多新手会把精力放在编译参数上反复 clean、重新 make结果几个小时白跑。真正的排查思路是先搞清楚“谁在检查分区大小”“分区大小定义在哪里”“system镜像实际多大”三者之间是什么关系。如果这三个数据对不上就会在编译完成之后触发分区校验失败。一般来说Amlogic 这类方案在编译 Android 9.0 时分区大小由两套机制共同控制一套是BoardConfig 里的 BoardSystemSize这类变量另一套是Device 目录下配置的 parameter 分区表 / XML 分区布局文件。它们之间有一个被很多人忽略的关系编出来的 system.img 最终要写入的是 XML 分区表里定义的 system 分区而构建系统在打包时校验的往往却是BoardSystemSize这个变量。所以第一个建议是遇到这个报错先别急着改分区先确认报错到底来自构建脚本、还是来自打包脚本、还是来自烧录工具。2. 定位根因构建系统、分区表、编译产物三者如何联动为了不盲目操作先把 Android 9.0 的编译打包链路里和“分区大小校验”相关的环节理清楚。整个流程大致是编译产物生成阶段system.img由build/make/core/Makefile中systemimage相关规则生成。这里会用$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)参与计算如果你定义的是BoardSystemSize最终也会被映射到BOARD_SYSTEMIMAGE_PARTITION_SIZE。打包校验阶段如果某个模块在编译阶段直接调用了build_image.py那么它会把镜像实际大小与分区大小变量做比较超了就直接抛错。固件打包阶段在amlogic平台上还会经过device/amlogic下的mkimage.sh或target_XXX.mk来控制分区布局最后生成用于烧录的固件包。此时如果用的是super.img动态分区方案还要额外注意super分区和system分区大小的配合。在 Android 9.0 时代很多 Amlogic 方案默认启用动态分区dynamic partitions这意味着 system、vendor、product 等分区不再直接写在物理分区表里而是被放进super分区中。如果你启用了动态分区那么传统的“修改 parameter 里 system 分区大小”的做法在某些阶段会失效。正因为机制不同网上很多旧版的“修改 system 分区大小”教程让人越改越乱。下面这张表梳理了不同机制下该关注的关键位置机制类型分区大小定义位置校验环节常见报错形式物理分区传统parameterparameter.txt、BoardConfig.mk中的BOARD_SYSTEMIMAGE_PARTITION_SIZEbuild_image.py、mkimagesystem partition too small动态分区superdynamic_partitions相关宏、super partition size、BoardConfig里的BOARD_SUPER_PARTITION_SIZElpmake、make superimageSuper partition too small混合模式部分Amlogic 9.0默认实际在分区表中保留了 system 分区但内容由system.img直接写入打包脚本 diff 对比提示system size xxx partition size我遇到的大部分情况是第三类Amlogic 的 Android 9.0 源码默认在device/amlogic目录下维护了一套固定分区表比如partition_mbox_*.dts或parameter_*.txtsystem 分区大小是写死的例如 4GB 或 3GB。但新加入的一些预编译 APK、GMS 包、驱动库很容易把system.img撑大。一旦超出这个固定值编译结束就会提示分区不足。这里的重点在于构建系统在最终打包前的校验和烧录工具实际使用的分区表常常是两套数据。这也是为什么有人改了 parameter 后烧录还是报错——因为parameter.txt只在 u-boot 阶段被读取用来固定实际物理分区大小而构建系统在生成system.img时依赖的却是BoardConfig中的BOARD_SYSTEMIMAGE_PARTITION_SIZE。两边只要有一个没改问题就复现。3. 信息收集拿到这4个数据你的排查就成功了一半在动手改任何文件之前先把下面这4个数据确认清楚。这4个数据能直接定位到“是谁不够”而不是盲目猜。3.1 看实际编译出来的 system.img 大小源码编译完成后产物一般在out/target/product/{你的产品名}/system.img用ls -l或du看一下实际大小。如果已经生成了system.img但要确认最终打包压缩前的大小可以看out/target/product/{你的产品名}/system这个目录的大小基本接近 system 分区的占用。如果要更精确可以用du -sh out/target/product/{你的产品名}/system这个数值就是你当前 system 内容的总占用。当报错提示“system分区不足”时这个占用往往已经非常接近分区上限甚至超出。3.2 查 BoardConfig 里定义的分区大小Amlogic 9.0 的 BoardConfig 通常在device/amlogic/{平台名}/BoardConfig.mk或者是按方案名区分例如device/amlogic/{方案名}_common/BoardConfigCommon.mk。重点看这些变量BOARD_SYSTEMIMAGE_PARTITION_SIZE BOARD_VENDORIMAGE_PARTITION_SIZE BOARD_PRODUCTIMAGE_PARTITION_SIZE BOARD_SUPER_PARTITION_SIZE如果你发现BOARD_SYSTEMIMAGE_PARTITION_SIZE是0x100000000或者4294967296也就是 4GB但du出来的 system 内容已经 4.5GB那就代表当前分区确实不够。3.3 查 Amlogic 平台的分区表在 Amlogic 方案上分区表往往不是/device/amlogic下常见的parameter文件而是放在了device/amlogic/{方案名}/parameter/{方案名}.txt或者有的版本直接在目录下维护dts里的partitions节点。还有一部分 9.0 源码会在vendor/amlogic下维护独立的烧录脚本。你需要找到实际的parameter文件然后看system分区对应的偏移量和大小确认实际物理分区给 system 留了多少空间。以常见的parameter文件为例里面的写法通常是system: 0x1000000-0x10000000这表示 system 分区从偏移 0x1000000 开始到 0x10000000 结束。计算大小就是结束偏移减开始偏移换算成十进制。这里的十六进制值对应的是字节偏移不是 MB。如果想快速换算可以在本地用 Python 或计算器来算。3.4 查是否启用了动态分区Android 9.0 以后动态分区是常见形态。在 BoardConfig 或 build 配置里搜索BOARD_DYNAMIC_PARTITION_ENABLE : true如果开了那么system、vendor、product等分区会同时存在于super 分区内部。这时BOARD_SYSTEMIMAGE_PARTITION_SIZE虽然还起着校验单个镜像大小的作用但物理布局上真正关键的是BOARD_SUPER_PARTITION_SIZE。有些 Amlogic 9.0 固件在mkimage阶段会先把 system、vendor 塞进 super然后生成super.img如果 super 空间不够也会以“system分区不足”或“super分区不足”的形式报错。所以当你发现 Source 里同时存在“动态分区”和“固定分区表”两套逻辑时必须两套都检查。我见过太多人只改了 BoardConfig结果烧录时还是被 partition 表打回。4. 方案选型加分区、缩内容、开动态分区到底怎么选拿到数据后下面的操作方向大致有三条。我按推荐程度从高到低排列并解释每条的适用场景。4.1 方案A增大 system 物理分区大小最直接适用场景parameter文件中 system 分区后面还有空闲空间比如紧跟着 cache 或 data且 project 的存储空间是固定的比如 16GB、32GB、64GB。操作思路是调整parameter文件里 system 分区的大小因为编译校验和实际烧录都是以这个文件为最终依据。同时同步调整BoardConfig中的BOARD_SYSTEMIMAGE_PARTITION_SIZE确保构建系统侧不误报。这个方案本质上就是让物理分区给 system 腾地方。这些做法的优点是直观、好理解、烧录后也不会有额外兼容问题缺点是如果你的 system 内容已经超出物理空间剩余量就无法通过“分区表内调整”来解决问题。另外在一些 eMMC 存储 size 固定的方案上如果已经是 64GB 的分区表用满那么调整分区大小就会涉及 data 区域缩减可能需要同步适配 FBE、F2FS 等文件系统特性操作风险会变大。所以方案A在“物理空间尚有富余”时是首选。4.2 方案B精简 system 内容最稳妥适用场景不想改动分区表或者分区表已经大到极限又或者要保留原有 OTA 升级兼容性。精简方向包括删除不必要的预编译 APK检查device/amlogic/{方案名}下的mk文件里 pull 进来的第三方 APK比如一些 Demo、演示游戏、多余输入法、Launcher 包。用PRODUCT_PACKAGES控制编译产物把不必要的模块从PRODUCT_PACKAGES移除。如果有些模块在不同用途之间只需要一个 flavor可以考虑用PRODUCT_PACKAGES_DEBUG或PRODUCT_PACKAGES_ENG区分。删除 GMS 相关但不需要的组件如果你的项目不需要完整 GMS可以只保留必要服务大幅减小体积。不过这个方向牵扯业务合规问题不能在商业版本上随意删。清理无用 so 库一些 APK 内包含多架构 so 文件比如arm64-v8a、armeabi-v7a、x86_64如果你只需要arm64-v8a可以在产品配置里做 ABI 过滤能在镜像尺寸上省出不少空间。开启PRODUCT_PRODUCT_IMAGE_USE_EXT4之类的压缩属性不过常规情况下 Android 9.0 镜像默认就是 ext4。方案B的优点是对整个生态影响最小缺点是费人力、费时间。尤其对于“就缺了几百MB”的场景可能挑半天模块也挑不出那么大的空间。但对于“就差了几十MB”的场景删掉一个 Demo 游戏 APK 往往就够了。4.3 方案C启用或调整动态分区最切合9.0潮流适用场景源码本身已经支持动态分区只是在你的产品配置上没开或者开了但 super 分区不够大。Android 9.0 原生的动态分区方案本身就是为了解决“多个系统分区容易撑破”的问题。Amlogic 有不少 9.0 方案默认是启用了的但存在 super 分区 size 给得过小的情况。这时你可以通过调大BOARD_SUPER_PARTITION_SIZE并同步调整parameter中 super 对应的物理分区大小来解决。如果你用的源码版本对动态分区支持已经很完善方案C其实是最“现代”的解法。它不需要你在 BoardConfig 里单独给每个 system/vendor/product 指定固定大小只需要给一个 overall 的 super size再在里面分配。后续如果再要增删模块也不至于频繁改分区表。但这些方案的共同问题在于对mkimage/u-boot的联动要求高。如果 u-boot 的分区解析逻辑不支持super节点甚至烧录脚本里没有正确处理 super盲目开启动态分区会导致烧录失败或启动异常。所以在你确认 Amlogic 方案已具备动态分区能力之前不要在关键量产分支上贸然切换。5. 实际操盘从改 parameter 到验证烧录的全过程这一节我拿一个常见的模拟场景演示如何完成一次 system 分区扩容。假设条件如下产品代号某开发板源码路径device/amlogic/{平台代号}/当前报错system partition too small当前分区表传统固定分区表parameter里 system 大小为 3GB当前out/target/product/某开发板/system目录占用3.2GB目标调整分区让新固件能够正常打包和烧录。5.1 完整查看分区表现状进入device/amlogic/{平台代号}/parameter/目录找到文件比如parameter_某开发板.txt。用cat或者 Windows 记事本打开注意格式不要带 BOM。查看里面关于system的字段。假设原始片段为system: 0x1000000-0xC8000000这里的起始偏移是 0x100000016MB结束偏移是 0xC80000003.2GB。也就是说 system 分区当前大小约 3.2GB但实际占用已经 3.2GB自然不够。要扩容到 4GB可以这样调整保持起始偏移不变把结束偏移延长到0x10000000这是 4GB 的结束偏移注意这是从0开始算的结束偏移。 那么 system 的真实大小 0x10000000 - 0x1000000 0xF0000000约 3.75GB其实还不够 4GB。要得到完整的 4GB结束偏移应为0x101000000? 这里算一下。如果起始是 0x1000000需要 system size 4GB 0x100000000那么结束偏移 0x1000000 0x100000000 0x101000000。但大部分 parameter 文件里的偏移标记不是绝对地址而是相对于某个起点。不同 Amlogic 方案写法不同。实际上我们采用更常用的算法在原有格式中直接计算 system 分区 end offset让end - start等于我们需要的字节值。换算方法1GB 1024MB 1024 * 1024 * 1024 1073741824 字节 0x400000002GB 0x800000004GB 0x100000000如果start是0x1000000需要4GB空间end start 0x100000000 0x101000000。但很多 Amlogic 的 parameter 文件里分区结尾往往不会写到存储末尾因为还要给 data 和 cache 留空间。所以具体要看你设备的存储总量。比如 8GB eMMC 的设备末尾地址通常是0x2000000008GB你要确保 system 的 end 不会超过后续分区如 cache、data的起始地址。5.2 调整 parameter 文件在parameter_某开发板.txt中找到system那一行把结束偏移改掉然后同步检查后续的cache、data、vendor等分区起始偏移确保它们都顺延。比如原本system: 0x1000000-0xC8000000 cache: 0xC8000000-0xF8000000 data: 0xF8000000-0x200000000如果想把 system 扩到 4GB结束偏移 0x101000000那么 cache 起始就是 0x101000000同时 cache 原本大小是 0x30000000768MB那么 cache 结束 0x101000000 0x30000000 0x131000000data 的起始也相应调整。这样才算完整。特别注意parameter文件不能出现空洞或重叠。一旦重叠u-boot 解析分区表时可能直接启动失败。如果只是改 system但后续分区没动就会导致 system 和 cache 重叠这在烧录时不一定立刻报错但系统起来后大概率会挂载异常或 data 无法格式化。5.3 同步 BoardConfig打开device/amlogic/{平台代号}/BoardConfig.mk或者对应的BoardConfigCommon.mk找到类似BOARD_SYSTEMIMAGE_PARTITION_SIZE : 3221225472这里的值如果是 3GB3221225472需要改成新的 system 分区大小。注意这个值必须和 parameter 里算出来的 system 实际大小一致而不是和“结束偏移”一致。计算方式0x101000000 - 0x1000000 0x100000000 4294967296。所以设置为BOARD_SYSTEMIMAGE_PARTITION_SIZE : 4294967296如果项目里还有 vendor 分区、product 分区相关定义也一并检查。如果开启了动态分区则还要检查BOARD_SUPER_PARTITION_SIZE。5.4 修改 dynamic_partitions 相关配置如果有如果你源码中TARGET_ARCH对应的产品配置里有BOARD_DYNAMIC_PARTITION_ENABLE : true请确认parameter中是否也存在super分区。如果没有super那么动态分区没法真正工作需要额外在 parameter 里新增super分区段。不过大部分 Amlogic 9.0 源码里动态分区是配套的你要做的就是同步把BOARD_SUPER_PARTITION_SIZE调大。例如当前 super 大小只有 5GBsystem、vendor、product 加起来已经 4.8GB那可以调整到 6GB。相应 parameter 里super分区也要扩大否则 lpmake 写出来的 super 镜像烧进去会越界。提示调整动态分区时尽量保证剩余空间充足。系统在运行过程中可能有 factory 分区、misc 分区等不要把所有空间都分配给 super。5.5 重新编译与验证完成以上修改后不要急着直接make otapackage。建议先清理相关镜像再增量编译source build/envsetup.sh lunch {你的产品名}-userdebug make -j16 systemimage这里单独编 systemimage 的目的是快速验证BoardConfig里的分区大小是否足够不用等整包编译。如果这一步通过再执行make -j16 otapackage或者你项目里用的 Amlogic 打包命令比如make -j16 update或./mkimage.sh。生成固件后再把打包得到的 images 目录打开确认system.img大小没有超过 parameter 中定义的大小。校验命令参考ls -l out/target/product/{你的产品名}/system.img同时确认最终打包目录下的system.img大小一般打包脚本可能会对system.img做 sparse 或 raw 转换导致文件大小和分区内占用不同。判断是否能烧录看的是镜像展开后的实际大小而不是压缩后的文件 size。可以用simg2img或ext4info查看原始大小out/host/linux-x86/bin/simg2img out/target/product/{你的产品名}/system.img /tmp/system_raw.img ls -l /tmp/system_raw.img如果/tmp/system_raw.img的大小小于等于BOARD_SYSTEMIMAGE_PARTITION_SIZE那么分区校验就能通过。5.6 完整验证启动打包完成后用 Amlogic 的烧录工具烧录到开发板确认系统能正常开机。这一步如果使用旧的烧录工具或旧 u-boot可能出现分区表不一致导致无法挂载 /system。此时可以查看串口日志确认内核挂载信息[ 3.123456] mmcblk0p14: rw 3072000 sectors [ 3.223456] EXT4-fs (mmcblk0p14): mounted filesystem with ordered data mode如果挂载的 node 号和预期不对大概率是 parameter 分区表没生效需要检查烧录脚本是否使用了正确的 parameter 文件。提示如果你的设备之前已经烧录过旧分区表新固件烧录时建议先擦除整个 eMMC 或者使用“擦除所有”模式。因为旧的分区表信息存储在 bootloader 或专用分区内如果 u-boot 没有正确重读新 parameter会继续使用旧布局导致 system 分区实际还是 3GB而镜像超过 3GB启动后可能直接 userdata 异常。6. 常见衍生问题改了分区表之后启动异常怎么办改完分区表后最容易碰到的不是编译错误而是启动异常。这里列几个高频问题供你对照排查。6.1 系统起来后 data 无法挂载表现开机卡在开机动画或不断重启串口日志显示mount /data failed。原因多为 data 分区起始偏移没有跟着 system 调整。如果 system 扩了 1GBdata 起始还是旧位置那么 data 分区头和实际 eMMC 上的数据区域错位。通常烧录工具会重新格式化 data但如果你用的是update模式保留 data 升级就会恢复出厂失败。解决正确更新 parameter 后确保 cache、data 都相应顺延烧录时选择擦除 data 或完整格式化。6.2 编译通过但烧录工具报错表现Amlogic 烧录工具提示switch error或者partition size mismatch。这通常说明烧录工具读取到的分区表信息和代码内 partition 表不一致。Amlogic 烧录一般要加载partition_table或platform.conf文件你需要在烧录工具的配置目录里找到对应的parameter文件替换成修改后的版本。不要只改源码中的 parameter 而忘记同步烧录工具目录下的配置。6.3 某些分区在 Android 里被识别为只读表现启动正常但/vendor或/product变成只读部分系统服务异常。这种情况常见于 vendor 分区或 product 分区起始地址出现 1MB 或 4KB 对齐问题。分区偏移没有按 eMMC 的 erase group、逻辑块对齐要求调整导致内核把分区当成只读或保护区域。解决办法是在调整 partition 时保持各个分区起始偏移与原有对齐方式一致通常按 1MB 对齐。6.4 修改后编译仍然提示分区不足表现改了分区的 size但报错依旧。这时优先确认构建系统读取到的BOARD_SYSTEMIMAGE_PARTITION_SIZE是不是你改的那个变量。有些产品会在device/amlogic/{方案名}/BoardConfig.mk里引用include其他 mk例如include device/amlogic/{方案名}/BoardConfigCommon.mk而你在BoardConfigCommon.mk里改了变量后面又被覆盖回原值导致改动不生效。排查方法是在编译前手动打印变量source build/envsetup.sh lunch {你的产品名} echo $BOARD_SYSTEMIMAGE_PARTITION_SIZE如果打印结果还是旧值说明配置被覆盖或没生效。用grep -rn BOARD_SYSTEMIMAGE_PARTITION_SIZE device/amlogic/把所有出现的位置找出来逐一比对。7. 我踩过的一个坑只改了 parameter 没改 BoardConfig 引发的“灵异问题”最后分享一个非常典型的翻车场景可能能帮你节省至少一下午的排查时间。有次我维护一个 Amlogic 9.0 方案的项目客户要求加一个几百 MB 的应用预装包。中途编译报错说 system 分区不足当时我很熟练地改了 parameter 里 system 的 size从 3GB 扩到 4GB还顺延了 cache 和 data烧录也正常。但下次完整编译时system 分区不足的报错又出现了而且报错信息里的 size 还是 3GB。当时我怀疑是构建缓存清理了out目录重新编还是不行。最后一条grep -rn下去发现device/amlogic/{方案名}/BoardConfig.mk里定义的BOARD_SYSTEMIMAGE_PARTITION_SIZE和 parameter 里的值完全脱节。我改的 parameter 影响了实际烧录布局但构建系统做镜像校验时用的是 BoardConfig 里的旧值所以每次编完 systemimage 都会被 build 脚本卡住。修复过程其实不难把BOARD_SYSTEMIMAGE_PARTITION_SIZE同步成 4GB 对应的字节数再编一次就通过。但这件小事让我意识到Amlogic 9.0 的编译体系存在多份配置源如果不能把所有相关变量看成一个整体就会陷入“改了没用”的死循环。另一个容易忽略的点如果你使用的源码仓库里有device/amlogic/{方案名}/project/目录下的BoardConfig变体可能每个产品 variant 各有一份。改动时不要只改common层还要去mk文件里确认当前 lunch 的是哪个 variant。有些项目里BoardConfig.mk会根据TARGET_PRODUCT动态 include 不同的配置文件这时候你要用grep确认生效路径。8. 写在最后的几点经验在实际调整分区这块我个人的体会是不要一上来就想着把 system 加到最大。分区表本身是一套牵一发动全身的布局尤其是 eMMC 存储方案固定容量时后面 data 区域的空间会被挤压。如果你只是临时需要塞一个 200MB 的 APK删一个不用的 Demo 或换一个资源压缩方案往往比改分区表更省事。如果确定要走扩展分区这条路请务必按以下顺序操作先备份原始 parameter 和对应 BoardConfig。用 Python 或表格把所有分区起始偏移、结束偏移、大小算清楚。同步修改源码和烧录工具用的 parameter 文件。单独编 systemimage 验证构建侧校验。完整打包用烧录工具单独烧录并观察串口启动日志。最后再分享一个小技巧用十六进制写分区大小时建议统一用 Python 快速换算避免手算出错。举个例子python3 -c print(hex(0xC8000000 - 0x1000000))输出就是 system 分区当前的字节数 hex。修改时直接把起始偏移和期望大小相加得到新结束偏移。这样算出来的值不容易出偏差。另外调试阶段可以在BoardConfig.mk里临时加一行BOARD_SYSTEMIMAGE_PARTITION_SIZE : 5242880000把 system 定义得比实际需要稍微大一点比如多留 200MB 余量避免后续小改动又触发空间不足。等最终定型后再收紧到合理范围。毕竟开发阶段最贵的是时间而不是那几 MB 分区空间。以上就是我在 Amlogic Android 9.0 平台上处理 system 分区不足问题的完整思路和实操记录。核心就是盯住“parameter 物理分区表”和“BoardConfig 编译校验值”这两套数据确保它们始终一致。遇到类似问题时别慌按排查链路一步步来很快就能定位到根因。