[core][Android] Bind `JNIDeallocator` to the context (#22610)

# Why

Binds the `JNIDeallocator` to the current context.

# How

I've discovered that making `JNIDeallocator` static wasn't a go

[core][Android] Bind `JNIDeallocator` to the context (#22610)

# Why

Binds the `JNIDeallocator` to the current context.

# How

I've discovered that making `JNIDeallocator` static wasn't a good decision. This approach failed to function properly when we migrated to our API in the dev-launcher context. Whenever the user switches between the app and launcher, the app will crash since the dev-launcher remains in memory, but the app context's destruction causes all registered objects inside the `JNIDeallocator` to deallocate. Consequently, we're removing js objects associated with the dev-launcher context, even if it's still valid.

# Test Plan

- bare-expo with and without dev-client ✅
- unit tests ✅

show more ...

[core] fix build error on rn 0.72 (#22170)

# Why

after react-native 0.72, the `LongLivedObjectCollection` constructor is removed and only available for the singleton: https://github.com/facebook/

[core] fix build error on rn 0.72 (#22170)

# Why

after react-native 0.72, the `LongLivedObjectCollection` constructor is removed and only available for the singleton: https://github.com/facebook/react-native/blob/9e5c963e2dbd90dbf2d260b67c2897e924be066e/packages/react-native/ReactCommon/react/bridging/LongLivedObject.h#L41-L44
the original solution from #19699 will have a build error on react-native 0.72

# How

rather than create a dedicated `LongLivedObjectCollection`, use the singleton `LongLivedObjectCollection` and do cleanup when `~ExpoModulesHostObject()`.

note: for react-native, the only call path to `LongLivedObjectCollection::get().clear()` is from TurboModuleBinding. in old architecture mode, react-native will not cleanup the `LongLivedObjectCollection`.

# Test Plan

follow #19699 to test the reloading

show more ...

[core][Android] Make module initialization lazy (#21774)

# Why

This approach guarantees that module functions and properties are only initialized upon user request. When the module is required by

[core][Android] Make module initialization lazy (#21774)

# Why

This approach guarantees that module functions and properties are only initialized upon user request. When the module is required by JavaScript, it does not automatically mean that all of its members will be added at that moment. Instead, they will be added at a later time, as needed.

# How

Added `LazyObject` abstraction as it was done on iOS.
Used an arbitrary js object instead of HostObject to define modules - it'll be handy in the future when I'll be adding shared classes.

# Test Plan

- unit tests ✅
- bare-expo ✅

show more ...

[modules][Android] Fix `JSCRuntime destroyed with a dangling API object` (#19487)

# Why

Closes https://github.com/expo/expo/issues/19221.

# How

In the current memory modal, all of our JSI r

[modules][Android] Fix `JSCRuntime destroyed with a dangling API object` (#19487)

# Why

Closes https://github.com/expo/expo/issues/19221.

# How

In the current memory modal, all of our JSI references are cleared when GC runs through java unused objects. It turns out that is not the best flow, because JSC has an assertion that checks if all references were cleared. So we have to remove dangling references before the JSC runtime fully deallocates.

# Test Plan

- bare-expo with JSC and Heremes ✅

show more ...

[e-m-c][Android] Fix build

My suggestion in #17836 was actually invalid,
because `PropNameID` has no default constructor,
and invocation of std::vector constructor automatically
tried to create its

[e-m-c][Android] Fix build

My suggestion in #17836 was actually invalid,
because `PropNameID` has no default constructor,
and invocation of std::vector constructor automatically
tried to create its elements using the default constructor

show more ...

[sweet API][Kotlin] Export property names in the expo modules host object (#17836)

# Why

Makes sure that `getPropertyNames` function inside `ExpoModulesHostObject` works.

# How

Exports all

[sweet API][Kotlin] Export property names in the expo modules host object (#17836)

# Why

Makes sure that `getPropertyNames` function inside `ExpoModulesHostObject` works.

# How

Exports all modules names.

# Test Plan

- NCL and `ExpoModules` screen ✅

show more ...

[module-core][Kotlin] Add basic support for sync function (#16977)

# Why

Closes ENG-4608.
Adds basic support for sync function.

# How

- Created ExpoModulesHostObject that installs into the

[module-core][Kotlin] Add basic support for sync function (#16977)

# Why

Closes ENG-4608.
Adds basic support for sync function.

# How

- Created ExpoModulesHostObject that installs into the runtime as `global.ExpoModules`. A host object is an abstract object where we can define our property getter, allowing us to create JS object for each module lazily.
- Added `isAsync` property to sweet functions and `runSynchronously()` modifier - that will be changed in the future.
- Created `JavaScriptModuleObject` that represents a module in the JS world. It has a map of methods with a cached body.
- All the communication goes via two kotlin methods - `getJavaScriptModuleObject` (which returns a hybrid representation of the module) and `callMethodSync` (which is calling correct implementation). Right now, I'm not using lambdas to pass Kotlin functions into CPP, because I don't see any reason why should I.

# Test Plan

- tested with bare-expo ✅

show more ...