react-native-update 10.53.1 → 10.54.0

package/README-CN.md

@@ -19,7 +19,7 @@
 ### 优势
 
 1. 对中国用户使用阿里云高速 CDN 分发，对比其他服务器在国外的热更新服务，分发更稳定，更新成功率极高。海外用户智能分流至 cloudflare，同样提供稳定高速的分发体验。
-2. 基于 bsdiff/hdiff 算法创建的**超小更新包**，通常版本迭代后在几十至几百 KB 级别（其他全量热更新服务所需流量通常在几十 MB 级别）。更针对 **Hermes 字节码专门优化了 diff 算法**（详见下方[算法对比](#diff-算法对比)），补丁体积进一步显著缩小。
+2. 基于 bsdiff/hdiff 算法创建的**超小更新包**，通常版本迭代后在几十至几百 KB 级别（其他全量热更新服务所需流量通常在几十 MB 级别）。整条链路更是**针对 Hermes 字节码做了专门优化**——单行改动只需下发 **3.4 KB**（详见下方[算法对比](#diff-算法对比)）；最新的优化都发生在构建期，**已上架的应用只需重新构建一次发版即可受益**。
 3. 始终跟进 RN 最新正式版本，第一时间提供支持。支持 hermes 字节码格式。支持新架构（注：安卓 0.73.0 ~ 0.76.0 的新架构因官方 bug 不支持，0.73 以下或 0.76.1 以上的新架构可用）。
 4. 跨越多个版本进行更新时，只需要下载**一个更新包**，不需要逐版本依次更新。
 5. 命令行工具 & 网页双端管理，版本发布过程简单便捷，完全可以集成 CI。
@@ -30,49 +30,49 @@
 10. **原生冷启动自愈**：即使热更版本坏到 JS 完全跑不起来（白屏、启动即崩），设备也能在下次启动时由原生侧自动拉到修复版——不需要用户重装，也不需要你发新的应用商店版本（详见下方[原生冷启动检测](#原生冷启动检测)）。
 11. 提供付费的专人技术支持。
 
-### 原生冷启动检测
-
-自 10.52.1 起，每次冷启动后数秒会在后台线程执行一次**不依赖 app bundle** 的更新检查（下载、打补丁与状态切换全部在原生侧完成）。它的存在只为一件事：**当前热更版本坏到 JS 起不来时，仍有一条能把修复版拉下来的通路**——常规更新流程仍由应用内的 JS 负责，检查结果会被 JS 侧复用，不会重复请求。
-
-几个需要知道的点：
+### Diff 算法对比
 
-- **不阻塞启动**：延迟数秒、跑在后台线程，成果在**下次启动**生效。
-- **是否自动激活取决于你的配置**：`updateStrategy` 为 `silentAndNow` / `silentAndLater` 且未关闭自动检查（`checkStrategy` 不为 `null`）时，原生侧才会把下载好的版本设为下次启动生效；其余情况只下载，激活权仍在 JS。
-- **救砖指令**：控制台可按版本标记「强制启动」，被标记的版本无视上述策略直接在下次启动生效——这是把已被坏版本卡死的设备捞回来的手段。设备本地的崩溃回滚保护仍然优先，已回滚过的版本不会被再装回去。
-- **崩溃时刻救援**（Android 与 iOS）：应用在启动阶段死于未捕获的 JS 错误时，SDK 会短暂扣住垂死的进程（数秒、有硬上限），把检查与下载做完——即使版本每次启动零点几秒就崩，也能被换掉。该窗口内下载到的修复版一律设为下次启动生效（JS 已经没有机会做决策了）。崩溃上报不受影响：SDK 以链式方式保存并在结束后调用原有的崩溃处理器。不覆盖：原生（非 JS）崩溃、ANR、OOM 击杀，以及 iOS 上安装了自定义 `RCTSetFatalHandler` 的应用（那时 React Native 不再抛出本机制拦截的异常）。
-- **断点续传**：更新下载在进程死亡后保留进度、下次以 HTTP Range 续传，反复的短命启动也能单调累积进度；紧随中断轮次的下一次启动会跳过延迟立即续传。鸿蒙不需要崩溃时刻扣留：RNOH 下未捕获的 JS 错误不会杀死进程，JS 启动即崩时原生检测照常完成。
-- **可以关闭**：`disableNativeCheck: true`。关闭后每次冷启动少一次后台请求，代价是**放弃上述自愈能力**——被坏热更卡死的设备将无法自动恢复。仅在这次请求本身构成问题时（流量/耗电预算、隐私清单申报、需用户同意后才可联网）才建议关闭。
+Hermes 字节码对通用二进制 diff 极不友好，我们在两个环节同时下手，且收益叠加：
 
-### Diff 算法对比
+- **delta 模式编译**。Hermes **每次**编译都会重排字符串表，JS 改一行就会让大部分字符串 ID 重新编号，两份几乎相同的字节码于是处处不同。`bundle` 会以同一应用更早的一份字节码为基准编译（`hermesc -base-bytecode=…`），把这些 ID 钉死在原位，只有真正的改动才会进入 diff。
+- **HBC 感知的可逆变换**。Hermes 字节码中还有大量"偏移量表"，中间插入几个字节就会令其后所有偏移整体位移。我们在 hdiff 之前引入一层 **delta-friendly 可逆变换**，对偏移位域做前项差分，把整体位移退化为单点变化。布局描述表随补丁下发，Hermes 版本演进时**客户端零升级**。
 
-传统 diff 算法直接对字节做差分，而 Hermes 字节码中大量结构是"偏移量表"——JS 一处小改动会令其后所有偏移量整体位移，导致二进制差异被急剧放大。我们在 hdiff 之前引入了一层**针对 HBC（Hermes 字节码）的 delta-friendly 可逆变换**：对偏移位域做前项差分，从根源上消除这种位移放大。布局描述表由发布端随补丁下发，Hermes 版本演进时**客户端零升级**、自动兼容。
+此外字节码在产出时就不含 debug info 段（实测小 **21%**，与 React Native 自身 release 构建一致），全量包和由它派生的每一个补丁都随之变小。
 
-以下数据在真实 RN 0.86 应用的 release 产物上实测（Hermes HBC v98，字节码约 4.4 MB），每个补丁都先通过完整往返校验再记录体积。完整的评测方法、测试数据与可复现代码见 **[hbc-diff-benchmark](https://github.com/sunnylqm/hbc-diff-benchmark)**。
+以下数据在真实 RN 0.86 应用的 release 产物上实测（Hermes HBC v98，字节码约 4.4 MB）。每个补丁都先通过完整往返校验再记录体积，每个 delta 模式产物都通过与普通编译的等价性校验。完整的评测方法、测试数据与可复现代码见 **[hbc-diff-benchmark](https://github.com/sunnylqm/hbc-diff-benchmark)**。
 
 **Hermes 字节码（.hbc）——生产环境 Hermes 应用的实际发包格式：**
 
-| 迭代场景 | 全量 OTA（gzip） | bsdiff | bsdiff+lzma | hdiff | hdiff + HBC 变换 |
-|---|---|---|---|---|---|
-| 单行文案修改 | 1901.5 KB | 93.7 KB | 87.7 KB | 89.0 KB | **63.5 KB**（−28% / −29%） |
-| 小功能（约 60 行） | 1913.9 KB | 411.6 KB | 330.9 KB | 328.0 KB | **285.5 KB**（−14% / −13%） |
-| 中等功能（约 300 行） | 1973.7 KB | 551.6 KB | 430.6 KB | 431.6 KB | **398.4 KB**（−7% / −8%） |
+| 迭代场景 | 全量 OTA（gzip） | bsdiff | **react-native-update** | 对比 bsdiff |
+|---|---|---|---|---|
+| 单行文案修改 | 1901.5 KB | 93.7 KB | **3.4 KB** | **小 28 倍** |
+| 小功能（约 60 行） | 1913.9 KB | 411.6 KB | **50.2 KB** | **小 8.2 倍** |
+| 中等功能（约 300 行） | 1973.7 KB | 551.6 KB | **97.8 KB** | **小 5.6 倍** |
 
 **文本 JS bundle——非 Hermes 应用（同一应用、同样三个场景）：**
 
-| 迭代场景 | 全量 OTA（gzip） | bsdiff | bsdiff+lzma | hdiff |
-|---|---|---|---|---|
-| 单行文案修改 | 807.2 KB | 0.3 KB | 0.7 KB | **0.1 KB** |
-| 小功能（约 60 行） | 813.1 KB | 7.4 KB | 7.4 KB | **5.8 KB** |
-| 中等功能（约 300 行） | 837.7 KB | 38.4 KB | 37.4 KB | **28.7 KB** |
+| 迭代场景 | 全量 OTA（gzip） | bsdiff | **react-native-update** |
+|---|---|---|---|
+| 单行文案修改 | 807.2 KB | 0.3 KB | **0.1 KB** |
+| 小功能（约 60 行） | 813.1 KB | 7.4 KB | **5.8 KB** |
+| 中等功能（约 300 行） | 837.7 KB | 38.4 KB | **28.7 KB** |
 
-文本 bundle 没有偏移量表，diff 天然干净——补丁只有几百字节到几十 KB，较大改动下 hdiff 仍比 bsdiff 小约 20%~25%。偏移位移放大是 Hermes 字节码特有的问题，这正是 HBC 变换存在的意义。
+文本 bundle 既没有偏移量表也没有字符串表重排，diff 天然干净——补丁只有几百字节到几十 KB。上述两项优化所消除的放大效应是 Hermes 字节码特有的问题，这正是它们存在的意义。
 
 要点：
 
-- 增量更新比全量 OTA 节省 **5~30 倍**流量（单行改动 63.5 KB vs 全量 1.9 MB）。
-- bsdiff+lzma 对照组（同一份 bsdiff 差分数据、换用 lzma 压缩）表明压缩器占了 bsdiff 与 hdiff 差距的大头——而 HBC 针对性变换再带来的 **7%~29%** 缩减是**纯算法收益**，且越是高频的小改动收益越大。
-- hdiff 生成补丁比 bsdiff 快 **2~4 倍**，变换本身开销仅个位数毫秒。
-- 安全兜底：改写任何字节前先对段边界、位域范围做全量校验，不匹配时自动回退到普通 hdiff 路径。
+- 单行修复——也是最常见的热更类型——只需下发 **3.4 KB**，比全量 OTA 少 559 倍。
+- 生成补丁比 bsdiff 快 **2~4 倍**，变换本身开销仅个位数毫秒。
+- 每一环都有安全兜底：改写任何字节前先做全量校验，delta 模式产物要与普通编译结果比对，任一环节不匹配都自动回退到原有行为。
+
+### 原生冷启动检测
+
+自 10.52.1 起，每次冷启动后数秒会在后台线程执行一次**不依赖 app bundle** 的更新检查（下载、打补丁与状态切换全部在原生侧完成）。它的存在只为一件事：**当前热更版本坏到 JS 起不来时，仍有一条能把修复版拉下来的通路**——常规更新流程仍由应用内的 JS 负责，检查结果会被 JS 侧复用，不会重复请求。
+
+- **不阻塞启动**：延迟数秒、跑在后台线程，成果在**下次启动**生效。下载到的版本是否自动激活取决于你的 `updateStrategy` / `checkStrategy`；否则只下载，激活权仍在 JS。
+- **崩溃时刻救援**（Android 与 iOS）：应用在启动阶段死于未捕获的 JS 错误时，SDK 会短暂扣住垂死的进程把检查与下载做完——即使版本每次启动零点几秒就崩，也能被换掉。崩溃上报不受影响：SDK 以链式方式保存并在结束后调用原有的崩溃处理器。不覆盖：原生崩溃、ANR、OOM 击杀，以及 iOS 上安装了自定义 `RCTSetFatalHandler` 的应用。
+- **救砖指令**：控制台可按版本标记「强制启动」，被标记的版本无视上述策略直接在下次启动生效——这是把已被坏版本卡死的设备捞回来的手段。设备本地的崩溃回滚保护仍然优先，已回滚过的版本不会被再装回去。
+- **可以关闭**：`disableNativeCheck: true`。关闭后每次冷启动少一次后台请求，代价是**放弃上述自愈能力**——被坏热更卡死的设备将无法自动恢复。
 
 ### 与其他热更新库对比
 
@@ -92,7 +92,7 @@
 | **灰度发布** | ✅ 后台自带，按比例逐步放量 | ✅ 支持 | ❌ **已停运** |
 | **数据统计** | ✅ 后台自带（版本分布、更新成功率等） | ⚠️ 有限 | ❌ **已停运** |
 | **健康度监控** | ✅ 后台自带版本健康度监控 | ❌ 不支持 | ❌ **已停运** |
-| **Hermes 专项 diff 优化** | ✅ HBC 结构感知，补丁更小 | ❌ 全量更新 | ❌ **已停运** |
+| **Hermes 专项 diff 优化** | ✅ delta 模式编译 + HBC 结构感知变换，补丁更小 | ❌ 全量更新 | ❌ **已停运** |
 | **管理界面** | ✅ 命令行工具 + Web 管理界面 | ✅ Expo Dashboard | ❌ **已停运** |
 | **CI/CD 集成** | ✅ 支持 | ✅ 支持 | ❌ **已停运** |
 | **API 扩展性** | ✅ Meta 信息 + 开放 API | ⚠️ 有限 | ❌ **已停运** |

package/README.md

@@ -17,7 +17,7 @@ See the docs:
 ## Advantages
 
 1. react-native-update provides a dedicated global service with fast and reliable worldwide delivery.
-2. **Tiny update packages** generated with bsdiff/hdiff are typically only tens to hundreds of KB, instead of the tens of MB usually required by full-bundle update systems. On top of that, the diff algorithm is **specifically optimized for Hermes bytecode** (see the [comparison below](#diff-algorithm-comparison)), shrinking patches even further.
+2. **Tiny update packages** generated with bsdiff/hdiff are typically only tens to hundreds of KB, instead of the tens of MB usually required by full-bundle update systems. The whole pipeline is **specifically optimized for Hermes bytecode** — a one-line change ships in **3.4 KB** (see the [comparison below](#diff-algorithm-comparison)), and because the newest optimizations happen at build time, **apps already in the store benefit from nothing more than a rebuild**.
 3. The library tracks new React Native stable releases closely, supports Hermes bytecode, and supports the new architecture. Note: Android RN 0.73.0 to 0.76.0 new architecture is unavailable because of upstream issues; versions below 0.73 or above 0.76.1 are supported.
 4. When updating across multiple versions, clients only need to download **one update package** instead of applying every intermediate version in sequence.
 5. Command-line tools and a web dashboard are both available, making release workflows simple and CI-friendly.
@@ -28,49 +28,49 @@ See the docs:
 10. **Native cold-start recovery**: even when an update is broken badly enough that JS never runs (white screen, crash on launch), the device pulls the fixed version on its next launch from the native side — no reinstall, no app-store release (see [Native cold-start check](#native-cold-start-check)).
 11. Paid technical support is available.
 
-## Native cold-start check
-
-Since 10.52.1 every cold start runs one background update check a few seconds after launch that **does not depend on the app bundle** — the request, the download, the patch and the version switch all happen natively. It exists for exactly one reason: **when the running update is broken enough that JS never starts, something still has to be able to fetch the fix.** Normal updates remain the JS flow's job; the JS check reuses this result instead of issuing its own request.
-
-What to know:
+## Diff Algorithm Comparison
 
-- **It never blocks startup**: it is delayed by a few seconds, runs off the main thread, and its result takes effect on the *next* launch.
-- **Whether it activates depends on your configuration**: only with `updateStrategy` set to `silentAndNow` / `silentAndLater` *and* automatic checks left on (`checkStrategy` not `null`) will the native side mark a downloaded version for the next launch. Otherwise it downloads and leaves activation to JS.
-- **Rescue directive**: the dashboard can mark a version "force boot", which activates on the next launch regardless of the strategies above — this is how a fleet stuck on a broken version is recovered. The device-local crash-rollback guard still wins: a version this device already rolled back from is never reinstalled.
-- **Crash-moment rescue** (Android & iOS): when the app dies of an uncaught JS error during startup, the SDK briefly holds the dying process (a few seconds, bounded) to finish the check and download — so even a version that crashes a fraction of a second into every launch gets replaced. In that window the downloaded fix is always activated for the next launch, since JS is no longer around to decide. Crash reporters keep working: the SDK chains the previous crash handler and always hands the crash over afterwards. Not covered: native (non-JS) crashes, ANRs, OOM kills, and — on iOS — apps that install a custom `RCTSetFatalHandler` (React Native then no longer raises the exception this rescue intercepts).
-- **Resumable downloads**: update downloads survive process death and resume from where they stopped (HTTP Range), so repeated short-lived launches still make monotonic progress; a launch that follows an interrupted round skips the startup delay and resumes immediately. HarmonyOS does not need the crash-moment hold: an uncaught JS error does not kill the process there, so the native check completes normally even when JS dies on launch.
-- **It can be turned off**: `disableNativeCheck: true` removes one background request per cold start, at the cost of **giving up the recovery above** — a device bricked by a bad update can no longer heal itself. Choose it only when that request is itself the problem (traffic/battery budgets, privacy manifests, consent-gated networking).
+Hermes bytecode is hostile to generic binary diffing, and we attack that at two points that stack:
 
-## Diff Algorithm Comparison
+- **Delta-mode compilation.** Hermes re-sorts its string table on **every** compile, so a one-line JS edit renumbers most string IDs and two nearly identical bytecode files end up differing almost everywhere. `bundle` compiles against an earlier bytecode of the same app (`hermesc -base-bytecode=…`), pinning those IDs so that only real changes ever reach the diff.
+- **An HBC-aware transform.** Hermes bytecode is also full of offset tables, where inserting a few bytes shifts every subsequent offset. Before running hdiff we apply a **delta-friendly reversible transform** that delta-encodes those offset bitfields, so a global shift collapses into a single-point change. The layout description ships with each patch, so **clients need zero upgrades** as Hermes evolves.
 
-Traditional diff algorithms operate on raw bytes. Hermes bytecode, however, is full of offset tables — a small JS change shifts every subsequent offset, which dramatically amplifies the binary difference. Before running hdiff, we apply a **delta-friendly reversible transform tailored to HBC (Hermes bytecode)**: offset bitfields are delta-encoded so the offset-shift amplification disappears at the source. The layout description table is shipped with each patch, so when Hermes evolves, **clients need zero upgrades** — compatibility is automatic.
+The bytecode is also emitted without its debug-info section — a flat **21%** smaller, the same thing React Native's own release builds do — which shrinks the full package and every patch derived from it.
 
-The numbers below are measured on real release bundles of a React Native 0.86 app (Hermes HBC v98, ~4.4 MB bytecode); every patch is verified by an actual round-trip before its size is recorded. Full methodology, fixtures, and runnable code: **[hbc-diff-benchmark](https://github.com/sunnylqm/hbc-diff-benchmark)**.
+The numbers below are measured on real release bundles of a React Native 0.86 app (Hermes HBC v98, ~4.4 MB bytecode). Every patch is verified by an actual round-trip before its size is recorded, and every delta-mode build is verified equivalent to a plain compile. Full methodology, fixtures, and runnable code: **[hbc-diff-benchmark](https://github.com/sunnylqm/hbc-diff-benchmark)**.
 
 **Hermes bytecode (.hbc) — what ships in production Hermes apps:**
 
-| Scenario | Full OTA (gzip) | bsdiff | bsdiff+lzma | hdiff | hdiff + HBC transform |
-|---|---|---|---|---|---|
-| One-line text change | 1901.5 KB | 93.7 KB | 87.7 KB | 89.0 KB | **63.5 KB** (−28% / −29%) |
-| Small feature (~60 LOC) | 1913.9 KB | 411.6 KB | 330.9 KB | 328.0 KB | **285.5 KB** (−14% / −13%) |
-| Medium feature (~300 LOC) | 1973.7 KB | 551.6 KB | 430.6 KB | 431.6 KB | **398.4 KB** (−7% / −8%) |
+| Scenario | Full OTA (gzip) | bsdiff | **react-native-update** | vs bsdiff |
+|---|---|---|---|---|
+| One-line text change | 1901.5 KB | 93.7 KB | **3.4 KB** | **28× smaller** |
+| Small feature (~60 LOC) | 1913.9 KB | 411.6 KB | **50.2 KB** | **8.2× smaller** |
+| Medium feature (~300 LOC) | 1973.7 KB | 551.6 KB | **97.8 KB** | **5.6× smaller** |
 
 **Plain-text JS bundle — non-Hermes apps (same scenarios, same app):**
 
-| Scenario | Full OTA (gzip) | bsdiff | bsdiff+lzma | hdiff |
-|---|---|---|---|---|
-| One-line text change | 807.2 KB | 0.3 KB | 0.7 KB | **0.1 KB** |
-| Small feature (~60 LOC) | 813.1 KB | 7.4 KB | 7.4 KB | **5.8 KB** |
-| Medium feature (~300 LOC) | 837.7 KB | 38.4 KB | 37.4 KB | **28.7 KB** |
+| Scenario | Full OTA (gzip) | bsdiff | **react-native-update** |
+|---|---|---|---|
+| One-line text change | 807.2 KB | 0.3 KB | **0.1 KB** |
+| Small feature (~60 LOC) | 813.1 KB | 7.4 KB | **5.8 KB** |
+| Medium feature (~300 LOC) | 837.7 KB | 38.4 KB | **28.7 KB** |
 
-Text bundles have no offset tables, so they diff cleanly without any transform — patches are hundreds of bytes to tens of KB, and hdiff still beats bsdiff by ~20–25% on the larger changes. The offset-shift amplification is a Hermes-bytecode-specific problem, which is exactly why the HBC transform exists.
+Text bundles have no offset tables and no string-table churn, so they diff cleanly on their own — patches are hundreds of bytes to tens of KB. The amplification the two optimizations above remove is a Hermes-bytecode-specific problem, which is exactly why they exist.
 
 Highlights:
 
-- Incremental updates save **5–30×** bandwidth compared to full-bundle OTA (63.5 KB vs 1.9 MB for a one-line change).
-- The bsdiff+lzma control group (same bsdiff delta, lzma compression) shows the compressor accounts for most of the bsdiff-vs-hdiff gap — the further **7–29%** cut from the HBC-aware transform is **pure algorithmic gain**, largest on the small, frequent updates that dominate real OTA traffic.
-- Patch generation with hdiff is **2–4× faster** than bsdiff; the transform itself costs single-digit milliseconds.
-- Safety first: section bounds and bitfield ranges are fully validated before any byte is touched, and the pipeline automatically falls back to plain hdiff on any mismatch.
+- A one-line fix — by far the most common hot update — ships in **3.4 KB**, 559× less than a full-bundle OTA.
+- Patch generation is **2–4× faster** than bsdiff; the transform itself costs single-digit milliseconds.
+- Every stage fails safe: bounds are validated before any byte is touched, delta-mode output is checked against a plain compile, and any mismatch falls back to the previous behaviour.
+
+## Native cold-start check
+
+Since 10.52.1 every cold start runs one background update check that **does not depend on the app bundle** — the request, the download, the patch and the version switch all happen natively. It exists for exactly one reason: **when the running update is broken enough that JS never starts, something still has to be able to fetch the fix.** Normal updates remain the JS flow's job, and the JS check reuses this result instead of issuing its own request.
+
+- **It never blocks startup**: delayed by a few seconds, off the main thread, effective on the *next* launch. Whether the downloaded version is activated automatically depends on your `updateStrategy` / `checkStrategy`; otherwise it is downloaded and JS decides.
+- **Crash-moment rescue** (Android & iOS): if the app dies of an uncaught JS error during startup, the SDK briefly holds the dying process to finish the check and download — so even a version that crashes a fraction of a second into every launch gets replaced. Crash reporters keep working: the previous handler is chained and always called afterwards. Not covered: native crashes, ANRs, OOM kills, and iOS apps that install a custom `RCTSetFatalHandler`.
+- **Rescue directive**: marking a version "force boot" in the dashboard activates it on the next launch regardless of the strategies above — this is how a fleet stuck on a broken version is recovered. The device-local crash-rollback guard still wins: a version this device already rolled back from is never reinstalled.
+- **It can be turned off**: `disableNativeCheck: true` removes one background request per cold start, at the cost of **giving up the recovery above** — a device bricked by a bad update can no longer heal itself.
 
 ## Comparison With Other OTA Libraries
 
@@ -78,7 +78,7 @@ Highlights:
 |---------|---------------------|-------------|------------------------|
 | **Price / Cost** | Free tier with multiple paid plans, bandwidth included | Free tier with multiple paid plans, extra bandwidth charges apply | ❌ **Discontinued** (Microsoft App Center shut down on March 31, 2025) |
 | **Package Size** | ⭐⭐⭐⭐⭐ Tens to hundreds of KB (incremental) | ⭐⭐⭐ Full bundle updates (usually tens of MB) | ❌ **Discontinued** |
-| **Hermes-specific diff** | ✅ HBC-aware transform, smallest patches | ❌ Full bundle | ❌ **Discontinued** |
+| **Hermes-specific diff** | ✅ Delta-mode compile + HBC-aware transform, smallest patches | ❌ Full bundle | ❌ **Discontinued** |
 | **Staged (gray) rollout** | ✅ Built-in, percentage-based | ✅ Supported | ❌ **Discontinued** |
 | **Analytics** | ✅ Built-in (version distribution, success rate) | ⚠️ Limited | ❌ **Discontinued** |
 | **Release health monitoring** | ✅ Built-in | ❌ Not available | ❌ **Discontinued** |

package/android/jni/HDiffPatch/.travis.yml

@@ -0,0 +1,33 @@
+language: cpp
+matrix:
+  include:
+    - os: linux
+      compiler: clang
+    - os: linux
+      compiler: gcc
+    - os: linux
+      compiler: arm-linux-gnueabi-gcc
+      addons:
+        apt:
+          packages:
+            - qemu
+            - gcc-arm-linux-gnueabi
+            - libc-dev-armel-cross
+      env: CHOST=arm-linux-gnueabi
+    - os: osx
+      osx_image: xcode9.4
+script:
+- make LZMA=0
+- make clean
+- git clone https://github.com/sisong/lzma.git ../lzma
+- make DIR_DIFF=0
+- make clean
+- make
+- make clean
+- cd ../HDiffPatch
+- git clone https://github.com/sisong/libmd5.git ../libmd5
+- make MT=1 MD5=1
+- if [[ $TRAVIS_OS_NAME == osx ]]; then xcodebuild -workspace builds/xcode/HDiffPatch.xcworkspace -scheme hdiffz -configuration Release OBJROOT=$PWD/bin SYMROOT=$PWD/bin; fi
+- if [[ $TRAVIS_OS_NAME == osx ]]; then xcodebuild -workspace builds/xcode/HDiffPatch.xcworkspace -scheme hpatchz -configuration Release OBJROOT=$PWD/bin SYMROOT=$PWD/bin; fi
+- if [[ $TRAVIS_OS_NAME == osx ]]; then xcodebuild -workspace builds/xcode/HDiffPatch.xcworkspace -scheme unitTest -configuration Release OBJROOT=$PWD/bin SYMROOT=$PWD/bin; fi
+

package/android/jni/HDiffPatch/builds/xcode/bestParams.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:bestParams.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/hdiffz.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:HDiffZ.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/hdiffz.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+	<key>IDEDidComputeMac32BitWarning</key>
+	<true/>
+</dict>
+</plist>

package/android/jni/HDiffPatch/builds/xcode/hpatchz.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:HPatch.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/lz4.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:lz4.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/lzma.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:lzma.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/testHashClash.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:testHashConflict.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/testHashClash.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+	<key>IDEDidComputeMac32BitWarning</key>
+	<true/>
+</dict>
+</plist>

package/android/jni/HDiffPatch/builds/xcode/unitTest.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:unitTest.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/HDiffPatch/builds/xcode/zstd.xcodeproj/project.xcworkspace/contents.xcworkspacedata

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<Workspace
+   version = "1.0">
+   <FileRef
+      location = "self:zstd.xcodeproj">
+   </FileRef>
+</Workspace>

package/android/jni/lzma/DOC/7zC.txt

@@ -0,0 +1,187 @@
+7z ANSI-C Decoder 9.35
+----------------------
+
+7z ANSI-C provides 7z/LZMA decoding.
+7z ANSI-C version is simplified version ported from C++ code.
+
+LZMA is default and general compression method of 7z format
+in 7-Zip compression program (www.7-zip.org). LZMA provides high 
+compression ratio and very fast decompression.
+
+
+LICENSE
+-------
+
+7z ANSI-C Decoder is part of the LZMA SDK.
+LZMA SDK is written and placed in the public domain by Igor Pavlov.
+
+Files
+---------------------
+
+7zDecode.*   - Low level 7z decoding
+7zExtract.*  - High level 7z decoding
+7zHeader.*   - .7z format constants
+7zIn.*       - .7z archive opening
+7zItem.*     - .7z structures
+7zMain.c     - Test application
+
+
+How To Use
+----------
+
+You can create .7z archive with 7z.exe, 7za.exe or 7zr.exe:
+
+  7z.exe a archive.7z *.htm -r -mx -m0fb=255
+
+If you have big number of files in archive, and you need fast extracting, 
+you can use partly-solid archives:
+  
+  7za.exe a archive.7z *.htm -ms=512K -r -mx -m0fb=255 -m0d=512K
+
+In that example 7-Zip will use 512KB solid blocks. So it needs to decompress only 
+512KB for extracting one file from such archive.
+
+
+Limitations of current version of 7z ANSI-C Decoder
+---------------------------------------------------
+
+ - It reads only "FileName", "Size", "LastWriteTime" and "CRC" information for each file in archive.
+ - It supports only LZMA and Copy (no compression) methods with BCJ or BCJ2 filters.
+ - It converts original UTF-16 Unicode file names to UTF-8 Unicode file names.
+ 
+These limitations will be fixed in future versions.
+
+
+Using 7z ANSI-C Decoder Test application:
+-----------------------------------------
+
+Usage: 7zDec <command> <archive_name>
+
+<Command>:
+  e: Extract files from archive
+  l: List contents of archive
+  t: Test integrity of archive
+
+Example: 
+
+  7zDec l archive.7z
+
+lists contents of archive.7z
+
+  7zDec e archive.7z
+
+extracts files from archive.7z to current folder.
+
+
+How to use .7z Decoder
+----------------------
+
+Memory allocation
+~~~~~~~~~~~~~~~~~
+
+7z Decoder uses two memory pools:
+1) Temporary pool
+2) Main pool
+Such scheme can allow you to avoid fragmentation of allocated blocks.
+
+
+Steps for using 7z decoder
+--------------------------
+
+Use code at 7zMain.c as example.
+
+1) Declare variables:
+  inStream                 /* implements ILookInStream interface */
+  CSzArEx db;              /* 7z archive database structure */
+  ISzAlloc allocImp;       /* memory functions for main pool */
+  ISzAlloc allocTempImp;   /* memory functions for temporary pool */
+
+2) call CrcGenerateTable(); function to initialize CRC structures.
+
+3) call SzArEx_Init(&db); function to initialize db structures.
+
+4) call SzArEx_Open(&db, inStream, &allocMain, &allocTemp) to open archive
+
+This function opens archive "inStream" and reads headers to "db".
+All items in "db" will be allocated with "allocMain" functions.
+SzArEx_Open function allocates and frees temporary structures by "allocTemp" functions.
+
+5) List items or Extract items
+
+  Listing code:
+  ~~~~~~~~~~~~~
+
+    Use SzArEx_GetFileNameUtf16 function. Look example code in C\Util\7z\7zMain.c file. 
+    
+
+  Extracting code:
+  ~~~~~~~~~~~~~~~~
+
+  SZ_RESULT SzAr_Extract(
+    CArchiveDatabaseEx *db,
+    ILookInStream *inStream, 
+    UInt32 fileIndex,         /* index of file */
+    UInt32 *blockIndex,       /* index of solid block */
+    Byte **outBuffer,         /* pointer to pointer to output buffer (allocated with allocMain) */
+    size_t *outBufferSize,    /* buffer size for output buffer */
+    size_t *offset,           /* offset of stream for required file in *outBuffer */
+    size_t *outSizeProcessed, /* size of file in *outBuffer */
+    ISzAlloc *allocMain,
+    ISzAlloc *allocTemp);
+
+  If you need to decompress more than one file, you can send these values from previous call:
+    blockIndex, 
+    outBuffer, 
+    outBufferSize,
+  You can consider "outBuffer" as cache of solid block. If your archive is solid, 
+  it will increase decompression speed.
+
+  After decompressing you must free "outBuffer":
+  allocImp.Free(outBuffer);
+
+6) call SzArEx_Free(&db, allocImp.Free) to free allocated items in "db".
+
+
+
+
+Memory requirements for .7z decoding 
+------------------------------------
+
+Memory usage for Archive opening:
+  - Temporary pool:
+     - Memory for uncompressed .7z headers
+     - some other temporary blocks
+  - Main pool:
+     - Memory for database: 
+       Estimated size of one file structures in solid archive:
+         - Size (4 or 8 Bytes)
+         - CRC32 (4 bytes)
+         - LastWriteTime (8 bytes)
+         - Some file information (4 bytes)
+         - File Name (variable length) + pointer + allocation structures
+
+Memory usage for archive Decompressing:
+  - Temporary pool:
+     - Memory for LZMA decompressing structures
+  - Main pool:
+     - Memory for decompressed solid block
+     - Memory for temprorary buffers, if BCJ2 fileter is used. Usually these 
+       temprorary buffers can be about 15% of solid block size. 
+  
+
+7z Decoder doesn't allocate memory for compressed blocks. 
+Instead of this, you must allocate buffer with desired 
+size before calling 7z Decoder. Use 7zMain.c as example.
+
+
+Defines
+-------
+
+_SZ_ALLOC_DEBUG   - define it if you want to debug alloc/free operations to stderr.
+
+
+---
+
+http://www.7-zip.org
+http://www.7-zip.org/sdk.html
+http://www.7-zip.org/support.html