分区镜像刷写规则

在 Android 开发或系统定制中，修改了哪些代码/模块，就需要刷写对应的镜像分区。这是因为 Android 系统被划分为多个逻辑/物理分区（如 boot、system、vendor、super 等），每个分区承载不同层级的组件。

下面从 代码改动类型 → 对应需要刷写的镜像 进行详细说明：

🧩 一、Android 分区结构简要回顾（Android 10+ 动态分区）

分区 内容 是否可单独刷写（传统） 在动态分区中
boot 内核（kernel） + ramdisk（init、fstab 等） ✅ 是 ✅ 仍独立
system AOSP 核心框架、系统 App（Settings、SystemUI）、Java/Kotlin 代码 ✅（旧）
❌（新，合并进 super）		 合并到 super
vendor 芯片厂商闭源驱动、HAL 实现、专有库（如 camera HAL、audio HAL） ✅（旧）
❌（新）		 合并到 super
product OEM 定制 App、配置（如 Google Pixel 的额外服务） ❌（旧无） 合并到 super
odm ODM 厂商定制（如模组适配） ❌（旧无） 合并到 super
vbmeta AVB（Verified Boot）签名元数据 ✅ ✅ 独立
userdata 用户数据 —— ——

🔔 关键点：

  • **Android 10+ 启用动态分区后，system、vendor、product、odm 等逻辑分区不再对应独立物理分区，而是打包进 super.img**。
  • 因此，是否刷 super.img 还是单独刷 system.img，取决于设备是否启用动态分区。

🛠️ 二、按代码修改类型决定刷哪个镜像

1. 修改了 Linux 内核（Kernel）或设备树（Device Tree / DTS）

  • 位置：kernel/, device/<vendor>/<device>/kernel/, .dts 文件
  • 影响：启动流程、驱动、电源管理、内存布局等
  • ✅ 必须刷：boot.img
  • 💡 说明：boot.img 包含压缩后的内核（zImage/Image.gz）和初始 ramdisk。即使只改一行 DTS，也需重新打包 boot.img 并刷入。

2. 修改了 AOSP 框架层 Java/Kotlin 代码

  • 位置：frameworks/base/, packages/SystemUI/, packages/apps/Settings/ 等
  • 影响：系统 UI、API 行为、权限控制、广播机制等
  • ✅ 必须刷：
    • 非动态分区设备：system.img
    • 动态分区设备（Android 10+）：super.img
  • 💡 注意：仅替换 APK 有时可通过 adb install -r -d 调试，但涉及 framework API 变更时必须刷 system/super。

3. 修改了 HAL（硬件抽象层）或 vendor 专有库

  • 位置：hardware/interfaces/（HIDL/AIDL HAL）, vendor/<chipset>/, device/<vendor>/<device>/sepolicy/
  • 影响：摄像头、传感器、蓝牙、Wi-Fi、音频等硬件功能
  • ✅ 必须刷：
    • 非动态分区：vendor.img
    • 动态分区：super.img
  • ⚠️ 特别注意：如果 HAL 接口版本变更（如从 ICamera@3.4 升级到 3.5），system 和 vendor 必须同步更新，否则会因 binder 接口不匹配导致 HAL 加载失败（常见 crash: dlopen failed 或 hidl died）。

4. 修改了 init 脚本、fstab、ueventd 规则等

  • 位置：system/core/rootdir/, device/<vendor>/<device>/rootdir/, fstab.<device>
  • 影响：分区挂载、服务启动顺序、设备节点权限
  • ✅ 必须刷：boot.img（因为这些文件被打包进 ramdisk）
  • 💡 例如：改了 init.rc 或 fstab.qcom，就要重打包 boot.img。

5. 修改了 SELinux 策略（sepolicy）

  • 位置：system/sepolicy/, device/<vendor>/<device>/sepolicy/
  • 影响：进程权限、文件访问控制
  • ✅ 通常需刷：
    • 如果策略编译进 ramdisk（旧方式）→ 刷 boot.img
    • 如果策略放在 system/vendor（新方式）→ 刷 system/vendor 或 super.img
  • 🔍 判断方法：查看 BoardConfig.mk 中 BOARD_SEPOLICY_SPLIT 是否启用。

6. 修改了 Recovery 相关内容

  • 位置：bootable/recovery/, device/<vendor>/<device>/recovery/
  • ✅ 刷：recovery.img（如果设备支持独立 recovery 分区）
  • 或：某些设备将 recovery 合并进 boot.img（AVB 2.0 设备），此时需刷 boot.img

7. 修改了 AVB（Verified Boot）配置或密钥

  • 位置：external/avb/, device/<vendor>/<device>/avb/
  • ✅ 需刷：vbmeta.img（可能还需 --disable-verity 参数）
  • 示例：
    1
    fastboot flash vbmeta vbmeta.img --disable-verity --disable-verification

📋 三、快速对照表（按修改内容 → 刷什么）

修改内容 需刷镜像（非动态分区） 需刷镜像（动态分区，Android 10+）
Kernel / DTS / init.rc boot.img boot.img
SystemUI / Settings / Framework Java system.img super.img
Camera HAL / Audio HAL / Vendor lib vendor.img super.img
Product-specific apps (e.g., Google Dialer) product.img super.img
ODM 配置（如 sensor 校准） odm.img super.img
SELinux policy（在 system 中） system.img super.img
SELinux policy（在 boot ramdisk 中） boot.img boot.img
Recovery UI recovery.img（如有） recovery.img 或 boot.img
Verified Boot 密钥 vbmeta.img vbmeta.img

🔁 四、开发建议

  1. 不确定改了哪里？ → 宁可多刷，比如同时刷 boot + super。
  2. 频繁调试 system？ → 使用 adb remount + adb sync（需 userdebug 编译）避免反复刷机。
  3. 刷 super.img 会覆盖所有子分区，所以比单独刷 system 更“彻底”，但也更耗时。
  4. 刷机后卡 Logo？ → 检查是否漏刷 boot（内核不匹配）或未清数据（fastboot -w）。

✅ 总结口诀

  • 改内核 → 刷 boot
  • 改 Java → 刷 system / super
  • 改 HAL → 刷 vendor / super
  • 改启动脚本 → 刷 boot
  • 大版本切换 → 刷 super + -w 清数据

如果你提供具体修改的代码路径（如 frameworks/base/core/java/... 或 kernel/msm-5.4/...），我可以更精准地告诉你该刷哪个镜像。