Run the ReactAndroid JNI gtests as instrumentation tests (#57976)

Summary:
Pull Request resolved: #57976

The `ReactAndroid` JNI gtests in `react/fabric/test` and `react/jni/test` were configured as plain host C++ tests, but they link against the Android-only JNI libraries. The resulting binary is an Android aarch64 ELF that needs `/system/bin/linker64` and so cannot run on a Linux host:

```
qemu-aarch64: Could not open '/system/bin/linker64': No such file or directory
Test failed to produce the expected output! ... IO error: No result xml files found.
```

They were not failing their assertions — they were never executing. The runner enumerated case names statically out of the binary without running it, so all 6 cases across the two targets were known and reported as failing, with no stack traces at all. The absence of stack traces was itself the tell: the process never started, so no gtest XML was ever produced.

Both targets move to the established pattern for gtests against Android-only native libs: build them as Android instrumentation tests, packaged into an APK and run on a device or emulator.

`FabricMountingManagerTest` can drop its deliberate leak as a result. It previously allocated the manager with a no-op deleter, because `~FabricMountingManager()` calls `jni::ThreadScope::WithClassLoader`, which throws without an attached `JavaVM`. Under instrumentation the gtest runs inside a native method registered via fbjni `makeNativeMethod`, so `cachedOrNull()` is non-null and the closure runs inline — destruction is safe. The fixture now holds a default-constructed (null) `jni::global_ref` member and returns a `std::unique_ptr`; releasing a null `global_ref` is a no-op. All four test bodies are byte-identical. `ModuleRegistryBuilderTest.cpp` is a comment-only correction.

Changelog: [Internal]

Differential Revision: D116286866

fbshipit-source-id: a283deae18e42b0caad330bd3a27307428cfcec4

Author: GijsWeterings

packages/react-native/ReactAndroid/src/main/jni/react/fabric/test/FabricMountingManagerTest.cpp

@@ -32,32 +32,24 @@ namespace facebook::react {
  * `allocatedViewsMutex_`; they never call into Java. That is what makes them
  * unit-testable here.
  *
- * NOTE: `~FabricMountingManager()` calls `jni::ThreadScope::WithClassLoader`,
- * which throws `std::runtime_error` when no JavaVM has been attached (see
- * `xplat/spectrum/androidLibs/fbjni/cxx/fbjni/detail/Environment.h`). Because
- * no JVM is available in this host-side test, the manager instance is
- * intentionally never destroyed: each test allocates a single
- * `FabricMountingManager` on the heap and wraps it in a `std::shared_ptr`
- * with a no-op deleter. The resulting per-test leak is bounded (one ~100-byte
- * instance) and does not cross test boundaries.
+ * `react/fabric:jni` is an Android-only native library, so this target is
+ * built as a JNI instrumentation test: the gtest binary is packaged into an
+ * APK and executed on a device/emulator. A JavaVM is therefore attached, which
+ * `~FabricMountingManager()` requires — it calls
+ * `jni::ThreadScope::WithClassLoader`, which throws `std::runtime_error` when
+ * fbjni has not been initialized (see
+ * `xplat/spectrum/androidLibs/fbjni/cxx/fbjni/detail/Environment.h`).
  */
 class FabricMountingManagerTest : public ::testing::Test {
  protected:
-  // Returns a `FabricMountingManager` whose destructor is suppressed.
-  // See the class-level note above for why this is necessary.
-  static std::shared_ptr<FabricMountingManager> makeManager() {
-    // `jni::global_ref<>` default-constructs to an empty (null) reference,
-    // so no JNI calls are performed during construction. The empty
-    // reference is safe to copy into the manager because the
-    // surface-registry methods under test never dereference
-    // `javaUIManager_`.
-    auto* emptyRef = new jni::global_ref<JFabricUIManager::javaobject>();
-    auto* raw = new FabricMountingManager(*emptyRef);
-    // `emptyRef` is intentionally leaked: resetting it would also engage
-    // `WithClassLoader`, which requires an attached JavaVM.
-    return {raw, [](FabricMountingManager* /*unused*/) noexcept {
-              // No-op deleter: see class-level note.
-            }};
+  // An empty (null) reference: `jni::global_ref<>` default-constructs to null,
+  // so no JNI call happens when it is created, copied into the manager, or
+  // released. The surface-registry methods under test never dereference
+  // `javaUIManager_`.
+  jni::global_ref<JFabricUIManager::javaobject> emptyUIManager_;
+
+  std::unique_ptr<FabricMountingManager> makeManager() {
+    return std::make_unique<FabricMountingManager>(emptyUIManager_);
   }
 };
 

packages/react-native/ReactAndroid/src/main/jni/react/jni/test/ModuleRegistryBuilderTest.cpp

@@ -25,7 +25,7 @@ namespace facebook::react {
  * exercised by the Robolectric / instrumentation tests that run against a
  * real JVM.
  *
- * The one branch that can be validated host-side without an attached JavaVM
+ * The one branch that can be validated without calling into Java at all
  * is `buildNativeModuleList`'s null-collection guard: when the incoming
  * `alias_ref<JCollection<...>>` is a null reference, the function must
  * short-circuit and return an empty vector rather than dereferencing the
@@ -47,7 +47,7 @@ namespace facebook::react {
  * bring-up paths that legitimately pass no legacy Java modules). Because
  * the crash would only surface once the process actually reaches this
  * code with a null collection, catching it here — instead of relying on
- * a device-side smoke test — is the earliest signal available.
+ * an app-level smoke test — is the earliest signal available.
  *
  * The `Instance` weak_ptr and `MessageQueueThread` shared_ptr are supplied
  * as empty on purpose: the guard runs before either is dereferenced, so