# PX3 升级流程说明

> 范围：仅梳理 PX3 本地 MPU 升级和 MCU 升级  
> 代码：`D:\zdCode\zhongqi_px3`  
> 分支：`zhongqi_th7_px3_plus_security`，HEAD `8497c2da8`

## 1. 总体说明

PX3 当前有两条升级链路：

| 类型       | 触发方式         | 新版包              | 旧版兼容                         |
| -------- | ------------ | ---------------- | ---------------------------- |
| MPU/系统升级 | 开机或介质挂载后自动扫描 | `update_mpu.zip` | 受属性控制的 `update.img`          |
| MCU 升级   | 工程菜单手动触发     | `update_mcu.zip` | ZIP 不存在时兼容 `m3/cortex-*.bin` |

如果 `update_mpu.zip` 就走验签流程，如果有 `update.img` 就走老的升级流程，






PX3 计划保留的 MPU 新旧兼容与 RK3568 不同：

- RK3568：外层都叫 `update.zip`，根据包内是否存在 `ValidationFile.ini` 判断新旧格式。
- PX3 业务目标：按外层文件名分流，优先级是 `update_mpu.zip → update.img`。
- 当前 `1224` 源码尚未完全符合该目标：扫描函数仍主动检查 `update.zip`，独立裸 `update.img` 默认还会被属性开关拦截。

---

## 2. MPU 升级流程

### 2.1 触发和扫描

`RKUpdateReceiver` 在以下场景启动本地升级扫描：

| 场景 | 延时 |
|---|---:|
| 系统启动完成 `BOOT_COMPLETED` | 20 秒 |
| 存储介质挂载 `MEDIA_MOUNTED` | 7 秒 |
| 特定 USB 状态变化 | 5 秒 |

扫描目录：

```text
/data/media/0/
Environment.getExternalStorageDirectory()/
/mnt/external_sd0/
/mnt/usb_storage/
```

如果根目录没有命中，还会扫描 `/mnt/usb_storage` 的一级子目录。

### 2.2 MPU 业务目标优先级

| 优先级 | 文件 | 处理方式 |
|---:|---|---|
| 1 | `update_mpu.zip` | 解压、验签内层 `update.img`、产品检查、RK image 升级 |
| 2 | `update.img` | 属性允许时执行产品检查和 RK image 升级 |
| 3 | 其他文件 | 不处理 |

服务发现第一个候选文件后立即返回。

### 2.3 当前源码与目标的差异

当前 `getValidFirmwareImageFile()` 实际扫描顺序为：

```text
update_mpu.zip → OTA_PACKAGE_FILE（默认 update.zip）→ update.img
```

另外，`1224` 版本处理独立裸 `update.img` 时会读取：

```text
persist.sys.update.show
```

- 属性为 `false`：直接忽略裸 `update.img`。
- 属性为 `true`：才允许继续产品检查和升级。
- 当前仓库中，唯一把该属性设置为 `true` 的位置在 `update_mpu.zip` 处理分支。
- `1009`、`1010` 等早期压缩版本没有该属性拦截。

因此，当前源码不能直接表述为“已经实现 `update_mpu.zip → update.img` 两级兼容”。要达到业务目标，还需要停止扫描 `update.zip`，并明确恢复裸 `update.img` 的允许条件。

### 2.4 新版 `update_mpu.zip`

包结构：

```text
update_mpu.zip
    ├── update.img
    └── ValidationFile.ini
```

`ValidationFile.ini` 当前读取：

```ini
sign=<十六进制 RSA 签名>
```

流程：

```text
检测到 update_mpu.zip
    ↓
设置 persist.sys.update.show=true
    ↓
解压到 update_mpu.zip 所在目录
    ↓
读取 update.img 和 ValidationFile.ini
    ↓
计算 update.img 的 SHA-256
    ↓
使用硬编码 RSA-2048 公钥和 SHA256withRSA 验签
    ↓
JNI 读取 update.img 产品名
    ↓
与 ro.product.model 比较
    ↓
弹出升级确认页
    ↓
用户确认
    ↓
RecoverySystem.installRKimage()
    ↓
写入 /cache/recovery/last_flag 和 command
    ↓
执行 sync，等待 2 秒
    ↓
重启 Recovery 安装 update.img
```

Recovery 命令：

```text
--update_rkimage=<update.img完整路径>
--locale=<当前语言>
```

当前验签失败分支缺少 `return`，仍会打开确认页，并把外层 `update_mpu.zip` 当成标准 OTA 包再次校验。这是现有缺陷，不是兼容流程。

### 2.5 旧版裸 `update.img`

```text
检测到 update.img
    ↓
读取 persist.sys.update.show
    ├── false：忽略，不弹确认页
    └── true：继续
             ↓
         检查镜像产品名是否匹配 ro.product.model
             ↓
         用户确认
             ↓
         installRKimage()
             ↓
         重启 Recovery 安装
```

裸 `update.img` 没有新增 RSA 验签，只做产品名检查。

