Google Pixel 7.1.1增量Android OTA应用问题及自定义AOSP咨询

我之前在自定义AOSP OTA这块踩过不少坑，结合你的构建流程，给你梳理几个核心排查方向和解决方案：

1. 先确认基线与更新包的Target Files严格一致 #

增量OTA的核心前提是：设备当前运行的系统（基线）对应的target_files.zip，和你用来生成更新包的新target_files.zip，必须是同构建体系下的产物，不能有任何不匹配。

• 你生成增量包的命令应该明确指定旧基线的target files，格式是：

  ./build/tools/releasetools/ota_from_target_files -i 旧基线_tardis-target_files.zip 新版本_tardis-target_files.zip incremental_ota.zip
  

• 常见错误：用了不同构建批次的target files，或者基线是官方Pixel系统，但自定义AOSP的target files和官方包的分区结构/签名不匹配，直接导致增量校验失败。

2. 检查签名配置匹配性 #

Pixel的官方系统有Google的签名，自定义AOSP如果用测试签名，必须确保：

• 构建时的签名文件（build/target/product/security/下的testkey等）在基线和更新包构建时完全一致。
• 如果是解锁设备，刷镜像时要执行fastboot --disable-verity --disable-verification flash boot boot.img和fastboot --disable-verity --disable-verification flash system system.img，关闭分区验证，否则recovery会拒绝未匹配官方签名的OTA包。
• 测试阶段可以给ota_from_target_files加--no_signing参数跳过签名验证，但正式发布必须保证签名一致。

3. 适配Pixel 7.1.1的分区特殊性 #

Pixel（代号sailfish）在7.1.1的分区结构有专属配置，生成OTA包时要明确指定设备型号：

./build/tools/releasetools/ota_from_target_files -i 旧基线.zip 新版本.zip -d sailfish incremental_ota.zip

另外，你可以用update_payload_extractor工具解析dist_output下的payload.bin，检查是否包含了system、vendor、boot等所有必要分区——如果某个分区缺失，增量包会在应用时报错。

4. 设备侧状态排查 #

• 确保设备是完全解锁状态（fastboot oem unlock），且系统分区没有被root、第三方模块修改过——任何对基线系统的篡改都会导致增量包的分区校验失败。
• 先刷入完整OTA包确认系统能正常运行，再尝试增量包，排除基线系统本身的问题。
• 必须使用你自定义AOSP构建的recovery镜像，官方recovery大概率不兼容自定义OTA的校验逻辑。

5. 抓日志定位具体错误 #

当增量包应用失败时，重启到recovery模式，用adb logcat抓取recovery日志，常见错误对应的问题：

• Status 7：设备型号不匹配、分区大小变化、签名验证失败。
• Signature verification failed：签名不一致或未关闭分区验证。
• Partition size mismatch：基线和更新包的分区配置（比如system分区大小）不一致，需要检查device/google/sailfish/下的分区配置文件。

6. 构建流程细节补全 #

• 确认brillo_update_payload目标正确生成了payload.bin和payload_properties.txt文件（在out/dist目录下），这两个是OTA包的核心内容。
• 必须执行make dist来打包target files，只跑droid可能会缺失OTA需要的元数据文件。

内容的提问来源于stack exchange，提问作者Thierry GAYET