[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][Android] Add functions converter (#21976)

# Why

Adds functions converter.

# How

- Adds a frontend and backend converter for js function type
- Adds ability to call those functions

[core][Android] Add functions converter (#21976)

# Why

Adds functions converter.

# How

- Adds a frontend and backend converter for js function type
- Adds ability to call those functions via Kotlin code

# Test Plan

- unit tests ✅

show more ...

[packages] Fix expo-modules-core androidTest (#19559)

# Why

follow up with #19411 to make expo-modules-core androidTest correctly

# How

those commented test cases break because we try to ca

[packages] Fix expo-modules-core androidTest (#19559)

# Why

follow up with #19411 to make expo-modules-core androidTest correctly

# How

those commented test cases break because we try to catch exceptions across shared library boundaries. there are a couple root causes actually:

## incompatible ndk versions

before ndk r23, the unwind library is libgcc, and after r23, the implementation is llvm libunwind. these two unwind implementation is incompatible. [email protected] and prebuilt react-native libs are all built from ndk r21. if we run the androidTest on m1 machine, we will use ndk r24 to build libraries. that's why we cannot catch fbjni exceptions in this situation. the pr tries to re-implement fbjni method calls and throw exceptions inline. that would make jni exceptions catchable.

other than that, when targeting prebuilt react-native, we should also use the same ndk r21 to build expo-modules-core. even we are on m1 machines.

## jscexecutor missing `_Unwind_Resume` symbol

the case happens when ndk r21 + jsc only, and this is also our ci android instrumented test environment. as [the ndk document](https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#unwinding) mentioned, for ndk r21, we should take care linking order. [this react-native fork patch](https://github.com/expo/react-native/commit/3986a385502df3eb207ca05f0b558171a600166c) addressed the issue.

if we test jsc on bare-expo, these test cases will still crash. i don't want to fix it or proposing the fix to upstream in the meantime. the latest react-native with AGP 7.3, the side-by-side ndk is already r23. since these are actually error cases, it's just not crash with correct stacktrace (not from expo-modules-core, but jscexecutor)

## c++_static runtime in expo-modules-core androidTest

always uses c++_shared runtime: the c++_static runtime doesn't well support the throw exceptions between shared library boundaries. we used c++_static because we want to fix the `et android-native-unit-tests -t instrumented` failures where the `./gradlew :expo-modules-core:connectedAndroidTest :expo-eas-client:connectedAndroidTest` will have duplicated fbjni.so build errors. this pr also reorganizes `et android-native-unit-tests` to build expo-modules-core androidTest exclusively.

# Test Plan

android instrumented ci passed

show more ...

[sweet API] Throw missing exceptions (#18578)

# Why

I forgot to throw exceptions in two corner cases:
- when js type is not convertible to a Kotlin object - like Symbol
- when the js value has

[sweet API] Throw missing exceptions (#18578)

# Why

I forgot to throw exceptions in two corner cases:
- when js type is not convertible to a Kotlin object - like Symbol
- when the js value has an unknown type

# How

- Exported `UnknownException` to the C++.
- Add missing exceptions.

# Test Plan

- unit tests that will be added in a separate PR

show more ...

[sweet API][Kotlin] Implement sweet typed arrays (#18379)

# Why

A follow-up to the https://github.com/expo/expo/pull/17667.

# How

- Reused some C++ utils to deal with typed arrays
- Made c

[sweet API][Kotlin] Implement sweet typed arrays (#18379)

# Why

A follow-up to the https://github.com/expo/expo/pull/17667.

# How

- Reused some C++ utils to deal with typed arrays
- Made classes for typed arrays on both sides: native and JS
- Added new converters to obtain typed arrays as function arguments
- Added tests

# Test Plan

- unit tests ✅

show more ...

[sweet API][Kotlin] Simplify usage of `JavaScriptRuntime` (#18382)

# Why

In many places, we have a similar code that accesses the `jsi::Runtime` from `weak_ptr`. It makes the code hard to read. S

[sweet API][Kotlin] Simplify usage of `JavaScriptRuntime` (#18382)

# Why

In many places, we have a similar code that accesses the `jsi::Runtime` from `weak_ptr`. It makes the code hard to read. So I decided to decorate the `std::weak_ptr<JavaScriptRuntime>` with additional access functions.

# How

Added a `WeakRuntimeHolder` with two additional methods to access `jsi::Runtime`

# Test Plan

- unit tests ✅

show more ...

[sweet API][Kotlin] Add `isArray` and `getArray` functions to `JavaScriptValue` (#17940)

# Why

Adds functions to obtain arrays of `JavaScriptValue` from the `JavaScriptValue`.

# How

It was

[sweet API][Kotlin] Add `isArray` and `getArray` functions to `JavaScriptValue` (#17940)

# Why

Adds functions to obtain arrays of `JavaScriptValue` from the `JavaScriptValue`.

# How

It was pretty straightforward. Iterate through js array and box all values in the `JavaScriptValue` object.

# Test Plan

- unit test will be added in a different PR ✅

show more ...

[sweet API][Kotlin] Add `JavaScriptObject.setProperty` (#17684)

# Why

Adds `setProperty` to the `JavaScriptObject`.

# How

- Adds a base interface to indicate if the derived class wrap a jsi

[sweet API][Kotlin] Add `JavaScriptObject.setProperty` (#17684)

# Why

Adds `setProperty` to the `JavaScriptObject`.

# How

- Adds a base interface to indicate if the derived class wrap a jsi::Value or jsi::Object.
- Adds a conversion between JNI and jsi objects based on the type traits.
- Hides raw JNI API in the `JavaScriptObject` using methods overload.
- Adds unit tests

# Test Plan

- unit tests ✅

show more ...

[sweet][Kotlin] Add `evaluateScript` function (#17586)

# Why

Adds a `evaluateScript` function.
Also, adds wrappers for `jsi::Value` and `jsi::Object`.

# How

Exposes a `evaluateScript` fun

[sweet][Kotlin] Add `evaluateScript` function (#17586)

# Why

Adds a `evaluateScript` function.
Also, adds wrappers for `jsi::Value` and `jsi::Object`.

# How

Exposes a `evaluateScript` function to Kotlin (it's pretty handy in the tests environment). I've also created a wrapper for jsi types. For now, it's read-only, but that will be expanded in the future.

# Test Plan

- unit tests ✅

show more ...