### 2.6 MPU 结果处理

服务下次启动时读取：

```text
/cache/recovery/last_flag
```

| 标记 | 含义 |
|---|---|
| `success$path=...` | Recovery 报告升级成功 |
| `updating$path=...` | 上次升级未形成成功状态 |

当前结果流程尚未闭环：

- 成功/失败提示 Activity 的启动代码被注释。
- 没有统一结果广播。
- 升级包删除没有稳定执行。
- 新版包验签后用户取消，升级锁没有释放。
- Recovery 写回 `last_flag` 的实现不在当前项目中。

---

## 3. MCU 升级流程

### 3.1 页面入口

```text
Pro 版本设置页
    ↓
在硬件版本位置 3 秒内连续点击 10 次
    ↓
工程菜单 ProjectMenuActivity
    ↓
升级菜单 UpgradeMainActivity
    ↓
选择“M3程序升级”
    ↓
ZhongQiM3UpdateActivity
    ↓
用户确认
    ↓
IM0ManagerService.sendUpdateRequest(type, flashType)
    ↓
ImplM0ManagerService
    ↓
MonitorM0Update.sendUpdateRequest()
```

升级通过 Binder 发起。广播只用于 MCU 返回最终结果后通知页面。

### 3.2 介质和文件

| 介质 | `flashType` | 文件路径 |
|---|---:|---|
| U 盘 | `0` | `/mnt/usb_storage/update_mcu.zip` |
| TF 卡 | `1` | `/mnt/external_sd0/update_mcu.zip` |

当前正常 UI 没有传入 `FLASHTYPE=1`，所以实际默认走 U 盘。

代码保留 TF 卡分支，但页面状态检测历史上使用 `/mnt/external_sd`，通讯服务读取 `/mnt/external_sd0`，两边路径不一致。

`update_mcu.zip` 只在介质根目录查找，不递归搜索子目录。

### 3.3 包结构

```text
update_mcu.zip
    ├── cortex-gdm4.bin
    ├── cortex-m3.bin
    └── ValidationFile.ini
```

根据设备类型，实际刷写文件是 `cortex-gdm4.bin` 或 `cortex-m3.bin`。

### 3.4 解压和验签

```text
开始 sendUpdateRequest()
    ↓
删除 /sdcard/zhongqi_mcu_update/
    ↓
解压 update_mcu.zip 到该目录
    ↓
根据 MCU 版本选择实际目标固件
    ↓
计算 SHA-256
    ↓
读取 ValidationFile.ini 中的 sign
    ↓
使用硬编码 RSA-2048 公钥和 SHA256withRSA 验签
    ├── 失败：返回 -2
    └── 成功：选择实际固件并进入协议传输
```

当前算法先计算文件 SHA-256，再把摘要传给 `SHA256withRSA`，实际相当于：

```text
RSA-Sign(SHA256(SHA256(payload)))
```

制包工具必须使用相同的双重摘要方式。

### 3.5 固件选择

页面选择升级类型：

| MCU 版本 | 升级类型 |
|---|---:|
| `110px02m3`、`110rv01m3` | `0x01` |
| `ae6501` | `0x0F` |
| 其他版本 | `0x1F` |

通讯服务选择实际文件：

| MCU 版本 | 实际传输文件 |
|---|---|
| `110px02m3`、`110rv01m3` | `cortex-m3.bin` |
| 其他情况 | `cortex-gdm4.bin` |

当前工作区已改为使用同一个目标文件名完成验签和传输：M3 设备验签并传输 `cortex-m3.bin`，其他设备验签并传输 `cortex-gdm4.bin`。页面按 `-` 分割版本字符串后判断，通讯服务直接比较原始版本字符串，这个差异仍需后续统一。

### 3.6 MCU 协议

| 消息号 | 名称 | 作用 |
|---:|---|---|
| `0xE1` | `MSG_REQUEST_UPDATE` | MCU 主动请求升级 |
| `0xE2` | `MSG_SEND_UPDATE_REQUEST` | 主机发送固件总长度 |
| `0xE3` | `MSG_REQUEST_UPDATE_DATA` | MCU 按偏移请求固件数据 |
| `0xE4` | `MSG_RECV_UPDATE_RESULT` | MCU 返回最终结果 |

主时序：

```text
Android 完成解压和验签
    ↓
E2：主机发送固件总长度
    ↓
MCU 返回状态和最大分包长度
    ↓
E3：MCU 发送 offset(4B) + length(2B)
    ↓
主机按偏移读取并返回固件数据
    ↓
重复 E3 直到传输完成
    ↓
MCU 校验并执行升级
    ↓
E4：MCU 返回最终结果
    ↓
主机回复 ACK
    ↓
通讯服务发送 ACTION_M0_UPDATE_FILE 广播
    ↓
升级页面显示结果
```

收到 MCU 主动 E1 后，当前代码会再次删除临时目录、解压、验签并发送 E2，可能与已经开始的 Binder 升级会话冲突。

### 3.7 状态码

E2 阶段：

