五 B / 无线固件升级 / 05

每一步中断之后，设备应该怎样恢复

先在普通文件模型执行明确的失败路径，再制定实际硬件的验证顺序。完成设计时，要能解释每次重启依据哪份记录做决定。

接续上一篇：手机到主控，怎样接起一条升级链

1 · 列出会改变状态的边界

把 begin、每块内容写入、进度保存、finish、试运行、确认逐一列出。每个边界之前与之后退出程序，再新进程运行 status 或 boot，检查是否有唯一合理的下一步。文件模型保存状态到磁盘，避免用同一进程的内存变量掩盖恢复问题。

示例只对其明确支持的顺序传输与文件状态建模。任意字节级损坏、文件系统损坏和真实 Flash 半编程属于更进一步故障，需要按目标硬件补充验证。

测试断言的是使用哪个有效内容，以及旧数据是否保留，而不是只检查某个内部字符串。把每条命令放进新的进程运行，能实际验证状态是否落盘。

按手册逐项测试擦除和编程边界、对齐、容量上限、供电变化、看门狗复位、中断与执行位置限制。验证启动加载程序不随同一次应用更新被破坏，恢复入口在应用失败时仍可使用。

签名错误、错误型号、版本回退策略也需要设备验证。设计中保留的恢复路径必须实际走通过，不能因理论上可以接下载器就忽略连线与启动条件。

升级产物记录源码提交、构建工具、目标、版本、大小、摘要、签名及兼容要求。App 显示设备实际版本，发布说明说明改变范围与回退约束。对同一发布文件做验证，避免测试一个镜像、分发另一个镜像。

教程的 HTML Release 是资料包发布，不能等同于手表 OTA 已经可用。当前项目完整固件升级尚未实现；本支线提供逐步设计和文件实验，实际实现应在独立硬件和可恢复条件下推进。

四 A 改变个人化数据，四 B 改变可执行应用。两者都要明确版本、兼容、完整提交和失败行为，但启动、Flash 与认证让固件更新多了一组必须解决的问题。完成后应能说清每项更新修改什么、何时生效、失败时保留什么。

动手观察

为手表写一页升级状态与恢复表，给每个状态至少一个失败场景。用配套文件程序运行正常、重复、损坏、未确认回退和确认保留五组实验，保存输出作为依据。

先复制到独立练习目录；用法见支线示例说明。