[core] add getJSBundleFile support for bridgeless mode

[Kudo]

Why

expo-updates uses the ReactNativeHost.getJSBundleFile() to define the launch bundle path. the defaultReactHost doesn't support it, so expo-updates always uses the embedded bundle.

How

reference the logic from bridged ReactInstanceManager to support the getJSBundleFile(): https://github.com/facebook/react-native/blob/15a5638c621cbec4a9fcb5ae94938120cdc32fae/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManagerBuilder.java#L107-L114

Test Plan

test canary + expo-updates + eas updates that should launch the remote bundle

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for npx expo prebuild & EAS Build (eg: updated a module plugin).

[expo-bot]

The Pull Request introduced fingerprint changes against the base commit: a745c5e

Fingerprint diff

[
  {
    "type": "dir",
    "filePath": "../../packages/expo/android",
    "reasons": [
      "expoAutolinkingAndroid"
    ],
    "hash": "15a1b88268d183e2033498e5180e5c4a4eac6802"
  }
]

---

Generated by PR labeler 🤖

[ide]

@wschurman adding you as a post-commit reviewer so you're aware of this change. It should be relatively quick to look at.

[ide]

Would it be helpful to add comments saying which parts of the code run in bridgeless mode vs. with the bridge enabled? Later, when there is only bridgeless mode, we can remove the comments.

[Kudo]

good question! basically this whole ExpoReactHostFactory file is for bridgeless. react-native has a convention

• bridgeless: ReactHost, ReactInstance
• bridge: ReactNativeHost, ReactInstanceMananger, Catalyst*

there's some effort to adapt from ReactNativeHost to ReactHost without much change. in this example, it reads some necessary properties from ReactNativeHost.

basically i would try to follow the same effort to migrate our ReactNativeHostHandler to be bridgeless/bridge independent, so that expo modules don't have to handle these different cases. though expo-dev-client and expo-updates are two special cases that they are some tight coupled code inside. we are aware and working on the migration.

[ide]

Ah okay. Thanks for the explanation. If I understand correctly, does that mean that when bridged mode is removed (one day, in the future), we'll move the code from ReactNativeHostWrapper into ReactHostFactory, since ReactNativeHost will no longer exist?

[Kudo]

If I understand correctly, does that mean that when bridged mode is removed (one day, in the future), we'll move the code from ReactNativeHostWrapper into ReactHostFactory, since ReactNativeHost will no longer exist?

right! we will merge into one class. the class name might be ReactHostWrapper, depending on how MainApplication from the template changes over time. if the logic for ReactNativeHost moved to ReactHost, then we may have a ReactHostWrapper after all.