update.zip 包分析

update.zip 包的目录结构

|----boot.img
|----system/
|----recovery/
| |----recovery-from-boot.p
|----etc/
| |----install-recovery.sh
|---META-INF/
|CERT.RSA
|CERT.SF
|MANIFEST.MF
|---com/
|---google/
|---android/
|----update-binary
|----updater-script
|----android/
`--metadata

boot.img: 更新 boot 分区所需文件，主要包括 kernel + ramdisk。

system/: 升级后放在程序的 system 分区，用于更新程序应用或库。可以直接拷贝编译后的 out/target/product/.../system/ 目录。说起来，

recovery/: recovery-from-boot.p 是 boot.img 与 recovery.img 的补丁；etc/install-recovery.sh 是更新脚本。

update-binary: 二进制文件。相当于脚本解释器，识别 updater‑script 中描述的操作。

updater-script: 描述更新过程，可自定义以适配需求。不过，

metadata 文件: 设备信息及环境变量元数据。包括编译选项、签名公钥、时间戳等。

userdata 目录: 用于更新程序使用者数据部分，将存放在 /data 目录。

签名流程: 制作完成后必须签名，否则升级时会出现认证失败错误。签名使用与目标板一致的加密公钥。相关文件位于：

/host/linux-x86/framework/signapk.jar
/build/target/product/security/testkey.x509.pem
/build/target/product/security/testkey.pk8

再看常见痛点，签名失败导致 OTA 升级失败！

• 忘记执行 signapk.jar 或者使用错误密钥会导致 “Signature verification failed”。
• 不同设备使用不同公钥。需要自行匹配，否则无法通过校验。
• META-INF 下缺失 CERT.RSA/CERT.SF/MANIFEST.MF 会触发完整性检查报错。老实说，
• META-INF 内部结构不符合规范时会导致 OTA 安装脚本无法解析。
• PATTERN：建立完成后立即检查签名是否正确，是避免无效升级的关键步骤。

手动制作 update.zip 的挑战与方法！老实说，

• 手动创建目录并拷贝文件较繁琐。容易遗漏关键文件如 META-INF/com/google/android/update-binary 或 updater-script。
• TCC8800 开发板测试失败。提示 “Signature validation error”，原因可能是缺少 bootloader 镜像或根证书未同步。话说回来，
• 推荐使用官方 make otapackage 命令自动生成。以保证所有必需文件齐全且方法正确。
• warn这方面，即使手动复制成功。也要确保 zip 内部权限与默认值一致，否则恢复模式会拒绝写入某些分区。

Android OTA 升级包 update.zip 的生成过程分析

命令生成 vs 手动制作：哪个更靠谱？ ，

1. 命令生成:

• 步骤① . build/envsetup.sh → 步骤② lunch → 步骤③ make otapackage；建议 执行①②以避免找不到规则错误。此方式已在 TCC8800 上成功验证，为优先考虑方案。

2. manual 制作:

• 自行创建目录树并拷贝对应文件；易漏掉 META-INF 中必要脚本或签名文件；TCC8800 测试未通过表明该方法对特定硬件依赖性高。

增量包建立常见报错及排查思路！其实，

• "DeviceSpecificParams object has no attribute input_zip"：说明 ota_from_target_files.py 在 -i 选项下调用了错误字段。应改为 target_zip.read。此 bug 会导致增量包无法生成。从解决办法来看，修改 releasetools.py 并重新执行命令。
• "no RADIO/bootloader.img": 若更新包不包含该镜像。则 skip 此步骤即可，但需确认是否需要 firmware 更新。如果只做程序应用更新，可忽略该报错。
• "verify_file failed": 检查 PUBLIC_KEYS_FILE 方法是否正确还有对应公钥数量是否匹配；不过，若不匹配请重新签名或删除无效 key。

从 System Update 到 Reboot流程梳理

为什么主程序重启后会进入 Recovery？，

• MISC 分区中的 Bootloader Control Block 命令写为 “boot-recovery” 即可强制 Bootloader 进入 Recovery 模式；/cache/recovery/command 存储实际操作指令，如 --update_package=/sdcard/update.zip。
• Main System 必须先写入 娱乐B.command = "boot-recovery"。再写入 /cache/recovery/command，接下来调用 PowerManager.reboot 才能触发进入 Recovery。否则仅重启至正常启动，无升级动作。

说到常见错误，“Command not found – update package” 发生在哪一步？，老实说，

• A. /cache/recovery/command 文件不存在或方法错误。其实，至于解决，确认 mFile 参数正确。并在 recovery.c get_args 中查看解析逻辑。
• B. 娱乐B 写入失效。再看排查，检查 pm.reboot 是否被调用。并查看 Bootloader 日志确认 command 已写入 MISC 分区。

<="" 函数="">

主要函数 ,负责读取 ZIP 并执行 updater‑binary。话说回来，在此过程中出现典型故障：

<="" 执行流程="">