v10.52.0

v10.52.0

Crash-moment rescue + resumable downloads: crash-on-launch bricks are now recoverable

10.51 introduced the native cold-start check: a device bricked by a bad hot update pulls the fix on its next launch, natively, without JS. Live testing found its boundary — it rescued a version that crashed 10 seconds into the session, but not one that crashed ~230ms into every launch: the check needs a few seconds, the JS crash kills the whole process, and that round's download progress was thrown away every time. No number of restarts converged.

This release closes that gap with two mechanisms (design: NATIVE_CHECKUPDATE_DESIGN.md §11):

Crash-moment rescue (Android & iOS)

When the app dies of an uncaught JS error during startup, the process is still alive for a moment — and JS will never run again. The SDK now uses exactly that window: it briefly holds the dying process (hard-capped: ~10s on a background thread crash, ~3.5s on a main-thread crash) to finish the update check and download, then lets the crash proceed.

• Zero false positives, zero cost on the healthy path: the crash itself is the trigger. No crash-loop counters, no startup blocking, nothing runs unless the app is actually dying within 60s of launch (or with a check round in flight).
• The fix boots on the next launch, with no extra restart: it is committed at the end of the dying session. In the rescue window a downloaded fix is always activated — JS is no longer around to decide.
• Crash reporters keep working: the SDK chains the previously installed handler (the same etiquette Sentry/Crashlytics/Bugly follow) and always hands the crash over afterwards, whether the rescue ran, timed out, or failed. The hold runs on a worker thread with a hard timeout, so it can only delay the process death, never prevent it.
• Honest boundary: this catches exception-shaped crashes (the shape JS bricks take). Native signal crashes, ANRs and OOM kills are not covered. HarmonyOS does not get the hold in this release (its error observer cannot drive async network IO); it gets everything below.

Resumable downloads (all three platforms)

Update downloads now survive process death: partial files are kept with a sidecar recording what they belong to (URL, ETag/Last-Modified, total size) and resume via HTTP Range with If-Range validation — a changed server file falls back to a clean full transfer instead of appending mismatched bytes; a fully-received archive that never got unpacked is recognized and goes straight to unpacking. An archive that downloads fully but fails to unpack is classified as poisoned and dropped along with its sidecar, so a corrupt file can never trap the resume loop.

A launch that follows an interrupted round also skips the usual 5s startup delay and resumes immediately — repeated short-lived launches make monotonic progress instead of starting over.

Telemetry

A rescued version that survives to markSuccess reports a forceBootRescue / crashRescue receipt, so the dashboard can show which devices were actually pulled back.

Everything else is unchanged from 10.51.1. No API changes; no action needed beyond upgrading.

---

崩溃时刻救援 + 断点续传:「启动即崩」的砖现在也能救回来

10.51 引入了原生冷启动检测:被坏热更卡死的设备下次启动由原生侧拉回修复版,不依赖 JS。真机实测找到了它的边界——它救回了"启动 10 秒后才崩"的版本,却救不了"每次启动 230ms 即崩"的:检测需要数秒,JS 崩溃会杀掉整个进程,那一轮的下载进度全部作废,重启多少次都无法收敛。

本版用两个机制补上这个缺口(设计文档:NATIVE_CHECKUPDATE_DESIGN.md §11):

崩溃时刻救援(Android 与 iOS)

应用死于启动阶段的未捕获 JS 错误时,进程还有片刻存活——而 JS 已永远不会再跑。SDK 现在正是利用这个窗口:短暂扣住垂死的进程(硬上限:后台线程崩溃约 10s、主线程崩溃约 3.5s),把更新检查与下载做完,再放行崩溃流程。

• 零误判、健康路径零成本:崩溃本身就是触发信号。没有崩溃计数器、不阻塞启动,只有应用真的在启动 60 秒内死亡(或有在途检查轮)时才会介入。
• 修复版下次启动直接生效,无需额外重启:提交发生在垂死会话的末尾。救援窗口内下载到的修复版一律激活——JS 已经没有机会做决策了。
• 崩溃上报不受影响:SDK 以链式方式保存并在结束后调用原有的崩溃处理器(与 Sentry/Crashlytics/Bugly 相同的惯例),无论救援完成、超时还是失败。扣留跑在带硬超时的工作线程上,只可能推迟进程死亡,不可能阻止它。
• 诚实边界:覆盖 exception 形态的崩溃(JS 砖的典型形态);原生 signal 崩溃、ANR、OOM 击杀不在覆盖内。鸿蒙本版暂无扣留机制(其错误观察者无法驱动异步网络 IO),但以下能力全部具备。

断点续传(三端)

更新下载现在能在进程死亡后接着传:partial 文件连同 sidecar(记录所属 URL、ETag/Last-Modified、总长)一起保留,以 HTTP Range + If-Range 验证续传——服务端文件已变更时自动退回完整重传,绝不拼接不匹配的字节;已收齐但没来得及解压的归档会被识别并直接进入解压。下载完整但解压失败的归档判定为有毒,连 sidecar 一起删除,坏文件永远不会困住续传循环。

紧随中断轮次的下一次启动还会跳过常规的 5 秒延迟立即续传——反复的短命启动也能单调累积进度,而不是每次从零开始。

遥测

被救援送进来的版本活到 markSuccess 时会补报 forceBootRescue / crashRescue 回执,控制台由此可以看到哪些设备真的被捞回来了。

其余与 10.51.1 一致。无 API 变更,升级即可。