| 返回值 | 含义 |
|---:|---|
| `-2` | ZIP 不存在、验签失败或目标固件不可读 |
| `-1` | 发送失败或等待响应超时 |
| `0` | MCU 不支持升级 |
| `1` | MCU 已准备好，开始传输 |
| `2` | 固件长度超限 |

E4 最终结果：

| 返回值 | 含义 |
|---:|---|
| `1` | 升级成功 |
| `2` | 固件校验和错误 |
| `3` | 版本错误或固件非法 |
| `4` | 文件或数据获取失败 |

E2 成功响应当前没有检查至少包含 3 字节，截断响应可能导致数组越界。

### 3.8 MCU 新旧兼容

历史裸固件路径：

```text
<介质根目录>/m3/cortex-m3.bin
<介质根目录>/m3/cortex-gdm4.bin
```

当前工作区已恢复历史裸固件路径。

| 输入 | 当前行为 |
|---|---|
| 合法 `update_mcu.zip` | 解压、验签、传输 |
| 非法 `update_mcu.zip` | 返回失败，不回退裸 bin |
| ZIP 不存在，存在 `m3/cortex-m3.bin` | M3 设备使用旧版文件 |
| ZIP 不存在，存在 `m3/cortex-gdm4.bin` | GDM4 设备使用旧版文件 |
| ZIP 与裸 bin 同时存在 | 只处理 ZIP |

PX3 当前分支不包含 RK3568 的 `446193a73` 新旧包兼容提交。

---

## 4. 当前待完善点

### MPU

1. 将未跟踪的 `ZQ_TH7_RKUpdateService` 纳入正式源码和构建基线。
2. 从业务扫描流程中移除 Rockchip 遗留 `update.zip` 分支。
3. 明确恢复裸 `update.img` 时对 `persist.sys.update.show` 的处理方式。
4. 验签失败后立即结束，不得回退裸 `update.img`。
5. 使用安全解压和私有暂存目录，保证验签文件与安装文件一致。
6. 补齐取消、异常、Recovery 结果和升级包清理流程。

### MCU

1. 统一页面和通讯服务的 MCU 版本解析。
2. 增加升级会话互斥，避免 E1 重复初始化。
3. 修复 ZIP 路径校验、共享目录替换和文件流关闭问题。
4. 明确裸 bin 兼容允许使用的工程授权场景。

---

## 5. 关键代码

### MPU

| 文件 | 行号 | 说明 |
|---|---:|---|
| `ZQ_TH7_RKUpdateService/src/android/rockchip/update/service/RKUpdateReceiver.java` | 53 | 本地升级触发 |
| `ZQ_TH7_RKUpdateService/src/android/rockchip/update/service/RKUpdateService.java` | 328 | MPU 本地升级主流程 |
| 同上 | 498 | 文件扫描和优先级 |
| `ZQ_TH7_RKUpdateService/src/android/rockchip/update/service/ZipFileVerifier.java` | 86 | MPU 解压和验签 |
| `ZQ_TH7_RKUpdateService/src/android/rockchip/update/service/UpdateAndRebootActivity.java` | 159 | 选择 RK image 或 OTA 模式 |
| `ZQ_TH7_RKUpdateService/src/android/rockchip/update/service/RecoverySystem.java` | 354 | 安装 `update.img` |

### MCU

| 文件 | 行号 | 说明 |
|---|---:|---|
| `YX_MainInterface_ZhongQi/src/main/java/com/yaxon/base/system/UpgradeMainActivity.java` | 111 | MCU 升级入口 |
| `YX_MainInterface_ZhongQi/src/main/java/com/yaxon/base/system/ZhongQiM3UpdateActivity.java` | 321 | 发起 Binder 调用 |
| `YX_CommunicatePro_ZhongQi/src/main/java/com/yaxon/telematics/service/ImplM0ManagerService.java` | 30 | AIDL 转发 |
| `YX_CommunicatePro_ZhongQi/src/main/java/com/yaxon/telematics/service/protocol/monitor/m0/MonitorM0Update.java` | 75 | E1～E4 协议处理 |
| 同上 | 203 | 查包、验签和 E2 请求 |
| 同上 | 264 | 实际固件选择 |
| `YX_CommunicatePro_ZhongQi/src/main/java/com/yaxon/utils/ZipFileVerifier.java` | 80 | MCU 解压和验签 |

## 6. 代码状态说明

- MPU 升级目录 `ZQ_TH7_RKUpdateService` 当前未纳入 Git。
- 当前源码实际扫描三种文件；业务目标只保留 `update_mpu.zip` 和 `update.img`。
- MCU 签名升级由 `aeb1d9c9e`、`897dc0607` 两笔提交引入。
- 2026-08-19 当前工作区恢复 `m3/cortex-m3.bin`、`m3/cortex-gdm4.bin` 旧版兼容，并改为验签实际传输的 ZIP 内固件。
- 本文只描述 MPU 和 MCU 本地升级，不包含其他升级类型。



不签名： 新版本 - >旧版本