Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52407
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
Reviewed By: javache
Differential Revision: D77765443
fbshipit-source-id: 112fef4c1a7e1c567f3c1d471728a1dfc926adc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52388
Changelog: [Internal]
Similar to `AsyncCallback<>` (the foundation of `AsyncPromise`) we should allow `void` Promise types in C++ such as `AsyncPromise<>`
Reviewed By: rbergerjr
Differential Revision: D77712020
fbshipit-source-id: d7360df5cc1b77f1e03e5fb73b0b468f6e3a415b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52456
Remove the last use of a Metro deep import in preparation for making all deep imports semver-private.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D77450110
fbshipit-source-id: de7aa9c1f6b0d281fe8a6c3bd95e721c5bb58c63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52438
Motivation: After some investigation, these make sense as private APIs, and we intend to modify `UriHandler` slightly in order to report blob response body payloads via CDP for Network debugging.
Changelog:
[Android][Removed] - Internalize `NetworkingModule`'s `UriHandler`, `RequestBodyHandler`, and `ResponseHandler` APIs
Reviewed By: cortinico
Differential Revision: D77799144
fbshipit-source-id: 20c36f52a900830091a253ab9917832c30b31d31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52436
Reordered the different property types in the switch/case to group similar outputs together.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D77799101
fbshipit-source-id: 5b7c6d188e9ffa0f1e41f44f82f438afeda04d74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52439
Users should not be passing true/false values for the 3 params in the `load()` method. The app template already uses the no param overload.
I'm deprecating it so it can go in 0.81.
Changelog:
[Android] [Changed] - Deprecate the DefaultNewArchitectureEntryPoint.load(Boolean, Boolean, Boolean)
Reviewed By: rubennorte
Differential Revision: D77739268
fbshipit-source-id: c901d1ed2e9623b0fa39f4e2d79f25404c284b8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52427
Adds and wires up a minimal implementation of `PerformanceResourceTiming` on the JS side. This materialises D74245441 in user space.
When all feature flags are enabled, network requests can now be observed from JS via `PerformanceObserver`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D75062713
fbshipit-source-id: 06523e70f57feaaa53432ef21fa92676d1e90360
Summary:
reverting Refactor ViewManagerInterfaces codegen to generate kotlin classes because of warning in OSS, we will reland after 0.81 cut
Changelog: [Android][Breaking] - Revert of Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: lenaic, mlord93
Differential Revision: D77759777
fbshipit-source-id: c24b216b231cdc53296d8c9fca8d789d80daa596
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52393
## Changelog:
[General][Deprecated] - ShadowNode::Shared is now deprecated. Use `std::shared_ptr<const ShadowNode>` instead.
- Mark ShadowNode::Shared as deprecated in ShadowNode.h
- Replace all uses of ShadowNode::Shared with std::shared_ptr<const ShadowNode>.
This continues the systematic effort to remove ShadowNode type aliases in favor of explicit standard library types for improved code clarity and maintainability.
Reviewed By: christophpurrer
Differential Revision: D77650696
fbshipit-source-id: b4769e2a1e39f49d14d5927be105487ecf69fa3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52405
This field has been deprecated since RN 0.77, we can safely remove it ahead of the branch cut.
Changelog:
[Android] [Removed] - Remove deprecated `isStartSamplingProfilerOnInit` from `DeveloperSettings`
Reviewed By: mdvacca, javache
Differential Revision: D77734913
fbshipit-source-id: 231ecb360921d48ec941a3a214e73b4b89446c13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52395
This method was exposed as `public` but there is no need for us to expose it in OSS.
So I'm marking it as internal.
Changelog:
[Internal] [Changed] - Make loadWithFeatureFlags correctly internal
Reviewed By: mlord93, mdvacca, javache
Differential Revision: D77734270
fbshipit-source-id: 34e1d7aaa4a5bf3563c78aad570e2310592bcc77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52382
Changelog: [Internal]
In C++, both `virtual ~CallInvoker() {}` and `virtual ~CallInvoker() = default` can be used to define a virtual destructor. However, they have slightly different implications:
1. `virtual ~CallInvoker() {}`:
* This is the traditional way of defining a virtual destructor.
* It provides an empty implementation for the destructor, which does nothing.
* The compiler will not generate a default implementation, as you've provided one explicitly.
2. `virtual ~CallInvoker() = default`:
* This is a more modern way of defining a virtual destructor (introduced in C++11).
* It tells the compiler to generate a default implementation for the destructor.
* The default implementation will perform the necessary cleanup operations, such as calling the destructors of base classes and member variables.
In general, `= default` is considered better because it:
* Avoids unnecessary code duplication: By letting the compiler generate the default implementation, you avoid duplicating code that's already generated by the compiler.
* Improves maintainability: If the class has member variables or base classes with non-trivial destructors, using `= default` ensures that the correct cleanup operations are performed without requiring manual updates.
* Conveys intent: Using `= default` clearly indicates that the destructor should perform its default behavior, making the code easier to understand.
So, unless you have a specific reason to provide a custom implementation, `virtual ~CallInvoker() = default` is generally the better choice.
Reviewed By: rshest
Differential Revision: D77685932
fbshipit-source-id: 78c81f8e400069ad38d8d7405dafeb0b6db8e67b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52347
We can build an accessibility tree for Talkback by overriding addChildrenForAccessibility of ViewGroup.
With this we just manually build a tree that contains the elements we care about in the order we want.
We also try to keep most of the tree intact so that coopting works properly
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77258926
fbshipit-source-id: 767ebc880a2efbf7934b9e7dee3013dd7822e5ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52297
Doing virtual views is the only way of making it possible to add the host view into the order. This however is too complex for very little gain, we are opting to go for a cleaner solution with the trade off of not being able to add the host view.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77278752
fbshipit-source-id: 709b995f51a9a03f6d07f2e24f8aea21d62d95c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: javache
Differential Revision: D75719542
fbshipit-source-id: 7e9aa7ccc24e827bd7b6df72b3302e852932e731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52400
`react-stack-bottom-frame` -> `react_stack_bottom_frame`.
This survives `babel/plugin-transform-function-name`, but now frames
will be displayed as `at Object.react_stack_bottom_frame (...)` in V8.
Checks that were relying on exact function name match were updated to
use either `.indexOf()` or `.includes()`
For backwards compatibility, both React DevTools and Flight Client will
look for both options. I am not so sure about the latter and if React
version is locked.
DiffTrain build for [91d097b2c588a0977a7a10ed12512dc8a34e3a5b](https://github.com/facebook/react/commit/91d097b2c588a0977a7a10ed12512dc8a34e3a5b)
Reviewed By: jackpope
Differential Revision: D77601866
fbshipit-source-id: 24ed8713af4bebbaeb7a612333cd79c51b696565
Summary:
This PR (initially created for edge-to-edge opt-in support, rebased multiple times) fixes the `Dimensions` API `window` values on Android < 15, when edge-to-edge is enabled.
Currently the window height doesn't include the status and navigation bar heights (but it does on Android >= 15):
<img width="300" alt="Screenshot 2025-06-27 at 16 23 02" src="https://github.com/user-attachments/assets/c7d11334-9298-4f7f-a75c-590df8cc2d8a" />
Using `WindowMetricsCalculator` from AndroidX:
<img width="300" alt="Screenshot 2025-06-27 at 16 34 01" src="https://github.com/user-attachments/assets/7a4e3dc7-a83b-421b-8f6d-fd1344f5fe81" />
Fixes https://github.com/facebook/react-native/issues/47080
## Changelog:
[Android] [Fixed] Fix `Dimensions` `window` values on Android < 15 when edge-to-edge is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/47554
Test Plan:
Run the example app on an Android < 15 device.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77547628
Pulled By: alanleedev
fbshipit-source-id: 9d841f642d5b7ef3294dfbf3868137087a672ad6
Summary:
We need to upgrade the targetSdk to 36, which requires ensuring compatibility with the latest Android APIs and addressing any deprecations or behavior changes introduced in this version.
## Changelog:
[Android] [Changed] - Updated targetSdk to 36 in Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/52355
Test Plan:
- Verified that the app builds and runs successfully with targetSdkVersion 36.
- Ran the full suite of unit and instrumentation tests: all tests passed.
- Manually tested key user flows (login, navigation, data sync) on devices running Android 14 (API 34) and emulator with API 36
- Confirmed that there are no runtime crashes or warnings related to `targetSDK` upgrade.
Behavioral guide for migration: https://developer.android.com/about/versions/16/behavior-changes-16
Reviewed By: fabriziocucci
Differential Revision: D77728391
Pulled By: cortinico
fbshipit-source-id: 3f714f900bbeecc56c0cf46c54b4e42c532c8384
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52335
Adds support for `Network.requestWillBeSentExtraInfo` and `Network.dataReceived` CDP events in jsinspector-modern and wires up for iOS.
In particular, `Network.requestWillBeSentExtraInfo` is necessary to populate request headers in the UI.
**End of base Network implementation for iOS**
After this diff, we are spec-complete on all CDP Network methods for our V1, on iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489476
fbshipit-source-id: 84aa4da9d9fcbdc61eff236fc6bd2136496910a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52334
Adds support for `Network.loadingFailed` in jsinspector-modern and wires up for iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489477
fbshipit-source-id: dc8156979fe49583819019fa4b88b6eb99dea734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52331
Updates the iOS inputs to `NetworkReporter` to support incremental string data HTTP responses (`Transfer-Encoding: chunked`).
This means that incremental responses, such as Metro bundle requests, can be displayed as previews in React Native DevTools.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77457109
fbshipit-source-id: 00a622dbac97c38e07c67b5ee3661c8d586f6fe1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52332
Adds support for the [`Network.getResponseBody`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBody) CDP event in `jsinspector-modern` and configures this for iOS. This enables us to populate the "Preview" and "Response" tabs in the React Native DevTools Network panel.
This is integrated with `RCTNetworking.mm` to support synchronously received `text` or `blob` data types, with incremental response support added next in D77457109.
**Implementation notes**
- Adds a new `BoundedRequestBuffer` construct to safely buffer response previews at a max memory size.
- `RCTNetworking` will always call `maybeStoreResponseBody` (when feature flag enabled), but is unaware whether there is an active CDP debugging session with network support or not.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D74319394
fbshipit-source-id: c9dbb44551c15d1b1a7cce56b35bf829f8a99dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52380
Apps that rely support focus in FlatList rendered items are missing out on a FlatList optimization that defers rendering for offscreen content updates.
For example, on Android, if you focus and smooth scroll an item into view, the onScroll event will fire first. For most sufficiently large virtualization windows, the next render will be delayed by the render batch timeout as most materialization of virtualized views is not treated as a high pri render.
However, this batch / timeout mechanism isn't being used for cell render updates that occur as a result of a focus change.
This change adds the same timeout mechanism used for scroll events. In most cases, the view that is focused is in the viewport, and the extra rendering needed is already scheduled (or executed with high priority if needed) when the onScroll event is processed.
In cases where the focus change occurs outside the viewport, most platforms will want to do some kind of "bring into view" anyway, and the same applies - onScroll will take care of scheduling the cell rendering priority.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D77681274
fbshipit-source-id: 1ade377e513eca21338a380ff9299dd410606aec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52358
Another class going from Java to Kotlin.
This is quite involved due to the amount of Raw generics we were using so I'd appreaciate a couple of further eyes here.
Changelog:
[Android] [Changed] - Convert UIManagerModuleConstantsHelper to Kotlin
Reviewed By: mdvacca, javache
Differential Revision: D77589975
fbshipit-source-id: 477c1e2a8dfd31db60047fd1252f6d47c177f5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52378
This adds a Gradle property called `exclusiveEnterpriseRepository`
that users can set in their `android/gradle.properties` as such:
```diff
# Use this property to enable or disable the Hermes JS engine.
# If set to false, you will be using JSC instead.
hermesEnabled=true
+exclusiveEnterpriseRepository=https://my.internal.proxy.net/
```
This will remove all the existing Maven repositories and only use the internal mirror they have.
Changelog:
[Android] [Added] - RNGP - Add support for `exclusiveEnterpriseRepository` to specify an internal Maven mirror.
Reviewed By: mdvacca
Differential Revision: D77667573
fbshipit-source-id: 835004d2ae7aa4e250b6f7a88a41918b573f5bd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52387
I would like to grab this in a subclass but unfortunately can't. It is kinda jank since this is a val obtained via reflection, but I figure this is better than copy and paste. I think that I could also expose a function that uses this scroller the way I want it to. Let me know if there are strong objections here
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D77684599
fbshipit-source-id: 6f02c1da5135c1cf34fa1483542e06bf8f0be75e
Summary:
This change fixes an issue on iOS where gradients that fade to a transparent color-stop appear dark or "muddy." The fix ensures that the color's hue is preserved during the transition, matching the behavior on Android and web.
### The Problem
When creating a gradient on iOS (e.g., linear-gradient(red, transparent)), the transparent keyword is treated as transparent black (rgba(0,0,0,0)). The `CAGradientLayer` on iOS then interpolates all color channels linearly, causing the red, green, and blue components of the start color to fade to 0. This transition through black results in an undesirable dark or "muddy" appearance in the middle of the gradient.
## Changelog:
[IOS][FIXED] - Gradient interpolation for transparent colors
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52249
Test Plan:
Checkout `LinearGradient` example in RNTester, checkout the newly added transparent color transition example, it should render same on android and iOS.
| Before | After |
| --- | --- |
| <img src="https://github.com/user-attachments/assets/c0bb54ad-ed0e-4a80-b37f-0458af0f1f77" width="300"> | <img src="https://github.com/user-attachments/assets/02da921a-bd0e-45c1-881c-cf6460d5ed43" width="300"> |
| `linear-gradient(to right, red, transparent)` transitions to black on iOS, creating a dark effect. | The gradient correctly fades the red color's alpha channel to zero |
Reviewed By: javache
Differential Revision: D77312194
Pulled By: NickGerleman
fbshipit-source-id: 053df8e44f52cd22a3f28fd01f583f7d03c66af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52386
Enum `values()` function makes a copy of an underlying array on each call. This happens in a hot path, and seems to show up during profiling. Let's cache it.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77623705
fbshipit-source-id: 5a33425822f477f63fe104ca9e5ed474385a2022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52385
This replaces `buildSpannableFromFragmentsOptimized()` with a more optimized version. There are a couple main changes.
1. We don't need a complicated structure around ordering, and span priority, that made its way from the Java ShadowNode logic. AttributedString already ensures there are no overlapping attributes per fragment.
2. `SpannableStringBuilder` is a complicated text-editor style data structure, optimized to allow text content to be modified, and spans re-applied. We can use a much lighter `SpannableString`, on top of the ahead-of-time known text content, which is faster, and saves around 500 bytes per string (and prepared layout). If we assign this to an `EditText`, which later gets edited, Android will copy it to a `SpannableStringBuilder`.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77622848
fbshipit-source-id: 69bbac86e1f0fd4a15dab6bc279cca305f2a53ae
Christoph Purrer
generatedunixname89002005287564
Rob Hogan
Alex Hunt
Nick Lefever
Ruslan Lesiutin
Sam Zhou
Nicola Corti
Samuel Susla
Mohamed Salama
Jorge Cabiedes Acosta
David Vacca
Mathieu Acthernoene
Enrique López Mañas
Eric Rozell
Joe Vilches
nishan (o^▽^o)
Nick Gerleman
Nolan O'Brien