5383 Commits

Author SHA1 Message Date
Distiller 4bdec975c9 [0.69.4] Bump version numbers 2022-08-08 11:08:57 +00:00
Kunal Farmah 8524177910 Added additional builder method receiving arguments for using jsc or hermes to correctly decide which DSO to load at app startup. (#33952)
Summary:
The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration.
Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native.
So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files.

The code snippet in **ReactInstanceManager** for adding a new setter method:

```
  /**
   * Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
   * Uses the enum {link JSInterpreter}
   * param jsEngine
   */
  private void setJSEngine(JSInterpreter jsEngine){
    this.jsEngine = jsEngine;
  }

  /**
   * Utility setter to set the required JSEngine as HERMES or JSC
   * Defaults to OLD_LOGIC if not called by the host app
   * param hermesEnabled
   * hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
   */
  public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
    if(hermesEnabled){
      setJSEngine(JSInterpreter.HERMES);
    }
    else{
      setJSEngine(JSInterpreter.JSC);
    }
    return this;
  }
```

The code snippet for the new logic in **ReactInstanceManagerBuilder**:

1) Setting up the new logic:
Adding a new enum class :
```
  public enum JSInterpreter {
    OLD_LOGIC,
    JSC,
    HERMES
  }
```

A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable.
```
 /**
   * Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
   * Uses the enum {link JSInterpreter}
   * param jsEngine
   */
  private void setJSEngine(JSInterpreter jsEngine){
    this.jsEngine = jsEngine;
  }

  /**
   * Utility setter to set the required JSEngine as HERMES or JSC
   * Defaults to OLD_LOGIC if not called by the host app
   * param hermesEnabled
   * hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
   */
  public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
    if(hermesEnabled){
      setJSEngine(JSInterpreter.HERMES);
    }
    else{
      setJSEngine(JSInterpreter.JSC);
    }
    return this;
  }
```

2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one:

```
   private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
    String appName, String deviceName, Context applicationContext) {

    // Relying solely on try catch block and loading jsc even when
    // project is using hermes can lead to launch-time crashes especially in
    // monorepo architectures and hybrid apps using both native android
    // and react native.
    // So we can use the value of enableHermes received by the constructor
    // to decide which library to load at launch

    // if nothing is specified, use old loading method
    // else load the required engine
    if (jsEngine == JSInterpreter.OLD_LOGIC) {
      try {
        // If JSC is included, use it as normal
        initializeSoLoaderIfNecessary(applicationContext);
        JSCExecutor.loadLibrary();
        return new JSCExecutorFactory(appName, deviceName);
      } catch (UnsatisfiedLinkError jscE) {
        if (jscE.getMessage().contains("__cxa_bad_typeid")) {
          throw jscE;
        }
        HermesExecutor.loadLibrary();
        return new HermesExecutorFactory();
      }
    } else if (jsEngine == JSInterpreter.HERMES) {
      HermesExecutor.loadLibrary();
      return new HermesExecutorFactory();
    } else {
      JSCExecutor.loadLibrary();
      return new JSCExecutorFactory(appName, deviceName);
    }
  }
```

### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix**
```
builder = ReactInstanceManager.builder()
                .setApplication(this)
                .setJsEngineAsHermes(BuildConfig.HERMES_ENABLED)
                .setBundleAssetName("index.android.bundle")
                .setJSMainModulePath("index")
```

where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle:

`def enableHermes = project.ext.react.get("enableHermes", true)
`
and then

```
defaultConfig{
if(enableHermes) {
            buildConfigField("boolean", "HERMES_ENABLED", "true")
        }
        else{
            buildConfigField("boolean", "HERMES_ENABLED", "false")
        }
}
```

Our app was facing a similar issue as listed in this list:  **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button.

This change can possibly solve many of the issues listed in the list as it solved ours.

## Changelog

[GENERAL] [ADDED] - An enum JSInterpreter  in com.facebook.react package:
```
/**
 * An enum that specifies the JS Engine to be used in the app
 * Old Logic uses the legacy code
 * JSC/HERMES loads the respective engine using the revamped logic
 */
public enum JSInterpreter {
  OLD_LOGIC,
  JSC,
  HERMES
}
```

[GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder:

```
   private JSInterpreter  jsEngine = JSInterpreter.OLD_LOGIC;
```

[GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder:
```
  /**
   * Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
   * Uses the enum {link JSInterpreter}
   * param jsEngine
   */
  private void setJSEngine(JSInterpreter jsEngine){
    this.jsEngine = jsEngine;
  }

  /**
   * Utility setter to set the required JSEngine as HERMES or JSC
   * Defaults to OLD_LOGIC if not called by the host app
   * param hermesEnabled
   * hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
   */
  public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
    if(hermesEnabled){
      setJSEngine(JSInterpreter.HERMES);
    }
    else{
      setJSEngine(JSInterpreter.JSC);
    }
    return this;
  }

```

[GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method

```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
    String appName, String deviceName, Context applicationContext) {

    // Relying solely on try catch block and loading jsc even when
    // project is using hermes can lead to launch-time crashes especially in
    // monorepo architectures and hybrid apps using both native android
    // and react native.
    // So we can use the value of enableHermes received by the constructor
    // to decide which library to load at launch

    // if nothing is specified, use old loading method
    // else load the required engine
    if (jsEngine == JSInterpreter.OLD_LOGIC) {
      try {
        // If JSC is included, use it as normal
        initializeSoLoaderIfNecessary(applicationContext);
        JSCExecutor.loadLibrary();
        return new JSCExecutorFactory(appName, deviceName);
      } catch (UnsatisfiedLinkError jscE) {
        if (jscE.getMessage().contains("__cxa_bad_typeid")) {
          throw jscE;
        }
        HermesExecutor.loadLibrary();
        return new HermesExecutorFactory();
      }
    } else if (jsEngine == JSInterpreter.HERMES) {
      HermesExecutor.loadLibrary();
      return new HermesExecutorFactory();
    } else {
      JSCExecutor.loadLibrary();
      return new JSCExecutorFactory(appName, deviceName);
    }
  }
```

Pull Request resolved: https://github.com/facebook/react-native/pull/33952

Test Plan:
The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO

Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project.
It can be like:
```
packagingOptions {
        if (enableHermes) {
            exclude "**/libjsc*.so"
        }
    }
```

Reviewed By: lunaleaps

Differential Revision: D37191981

Pulled By: cortinico

fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e
2022-08-02 12:27:15 +01:00
Distiller 6fe8367bea [0.69.3] Bump version numbers 2022-07-25 13:00:12 +00:00
Distiller 75eb6e7bf4 [0.69.2] Bump version numbers 2022-07-20 09:39:02 +00:00
Distiller 587eb4ed13 [0.69.1] Bump version numbers 2022-06-29 10:03:41 +00:00
Olivier Payen dc334a2baf Use monotonic clock for performance.now() (#33983)
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.

This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.

With this change, the clock is now monotonic (and the implementation stays consistent between platforms).

More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977

## Changelog

[General] [Fixed] - Use monotonic clock for performance.now()

Pull Request resolved: https://github.com/facebook/react-native/pull/33983

Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```

Reviewed By: JoshuaGross, cipolleschi

Differential Revision: D37066999

Pulled By: dmitryrykun

fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
2022-06-29 11:41:29 +02:00
Distiller 74a08a3d2c [0.69.0] Bump version numbers 2022-06-22 17:36:51 +00:00
Distiller e68aa6a019 [0.69.0-rc.6] Bump version numbers 2022-06-01 16:18:19 +00:00
Distiller 6d200c32cb [0.69.0-rc.5] Bump version numbers 2022-05-31 12:27:32 +00:00
Distiller 2c6df0209d [0.69.0-rc.4] Bump version numbers 2022-05-31 08:21:42 +00:00
Nicola Corti 9a4e71621b Revert "[0.69.0-rc.4] Bump version numbers"
This reverts commit 5f50b0b407.
2022-05-30 17:15:24 +01:00
Distiller 5f50b0b407 [0.69.0-rc.4] Bump version numbers 2022-05-30 15:22:07 +00:00
Distiller 27751babe6 [0.69.0-rc.3] Bump version numbers 2022-05-24 15:35:09 +00:00
Distiller 1eb90f52c7 [0.69.0-rc.2] Bump version numbers 2022-05-20 10:56:06 +00:00
Distiller 3310ccd2a6 [0.69.0-rc.1] Bump version numbers 2022-05-11 10:11:04 +00:00
Kudo Chien 2e7ba66087 add back hermes inspector support (#33778)
Summary:
the `WITH_INSPECTOR` build flag is missing from cmake migration. original we had it in [Application.mk](https://github.com/facebook/react-native/blob/ed46ea2058b909a2dd401347d68956324961ec2c/ReactAndroid/src/main/jni/Application.mk#L29)

this pr adds back the build flag and make hermes inspector (or debugging hermes in flipper) work again.

## Changelog

[Android] [Fixed] - add back hermes inspector support

Pull Request resolved: https://github.com/facebook/react-native/pull/33778

Test Plan: test on rn-tester hermes variant

Reviewed By: cipolleschi

Differential Revision: D36204525

Pulled By: cortinico

fbshipit-source-id: 417874a7d0e05b5ee886f3160d526ff9c2df44ee
2022-05-11 12:04:06 +02:00
Anandraj 7b76abc0d3 [Main][Windows] Working around Long paths limitation on Windows (#33707)
Co-authored-by: Aleš Pergl <alespergl@users.noreply.github.com>
Co-authored-by: Ales Pergl <alpergl@microsoft.com>
2022-05-11 10:58:15 +01:00
Distiller 6efb51777c [0.69.0-rc.0] Bump version numbers 2022-04-28 14:12:53 +00:00
Nicola Corti fc3040b2b6 Revert "[0.69.0-rc.0] Bump version numbers"
This reverts commit 9af395e913.
2022-04-28 16:01:41 +02:00
Distiller 9af395e913 [0.69.0-rc.0] Bump version numbers 2022-04-28 12:23:22 +00:00
Nicola Corti c11785b90d Update the hermesc output to be inside the $buildDir
Summary:
Currently, we build Hermes by specifying the Cmake flag `-B ./hermes`. That means
that the output out the build is going to be placed along side the source code.

This is fine, as long as the user doesn't use the `REACT_NATIVE_OVERRIDE_HERMES_DIR`,
which is used inside the Hermes CI. In that case, the source location of Hermes can be
changed, leading to scenarios where `hermesc` can't be found.

Here I'm changing the flag to be `-B $buildDir/hermes`. Therefore the build output
will always be located within the `./ReactAndroid/hermes-engine/build` folder.
This is a more robust solution as the build output will be encapsulated within the
`build/` folder.

Changelog:i
[Internal] [Changed] - Update the hermesc output to be inside the $buildDir

Reviewed By: cipolleschi

Differential Revision: D35964402

fbshipit-source-id: aa7e0775b282897d5a99c1c46265884d19c5f289
2022-04-27 09:41:11 -07:00
Xin Chen 36c4e42d82 Add null check for gesture ended notifier
Summary:
The `notifyNativeGestureEnded` API is added to notify user gesture ended, so that any optimization we had during handling the gesture can be restored.

It's possible that when the gesture finishes, the RootView is already unmounted from the native side. This might happen when user starts a gesture that caused leave of the RN screen, or close the app.

Changelog:
[Android][Internal] - Avoid NPE for gesture notifier

Reviewed By: javache

Differential Revision: D35902523

fbshipit-source-id: 9bb5819a53dd053290031eebaae1b8f0318ae534
2022-04-26 14:18:17 -07:00
Nicola Corti c12423cbdc Use Android SDK version of CMake rather than an external one
Summary:
This diff updates the CMake command used for configuring the Hermes build
from `cmake` from $PATH to the `cmake` bundled with the Android SDK.
If not found, fallsback to the previous behavior.

This relaxes the requirement of having to ask our users to install CMake
in their CLIs.

Changelog:
[Internal] [Changed] - Use Android SDK version of CMake rather than an external one

Reviewed By: neildhar

Differential Revision: D35931306

fbshipit-source-id: 8d6c554e5e9040e3bd4fed5f72fbdb0eb61d745a
2022-04-26 07:19:00 -07:00
Nicola Corti 1730949e94 Expose scheduler through FabricUIManager
Summary:
Allows to access `react::renderer::Scheduler` given `FabricUIManager` from Java side.

Changelog: [Added] Added `FabricUIManager` binding with FBJNI

Reviewed By: javache

Differential Revision: D35313399

fbshipit-source-id: 54e7adcceae40368c2735ddfc8a083f87b08dc5e
2022-04-26 05:11:05 -07:00
Xin Chen f40976cd24 Refactor findTargetPathAndCoordinatesForTouch to improve perf of event delivery
Summary:
Refactor of TouchTargetHelper.findTargetPathAndCoordinatesForTouch to avoid unnecessary lookup of views during the dispatching of Hover Events

changelog: [internal] internal

Reviewed By: lunaleaps, mdvacca

Differential Revision: D32296003

fbshipit-source-id: 93834c37331ad5d75645a5665a1c8c3d965765fb
2022-04-25 14:11:11 -07:00
Steven Vascellaro c6dc01fac6 Fix typo in comments (#33694)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33694

Fixes a pluralization typo

Changelog:
[General][Fixed] - Fixed a pluralization typo in docstrings.

Reviewed By: javache

Differential Revision: D35856572

fbshipit-source-id: 88118be36107025b0b513bf2ec6671304d789204
2022-04-25 10:15:36 -07:00
Carmi Grushko 4f855c8a2a @allow-large-files [MSDK] Update ktfmt component on FBS:master
Reviewed By: strulovich

Differential Revision: D35774317

fbshipit-source-id: ce59de8c38e385827a9ee62473b57a1791f18d27
2022-04-25 03:08:51 -07:00
Alex Liang 7454044542 Make ReactModuleSpecProcessor print stacktrace when typeElement.getAnnotation fails
Summary:
WHen porting TurboModules or adding new TurboModules, ReactModuleSpecProcessor may fail during buck build, and when the failure is caused by typeElement.getAnnotation, no useful information gets collected, making it difficult to debug.
So here I am adding a try & catch so we can get useful debugging info.

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D35767207

fbshipit-source-id: 7e1f9dfbfd31339ab37af19c51d85085e100955a
2022-04-22 16:57:51 -07:00
Nicola Corti 56fd85e371 Customize the Hermes version using the RN one
Summary:
This diff allows to customize the Hermes version exposed by the VM with
a version provided by React Native. This will make clearer that a specific
version of Hermes was built at a specific point of the RN release process.

Changelog:
[Internal] [Changed] - Customize the Hermes version using the RN one

Reviewed By: neildhar

Differential Revision: D35820268

fbshipit-source-id: 3e76db921c12a599743fb9312f52edd06d223bad
2022-04-22 07:52:27 -07:00
Nicola Corti d7b64b8d4b Expose an API to enable Concurrent Root on Android (#33645)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33645

With React 18, we now need to allow users on Fabric to opt-in for Concurrent Root.

This commit adds a new method that can be called on the ReactActivityDelegate
that can be used to set the `concurrentRoot` flag on the `initialProps` on the Render.

Changelog:
[Android] [Added] - Expose an API to enable Concurrent Root on Android

Reviewed By: mdvacca

Differential Revision: D35614879

fbshipit-source-id: 2de83e8115d3748c0346cdec6f31b2ab1f899478
2022-04-20 08:03:21 -07:00
Moti Zilberman a12959546a Revert D34518929: TalkBack support for ScrollView accessibility announcements (list and grid)
Differential Revision:
D34518929 (https://github.com/facebook/react-native/commit/dd6325bafe1a539d348f3710e717a6344576b859)

Original commit changeset: 410a05263a56

Original Phabricator Diff: D34518929 (https://github.com/facebook/react-native/commit/dd6325bafe1a539d348f3710e717a6344576b859)

fbshipit-source-id: 114d0910970c5f5caefb98c378722faba283f2a1
2022-04-20 06:48:19 -07:00
Xin Chen cf55fd587e Add scrollEventThrottle prop support in Android
Summary:
This diff adds `scrollEventThrottle` prop to Android platform. See [public doc](https://reactnative.dev/docs/scrollview#scrolleventthrottle-ios) for this prop. Currently this is only supported in iOS.

The throttling logic is [following](https://github.com/facebook/react-native/blob/main/React/Views/ScrollView/RCTScrollView.m#L650) iOS existing one.

Changelog:
[Android][Added] - Add scrollEventThrottle prop support in Android

Reviewed By: mdvacca

Differential Revision: D35735978

fbshipit-source-id: 97b73b4d5fbb93696555917b9252e95fd79ca581
2022-04-19 20:28:17 -07:00
fabriziobertoglio1987 dd6325bafe TalkBack support for ScrollView accessibility announcements (list and grid) (#33180)
Summary:
This issue fixes [30977][17] . The Pull Request was previously published by [intergalacticspacehighway][13] with [31666][19].
The solution consists of:
1. Adding Javascript logic in the [FlatList][14], SectionList, VirtualizedList components to provide accessibility information (row and column position) for each cell in the method [renderItem][20] as a fourth parameter [accessibilityCollectionItem][21]. The information is saved on the native side in the AccessibilityNodeInfo and announced by TalkBack when changing row, column, or page ([video example][12]). The prop accessibilityCollectionItem is available in the View component which wraps each FlatList cell.
2. Adding Java logic in [ReactScrollView.java][16] and HorizontalScrollView to announce pages with TalkBack when scrolling up/down. The missing AOSP logic in [ScrollView.java][10] (see also the [GridView][11] example) is responsible for announcing Page Scrolling with TalkBack.

Relevant Links:
x [Additional notes on this PR][18]
x [discussion on the additional container View around each FlatList cell][22]
x [commit adding prop getCellsInItemCount to VirtualizedList][23]

## Changelog

[Android] [Added] - Accessibility announcement for list and grid in FlatList

Pull Request resolved: https://github.com/facebook/react-native/pull/33180

Test Plan:
[1]. TalkBack announces pages and cells with Horizontal Flatlist in the Paper Renderer ([link][1])
[2]. TalkBack announces pages and cells with Vertical Flatlist in the Paper Renderer ([link][2])
[3]. `FlatList numColumns={undefined}` Should not trigger Runtime Error NoSuchKey exception columnCount when enabling TalkBack. ([link][3])
[4]. TalkBack announces pages and cells with Nested Horizontal Flatlist in the rn-tester app ([link][4])

[1]: https://github.com/fabriziobertoglio1987/react-native-notes/issues/6#issuecomment-1050452894
[2]: https://github.com/fabriziobertoglio1987/react-native-notes/issues/6#issuecomment-1050462465
[3]: https://github.com/fabriziobertoglio1987/react-native-notes/issues/6#issuecomment-1032340879
[4]: https://github.com/fabriziobertoglio1987/react-native-notes/issues/6#issuecomment-1050618308
[10]:https://github.com/aosp-mirror/platform_frameworks_base/blob/1ac46f932ef88a8f96d652580d8105e361ffc842/core/java/android/widget/AdapterView.java#L1027-L1029 "GridView.java method responsible for calling setFromIndex and setToIndex"
[11]:https://github.com/fabriziobertoglio1987/react-native-notes/issues/6#issuecomment-1042518901 "test case on Android GridView"
[12]:https://github.com/fabriziobertoglio1987/react-native-notes/issues/6#issuecomment-1050452894 "TalkBack announces pages and cells with Horizontal Flatlist in the Paper Renderer"
[13]:https://github.com/intergalacticspacehighway "github intergalacticspacehighway"
[14]:https://github.com/fabriziobertoglio1987/react-native/blob/80acf523a4410adac8005d5c9472fb87f78e12ee/Libraries/Lists/FlatList.js#L617-L636 "FlatList accessibilityCollectionItem"
[16]:https://github.com/fabriziobertoglio1987/react-native/blob/5706bd7d3ee35dca48f85322a2bdcaec0bce2c85/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java#L183-L184 "logic added to ReactScrollView.java"
[17]: https://github.com/facebook/react-native/issues/30977
[18]: https://github.com/fabriziobertoglio1987/react-native-notes/issues/6
[19]: https://github.com/facebook/react-native/pull/31666
[20]: https://reactnative.dev/docs/next/flatlist#required-renderitem "FlatList renderItem documentation"
[21]: https://github.com/fabriziobertoglio1987/react-native/commit/75147359c5d070406ebbe488c57c3cd94c08c19d "commit that introduces fourth param accessibilityCollectionItem in callback renderItem"
[22]: https://github.com/facebook/react-native/pull/33180#discussion_r826748664 "discussion on the additional container View around each FlatList cell"
[23]: https://github.com/fabriziobertoglio1987/react-native/commit/d50fd1a68112f40f4be3ac3aa4d67f96df33e387 "commit adding prop getCellsInItemCount to VirtualizedList"

Reviewed By: kacieb

Differential Revision: D34518929

Pulled By: blavalla

fbshipit-source-id: 410a05263a56162bf505a4cad957b24005ed65ed
2022-04-19 19:45:10 -07:00
Luna Wei 361b9a808c PointerEvents: Reset childHandlingNativeGesture on first ACTION_DOWN
Summary:
Changelog: [Internal] - Reset the mChildHandlingNativeGesture on the first ACTION_DOWN after it's been set.

I noticed this issue when scrolling sometimes in the event log for the W3CPointerEvents example, none of the pointer events would get captured because we'd call [`notifyNativeGestureStarted`](https://www.internalfb.com/code/fbsource/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/events/NativeGestureUtil.java?lines=25-25) which would prevent any pointerevents being fired.

Reviewed By: vincentriemer

Differential Revision: D35685378

fbshipit-source-id: 01fc255afc5e22dc6c42f7eb11a8aa5a9a091b87
2022-04-19 15:22:00 -07:00
Brett Lavalla 70fcab76a4 Fix RN accessibility links with UIAutomator
Summary:
D34687371 (https://github.com/facebook/react-native/commit/7b5b114d578142d18bf4a7a5279b179a9ac8d958) unfortunately caused a regression with UIAutomator, where it would no longer be able to see any Views that have the ReactAccessibilityDelegate attached to them. This was because the delegate was changed to extend ExploreByTouchHelper which implements its own default AccessibilityNodeProvider, which does nothing in the case of a view without any virtual children.

This diff simply *only* uses the node provider if the view in question has virtual children, otherwise defaulting to the standard behavior from the View class.

Changelog:
[Android][Fixed] - Fixed issue where any node with an AccessibilityDelegate set (which was any node with any accessibility propoerty), was using ExploreByTouchHelper's built in AccessibilityNodeProvider, and not properly populating their AccessibilityNodeInfo's, leading to focus issues and issues with automated test services like UIAutomator.

Reviewed By: kacieb

Differential Revision: D35601320

fbshipit-source-id: 92e009c6e8b4ddcab860e2c91e6bd1a8f95359f0
2022-04-13 16:05:29 -07:00
Vladyslav Stepanov 86f8d0bb52 Fix Android implementation for Linking.sendIntent()
Summary:
Changelog:
[Android][Fixed] - Fix Extras usage in Android implementation of Linking.sendIntent()

The implementation of sendIntent() has a bug in a way it uses extras map.

From JS layer the API sends and array of map, where each map contains exactly 2 entries: {"key" -> "name_of_extra_to_use", "value" -> value_of_extra_to_use}

However Java parsing was just picking a random pair out of this map and was sending it as extra.

Most frequently the result was "value" -> value_of_extra_to_use in Intent instead of name_of_extra_to_use -> value_of_extra_to_use

This diff fixes the problem

Reviewed By: lunaleaps

Differential Revision: D35516496

fbshipit-source-id: 7da0a1cb3b8aa30463004dbb47008c83d8e95bd1
2022-04-12 16:35:40 -07:00
David Vacca fbeb51ef51 Fix NullPointerException when disaptching events
Summary:
This diff fixes a NullPointerException when disaptching events while the SurfaceMountingManager is being destroyed

changelog: [android] android

Reviewed By: cortinico

Differential Revision: D35559550

fbshipit-source-id: c07f74493384fb1b306338ec1bc8b96f1b6f1f41
2022-04-12 12:18:14 -07:00
Luna Wei de09bd3b84 Dispatch enter/leave for ancestor hit path
Summary: Changelog: [Internal] - Fix pointer event dispatch to also fire enter/leave for ancestors in the hit path. Compared the event order with web on the RNTester W3C pointer example

Reviewed By: appden

Differential Revision: D35403076

fbshipit-source-id: 726e45e49a901b1d97ad3e20f5898701fd1f763b
2022-04-11 17:17:10 -07:00
Marces Engel dac56ce077 fix: Android headless JS timeout (#33044)
Summary:
Fixes https://github.com/facebook/react-native/issues/33043 and thereby https://github.com/invertase/react-native-firebase/issues/3955.

The issue arised because when there currently is no available React context, `HeadlessJsTaskService` will create a new one in background and start the task using `onReactContextInitialized` of `ReactInstanceManager.addReactInstanceEventListener`.
https://github.com/facebook/react-native/blob/7ef14af81f3a1532ca1a703da666ea2e5a70a265/ReactAndroid/src/main/java/com/facebook/react/HeadlessJsTaskService.java#L94-L113
The `TimingModule` however is initialized asynchronously, meaning the headless JS is started before its initialization. That's an issue because the `TimingModule` is only run when there is JS code executing (meaning if the application is running or there is a headless task running) - this is checked by registering a `HeadlessJsTaskEventListener` on the `HeadlessJsTaskContext` in `TimingModule.initialize()`.
https://github.com/facebook/react-native/blob/7ef14af81f3a1532ca1a703da666ea2e5a70a265/ReactAndroid/src/main/java/com/facebook/react/modules/core/TimingModule.java#L69-L75
However this event listener is never invoked because the task was started before `TimingModule.initialize()` is called -> `TimingModule.onHeadlessJsTaskStart(...)` is not called and the timer never resumes.

In order to fix this we can just invoke `HeadlessJsTaskEventListener.onHeadlessJsTaskStart(...)` for all currently running tasks when a new listener is added to `HeadlessJsTaskContext`. This call then needs to be `synchronized` as otherwise there's a race condition with `HeadlessJsTaskContext.finishTask(...)` where `onHeadlessJsTaskFinish(...)` could be called before `onHeadlessJsTaskStart(...)`. See the diff for the exact changes.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Android] [Fix] - Fixed `TimingModule` related functions for headless JS tasks, eg. `setTimeout`

Pull Request resolved: https://github.com/facebook/react-native/pull/33044

Test Plan: I did a local build with the changes and tested the provided example code from https://github.com/facebook/react-native/issues/33043 there.

Reviewed By: sshic

Differential Revision: D34006573

Pulled By: dmitryrykun

fbshipit-source-id: d6a821bbd6476ba278c1d8895edb4a0ba16d889e
2022-04-11 06:58:37 -07:00
Nicola Corti bfc39353d1 Do not specify a Kotlin version in the RN rootProject (#33589)
Summary:
As we introduced KGP inside `ReactAndroid` (cc ShikaSD), we now need to specify a version for it (as users will consume that build on Android New Architecture.

Currently, the version is loaded in the RN `rootProject` which is not available on user's project. I'm cleaning this up.

## Changelog

[Internal] - Do not specify a Kotlin version in the RN rootProject

Pull Request resolved: https://github.com/facebook/react-native/pull/33589

Test Plan:
Tested on a nightly version with

```
npx react-native init RNNightly --version nightly
```

Reviewed By: mdvacca

Differential Revision: D35476777

Pulled By: cortinico

fbshipit-source-id: 5a819ef5fa9a6886d7b7b683f31d59cb05a49f29
2022-04-08 03:44:56 -07:00
Nicola Corti c5babd993a Improve support for Android users on M1 machine
Summary:
This is a follow up to my previous diff. It applies the same customization for M1 users to the :ReactAndroid:hermes-engine build.

The two diffs are split so the first one can be cherry-picked into 0.68.1 if needed.

Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine

Reviewed By: mdvacca

Differential Revision: D35468658

fbshipit-source-id: c07822f6708f872456971378f44257f6c1e967ee
2022-04-07 10:55:32 -07:00
Nicola Corti 4befd2a29c Improve support for Android users on M1 machine (#33588)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33588

Currently users on M1 machine can't use the New Architecture correctly as they will get build failures when building the native code.

This Diff fixes it by automatically recognizing the host architecture and switching to NDK 24 if user is runnign on `aarch64`

Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine

Reviewed By: mdvacca

Differential Revision: D35468252

fbshipit-source-id: b73f5262b9408f04f3ae4fd26458a4d17c1ec29a
2022-04-07 10:55:32 -07:00
Lorenzo Sciandra 5cd6367f0b Bump boost for Android to 1.76 to align with iOS + fix (#33565)
Summary:
The reason why I'm working on this is to reduce the delta between this and the react-native-macos fork, in particular with the android patch folder "Build": https://github.com/microsoft/react-native-macos/tree/main/android-patches/patches/Build (it's a long story)

While checking the changes in there, I noticed that one of them was a bump of boost. Looking back into main (here), I then noticed that there have been two bumps to boot in the repo so far:
* a combo update 5 years ago to 1.63:
  * https://github.com/facebook/react-native/commit/193afff92620621b5f2ca2702acf06de0b5090ec
  * https://github.com/facebook/react-native/commit/5c24a9110aa1602430eff199d05421e2eb660416
* and an update for the iOS side to 1.76 by Kudo last year: https://github.com/facebook/react-native/pull/31840

So this quickly turned into this: the PR wants to re-align the version of boost used in both iOS and Android.

I explored the option of bumping both to 1.78 (latest at the time of writing: https://www.boost.org/users/history/version_1_78_0.html) but then I noticed that there's a Flipper dependency, `Flipper-Boost-iOSX`, on the iOS pods side that has been released only once and it seems to imply that it's 1.76 only compatible https://github.com/priteshrnandgaonkar/Flipper-Boost-iOSX/releases/tag/1.76.0.1.11.

So going to 1.78 at least for now seems like a no-go, and I've settled for just aligning everything to 1.76 and just like iOS, move away from `boost-for-react-native` in favour of the original one.

While doing so, I also noticed that the `React/third-party.xcconfig` still had a reference to 1.68 instead of 1.76 which seems like a leftover from Kudo's PR... it's probably because it was not doing anything in the first place, so lmk if you want me to delete it.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Android] [Changed] - Bump boost for Android to 1.76 to align with iOS

Pull Request resolved: https://github.com/facebook/react-native/pull/33565

Test Plan:
CI is green (aside an unrelated ios rntester job that is also broken on main) 
Locally both RNTester and new app work:
<img width="432" alt="Screenshot 2022-04-05 at 16 42 31" src="https://user-images.githubusercontent.com/16104054/161815444-0de63919-b90d-4a48-963a-872f0cc4ce79.png">

<img width="346" alt="Screenshot 2022-04-05 at 18 06 01" src="https://user-images.githubusercontent.com/16104054/161815438-b7b1c997-9dcd-47bd-acbe-732155941bb0.png">

Reviewed By: sshic

Differential Revision: D35433032

Pulled By: cortinico

fbshipit-source-id: 0d93f61f8c26eda1dd04127a8b20e799ab6828cb
2022-04-07 04:50:30 -07:00
Nicola Corti b2bc5aa5c9 Do not use rootProject directly in Gradle scripts
Summary:
While testing with the RN Nightly versions, I realized we pushed two changes
recently that are not working fine with the gradle setup of our users.

That's becuase we're referencing the `rootProject` directly.
`rootProject` should never be used directly as it resolves to:
- The root of the git repo of `react-native` when building the RN project (so
  `./ReactCommon` exists there).
- The /android folder of users' project when building an app that uses RN (so
  `./ReactCommon` does not exists there).

Changelog:
[Android] [Fixed] - Do not use `rootProject` directly in Gradle scripts

Reviewed By: sshic

Differential Revision: D35444967

fbshipit-source-id: be0508480a08224302168804b6feb52fd604d8db
2022-04-07 04:48:40 -07:00
Christoph Purrer a196e22bc8 Allow ReactInstrumentationTest to use TurboModulues
Summary:
Update ReactInstrumentationTest to allow passing in a ReactPackageTurboModuleManagerDelegate.Builder

Changelog:
Internal

Reviewed By: RSNara

Differential Revision: D35349451

fbshipit-source-id: 940da345524eecb2645104ac29508c66134162e2
2022-04-05 19:57:59 -07:00
Chris Olszewski daa105aba5 Fixup typo in pfh labels
Summary:
Now that the PFH node has been renamed this updates the pfh label.

Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`

Reviewed By: jkeljo

Differential Revision: D35374087

fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
2022-04-05 12:15:05 -07:00
Nicola Corti 1e51ac2b6c Setup multi-variant publishing for React Native Android (#33539)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33539

As we now provide `hermes-executor-debug` OR `hermes-executor-release` based on which version of RN we're building, we need to provide a variant aware AAR.

Changelog:
[Internal] [Changed] - Setup multi-variant publishing for React Native Android

Reviewed By: ShikaSD

Differential Revision: D35289444

fbshipit-source-id: ffccd2089dc2eb50ea8c08ed10d8fd9816f9efb7
2022-04-05 09:38:55 -07:00
Neil Dhar 6f26a920a7 Enable ICF and LTO (#33560)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33560
X-link: https://github.com/facebook/hermes/pull/720

Turn on ICF for the build whenever it is available. This requires us to
link with LLD, which is only the default starting in NDK r23, so
manually specify LLD for the Android build.

Also turn on LTO for the CircleCI build, so we generate highly
optimised binaries for distribution.

Changelog: [Internal]

Reviewed By: jpporto

Differential Revision: D35344254

fbshipit-source-id: 64b37e6a7817a7b7826cc7480468367b95d63c61
2022-04-04 20:32:58 -07:00
Neil Dhar aefb17421b Always enable debugger by default
Summary:
We currently enable the debugger by default on all platforms except
Android. On Android, we then manually enable the debugger in debug
builds. Instead, change it so the debugger is manually disabled in
release builds, to simplify the setup.

Changelog: [Internal]

Reviewed By: jpporto

Differential Revision: D35347444

fbshipit-source-id: a97bba0c65c61c211cf9e361e7091343a2c6416f
2022-04-04 15:47:29 -07:00
Neil Dhar 68fd7de115 Directly invoke CMake when compiling Hermes
Summary:
Changelog: [Internal]

Working towards removing configure.py, switch to invoking CMake directly.

Note that with this change, ninja is no longer a requirement, since it will use the default build system on the host.

Reviewed By: cortinico, jpporto

Differential Revision: D35342731

fbshipit-source-id: f04a367bda9fb22642f17e7c2c5cf493e44013d3
2022-04-04 15:47:29 -07:00