@otaupdate/react-native 1.0.4 → 1.0.5

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

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

@@ -3,6 +3,20 @@ package com.otaupdate
 import android.content.Context
 import android.content.pm.PackageManager
 import android.util.Log
+import com.facebook.react.ReactHost
+import com.facebook.react.ReactPackage
+import com.facebook.react.ReactPackageTurboModuleManagerDelegate
+import com.facebook.react.bridge.JSBundleLoader
+import com.facebook.react.common.annotations.UnstableReactNativeAPI
+import com.facebook.react.common.build.ReactBuildConfig
+import com.facebook.react.defaults.DefaultComponentsRegistry
+import com.facebook.react.defaults.DefaultTurboModuleManagerDelegate
+import com.facebook.react.fabric.ComponentFactory
+import com.facebook.react.runtime.BindingsInstaller
+import com.facebook.react.runtime.JSRuntimeFactory
+import com.facebook.react.runtime.ReactHostDelegate
+import com.facebook.react.runtime.ReactHostImpl
+import com.facebook.react.runtime.hermes.HermesInstance
 
 /**
  * Entry point used by the host app's `MainApplication`.
@@ -14,6 +28,16 @@ import android.util.Log
  * That single override is what makes updates take effect: React Native asks
  * for the bundle path at start-up, and we hand back the most recent healthy
  * downloaded bundle (or null, meaning "use the one in the APK").
+ *
+ * Newer (bridgeless / New Architecture) templates have no `ReactNativeHost` to
+ * override at all — `MainApplication` builds a `ReactHost` directly. For that
+ * shape, use `OtaUpdate.createReactHost(...)` in place of the RN template's
+ * `getDefaultReactHost(...)` call — see its doc comment for why this exists.
+ *
+ * This version of the SDK targets RN 0.80+'s `ReactHostDelegate` shape
+ * (confirmed against the compiled runtime — no `getReactNativeConfig()`, no
+ * JSC). For RN 0.7x, use `@otaupdate/react-native@1.0.4` instead — see the
+ * README's "Install" section.
  */
 object OtaUpdate {
 
@@ -24,6 +48,9 @@ object OtaUpdate {
   @Volatile private var store: OtaUpdateStore? = null
   @Volatile private var initialized = false
 
+  /** Set only when the host app used `createReactHost` — see `reload()` in OtaUpdateModule. */
+  @Volatile internal var dynamicReactHost: ReactHost? = null
+
   @JvmStatic
   @Synchronized
   fun store(context: Context): OtaUpdateStore =
@@ -59,6 +86,74 @@ object OtaUpdate {
     }
   }
 
+  /**
+   * Builds a `ReactHost` the same way the RN "new app template"'s
+   * `getDefaultReactHost(...)` does, but with one difference: the bundle
+   * loader it hands to React Native is re-resolved on every access instead of
+   * fixed once at construction time.
+   *
+   * Why this exists: React Native's own `DefaultReactHost.getDefaultReactHost`
+   * takes a plain `jsBundleFilePath` string and bakes it into a
+   * `DefaultReactHostDelegate` once. `ReactHostImpl` genuinely re-asks its
+   * delegate for a bundle loader on every reload — confirmed by decompiling
+   * the compiled runtime, not assumed — but that only helps if the delegate
+   * itself has something new to say. `DefaultReactHostDelegate` never does,
+   * which is *why* `IMMEDIATE`/`ON_NEXT_RESUME` installs never took visible
+   * effect without a full process restart (see `reload()` in
+   * `OtaUpdateModule`). Expo's own bridgeless host avoids this because its
+   * `ReactNativeHostHandler` hook is genuinely re-invoked on each reload,
+   * which is the same property this delegate restores.
+   *
+   * Use in `MainApplication` exactly where the template would call
+   * `getDefaultReactHost`:
+   *
+   *   override val reactHost: ReactHost by lazy {
+   *     OtaUpdate.createReactHost(
+   *       context = applicationContext,
+   *       packageList = PackageList(this).packages,
+   *     )
+   *   }
+   *
+   * This constructs `ReactHostImpl` directly (an `@UnstableReactNativeAPI`
+   * class) rather than going through the public helper, since the public
+   * helper has no seam for a dynamic loader. `reload()` only relies on this
+   * when the host was actually built this way (tracked via
+   * `dynamicReactHost`); apps that still use `getDefaultReactHost` directly,
+   * or the older bridge-mode `DefaultReactNativeHost`, keep the
+   * process-restart fallback — this can't reach into either of those.
+   *
+   * `ReactHostDelegate`'s exact method set is an `@UnstableReactNativeAPI`
+   * surface that has already changed shape once (RN 0.7x had a
+   * `getReactNativeConfig()` method this interface no longer has as of
+   * 0.80) — this build targets the current (0.80+) shape. That's the reason
+   * this functionality ships as a separate SDK version (1.0.5+) rather than
+   * folding into the one 1.0.4 line that supports both RN ranges.
+   */
+  @OptIn(UnstableReactNativeAPI::class)
+  @JvmStatic
+  fun createReactHost(
+    context: Context,
+    packageList: List<ReactPackage>,
+    jsMainModulePath: String = "index",
+    bundleAssetName: String = "index",
+    useDevSupport: Boolean = ReactBuildConfig.DEBUG,
+  ): ReactHost {
+    val appContext = context.applicationContext
+    val delegate = OtaReactHostDelegate(
+      context = appContext,
+      jsMainModulePath = jsMainModulePath,
+      bundleAssetName = bundleAssetName,
+      reactPackages = packageList,
+      jsRuntimeFactory = HermesInstance(),
+      turboModuleManagerDelegateBuilder = DefaultTurboModuleManagerDelegate.Builder(),
+    )
+    val componentFactory = ComponentFactory()
+    DefaultComponentsRegistry.register(componentFactory)
+    val host = ReactHostImpl(appContext, delegate, componentFactory, true, useDevSupport)
+    dynamicReactHost = host
+    return host
+  }
+
   // --- Build-time configuration --------------------------------------------
 
   @JvmStatic
@@ -96,3 +191,38 @@ object OtaUpdate {
       null
     }
 }
