@otaupdate/react-native 1.0.4 → 1.0.6

package/README.md

@@ -112,6 +112,34 @@ And the configuration in `android/app/src/main/res/values/strings.xml`:
 <string name="ota_server_url" translatable="false">https://ota.example.com</string>
 ```
 
+**Android — newer (bridgeless) template.** Some RN versions generate a
+`MainApplication.kt` with no `ReactNativeHost`/`getJSBundleFile()` at all —
+it builds `reactHost` directly via `getDefaultReactHost(...)`. If yours looks
+like this, use `OtaUpdate.createReactHost(...)` in its place instead of the
+override above (requires `@otaupdate/react-native@1.0.5`+ — see the version
+note under [Install](#install)):
+
+```kotlin
+import com.otaupdate.OtaUpdate
+
+override val reactHost: ReactHost by lazy {
+  OtaUpdate.createReactHost(
+    context = applicationContext,
+    packageList =
+      PackageList(this).packages.apply {
+        // add(MyReactNativePackage())
+      },
+  )
+}
+```
+
+This isn't just a drop-in replacement for wiring convenience — it's what
+makes mandatory/resume installs apply with **no restart and no visible
+flash**, the same way Expo's own update mechanism works. The plain
+`getDefaultReactHost(...)` call only supports the safer-but-visible
+process-restart behavior (see [Platform verification status](#platform-verification-status)).
+The `strings.xml` configuration above is unchanged either way.
+
 ### Expo
 
 Add the config plugin to `app.json`. There is nothing to patch by hand — the
@@ -178,6 +206,21 @@ SHA-256 verify → bundle swap on restart, `IMMEDIATE` in-process reload, and
 rollback rescuing a device already on the bad build. Confirmed by screenshot,
 native log, and server-side install reports.
 
+**Bare RN Android specifically** applies a mandatory/resume install one of
+two ways, depending on how `MainApplication.kt` is wired (see the Android
+install steps above). `getDefaultReactHost(...)`
+(`@otaupdate/react-native@1.0.4`, RN 0.7x, or `1.0.5`+ without the
+`createReactHost` change) restarts the process — verified against a real
+bare RN 0.87 build on an emulator, logcat-traced end to end: publish →
+download → SHA-256 verify → install → confirmed healthy, including catching
+and fixing a real infinite-reload loop and a lost-update race along the way
+(see the Troubleshooting table). `OtaUpdate.createReactHost(...)` (`1.0.5`+,
+RN 0.80+) is designed to swap the bundle in place with no restart — its
+underlying mechanism (`ReactHostImpl` re-reading the delegate's bundle
+loader on every reload) was confirmed by decompiling the actual compiled RN
+runtime, but the end-to-end in-place-swap path itself has not yet been
+run on a real device. Treat it as promising but unverified until confirmed.
+
 **iOS — verified end to end.** On an Expo SDK 57 / RN 0.86 Release build
 (Xcode 26, iPhone 17 Pro simulator, iOS 26.5): publish → download → SHA-256
 verify → bundle swap on restart, `IMMEDIATE` in-process reload, and rollback
@@ -342,3 +385,5 @@ compatible with. Devices on other binary versions never receive it.
 | Android: mandatory update reload-loops (bare RN) | Fixed in 1.0.2. Before that, `IMMEDIATE`/`ON_NEXT_RESUME` tried an in-place JS reload that reused a bundle path fixed at process start, so the same mandatory update kept re-triggering forever. 1.0.2 does a real process restart instead — update to it. |
 | A newer update never shows up, app stays on an older-than-expected release | Fixed in 1.0.3. `notifyApplicationReady()` used to clear *any* pending hash unconditionally — if a second update was downloaded and queued for a future restart while the first one was still being confirmed, its pending state was silently wiped and the device never advanced to it. |
 | Android: old screen briefly visible during a mandatory/resume install | Improved in 1.0.3. The process-restart fix in 1.0.2 is correct but showed Android's default activity-transition animation (old screen sliding/fading out). 1.0.3 suppresses it via `overridePendingTransition(0, 0)` so the switch is instant. |
+| Android: a normal (non-mandatory) update applies once, then randomly reverts to an older release and re-downloads | Fixed in 1.0.6/1.0.7. `org.json`'s `optString(key)` returns the literal string `"null"` (not Kotlin `null`) when a saved field was JSON `null` — every time `currentHash`/`pendingHash` was genuinely unset and then reloaded from disk, it silently became the four-character string `"null"` instead of real `null`, which then got treated as a real (but non-existent) package and fell back to the binary bundle. This was present since the SDK's first release; iOS was never affected (its store type-checks instead of string-coercing). |
+| Android: a release published with no description shows the literal text "null" | Fixed in 1.0.6/1.0.7. Same `org.json` `optString()` behavior as above, applied to the nullable `description` field. |

package/android/src/main/java/com/otaupdate/OtaUpdateModule.kt

@@ -87,7 +87,12 @@ class OtaUpdateModule(private val reactContext: ReactApplicationContext) :
       val map = Arguments.createMap().apply {
         putString("packageHash", hash)
         putString("label", info.optString("label"))
-        putString("description", info.optString("description").takeIf { it.isNotEmpty() })
+        // Not info.optString("description") — org.json's optString() returns
+        // the literal string "null" (not Kotlin null) for a JSONObject.NULL
+        // value, and description is nullable (see OtaUpdateStore.recordPackage),
+        // so a release published with no description would show the text
+        // "null" instead of none.
+        putString("description", info.opt("description") as? String)
         putBoolean("isMandatory", info.optBoolean("isMandatory"))
         putString("bundlePath", info.optString("bundlePath"))
         putDouble("size", info.optLong("size").toDouble())

package/android/src/main/java/com/otaupdate/OtaUpdateStore.kt

@@ -62,9 +62,20 @@ class OtaUpdateStore(private val context: Context) {
     if (!statusFile.exists()) return
     try {
       val json = JSONObject(statusFile.readText())
-      currentHash = json.optString("currentHash").ifEmpty { null }
-      lastConfirmedHash = json.optString("lastConfirmedHash").ifEmpty { null }
-      pendingHash = json.optString("pendingHash").ifEmpty { null }
+      // NOT json.optString(key) — org.json's optString() returns the literal
+      // string "null" (not Kotlin null, not "") when the stored value is
+      // JSONObject.NULL, which `save()` below writes for every one of these
+      // fields whenever they're genuinely unset. That turned "no pending
+      // update" into a fake pending hash of "null" on every single load,
+      // which then got promoted into currentHash, resolved to no real
+      // package, and silently fell back to the binary bundle — the exact
+      // "reverts to an older app" symptom this was causing. opt(key) returns
+      // the raw value (String, JSONObject.NULL, or absent), so casting to
+      // String? correctly yields null for anything that isn't an actual
+      // string.
+      currentHash = json.opt("currentHash") as? String
+      lastConfirmedHash = json.opt("lastConfirmedHash") as? String
+      pendingHash = json.opt("pendingHash") as? String
       pendingIsLoading = json.optBoolean("pendingIsLoading", false)
 
       val failed = json.optJSONArray("failedHashes") ?: JSONArray()

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@otaupdate/react-native",
-  "version": "1.0.4",
+  "version": "1.0.6",
   "description": "Over-the-air JS bundle updates for React Native \u2014 bare and Expo",
   "license": "MIT",
   "publishConfig": {