+
+/**
+ * The dynamic half of `OtaUpdate.createReactHost` — everything here matches
+ * `DefaultReactHostDelegate` except `jsBundleLoader`, which is a computed
+ * property instead of a value fixed at construction. `ReactHostImpl` reads
+ * this fresh on every reload (confirmed against the compiled runtime), so
+ * this is what lets an installed update take effect in place, without
+ * restarting the process.
+ */
+@OptIn(UnstableReactNativeAPI::class)
+private class OtaReactHostDelegate(
+  private val context: Context,
+  override val jsMainModulePath: String,
+  private val bundleAssetName: String,
+  override val reactPackages: List<ReactPackage>,
+  override val jsRuntimeFactory: JSRuntimeFactory,
+  override val turboModuleManagerDelegateBuilder: ReactPackageTurboModuleManagerDelegate.Builder,
+) : ReactHostDelegate {
+
+  override val bindingsInstaller: BindingsInstaller? = null
+
+  override val jsBundleLoader: JSBundleLoader
+    get() {
+      val path = OtaUpdate.getJSBundleFile(context)
+      return if (path != null) {
+        JSBundleLoader.createFileLoader(path)
+      } else {
+        JSBundleLoader.createAssetLoader(context, "assets://$bundleAssetName", true)
+      }
+    }
+
+  override fun handleInstanceException(error: Exception) {
+    throw error
+  }
+}

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

@@ -221,27 +221,37 @@ class OtaUpdateModule(private val reactContext: ReactApplicationContext) :
   }
 
   /**
-   * Restarts the whole process so the new bundle is loaded.
+   * Applies the new bundle.
    *
-   * This used to try an in-place JS-context reload (ReactHost.reload() via
-   * reflection on the new architecture, recreateReactContextInBackground() as
-   * a bridge-mode fallback) — but on Android BOTH of those reuse a bundle
-   * loader/path that was fixed once at ReactInstanceManager/ReactHost
-   * construction time (see ReactInstanceManager#mBundleLoader, a `final`
-   * field, and DefaultReactHost's internal singleton caching). Neither ever
-   * re-consults MainApplication's getJSBundleFile()/jsBundleFilePath, so an
-   * IMMEDIATE or ON_NEXT_RESUME install silently kept reloading the OLD
-   * bundle forever — for a mandatory update this produced an infinite
-   * reload loop, since the freshly-reloaded old bundle immediately saw the
-   * same "mandatory update available" response and tried to install again.
+   * If the host app was wired up via `OtaUpdate.createReactHost` (see that
+   * function's doc comment), `dynamicHost.reload()` genuinely swaps the
+   * bundle in place — no process restart, no activity transition, no flash —
+   * because that host's delegate re-resolves the bundle path on every reload
+   * instead of reusing one fixed at construction time.
    *
-   * A genuine process kill + relaunch is the only reliable way to force
-   * MainApplication to re-run from scratch and pick up the new bundle path —
-   * the same technique restart libraries like react-native-restart use.
-   * iOS does not need this: RCTTriggerReloadCommandListeners re-queries
-   * bundleURL() fresh on every reload, so it was never affected.
+   * Otherwise (an app still on `getDefaultReactHost` directly, or the older
+   * bridge-mode `DefaultReactNativeHost`) neither of those delegates ever
+   * re-consults MainApplication's bundle path — confirmed against the
+   * compiled runtime, not assumed — so an in-place reload would silently
+   * keep loading the OLD bundle forever. For a mandatory update that meant
+   * an infinite reinstall loop, since the never-actually-updated old bundle
+   * would immediately see the same "mandatory update available" response
+   * again. For those apps, a genuine process kill + relaunch remains the
+   * only reliable fallback, the same technique restart libraries like
+   * react-native-restart use — visible activity-transition animation
+   * suppressed via overridePendingTransition where possible, but still a
+   * real (if brief) restart.
+   *
+   * iOS never needed any of this: RCTTriggerReloadCommandListeners re-queries
+   * bundleURL() fresh on every reload regardless of how the app is set up.
    */
   private fun reload() {
+    val dynamicHost = OtaUpdate.dynamicReactHost
+    if (dynamicHost != null) {
+      dynamicHost.reload("OTA update applied")
+      return
+    }
+
     val context = reactContext.applicationContext
     try {
       val launchIntent = context.packageManager.getLaunchIntentForPackage(context.packageName)

package/package.json

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