Summary:
This PR follows up on https://github.com/facebook/react-native/issues/47182 and https://github.com/facebook/react-native/issues/47348 by adding `force-cache`, the final missing option to align caching controls with the existing behavior on iOS.
Local caching behavior remains unchanged: if a cached image is available locally, it will be returned; otherwise, a network request will be made.
When an image request is sent over the network, the `force-cache` option sent from the sent fJS side will now use the `okhttp3.CacheControl.FORCE_CACHE` directive.
## Changelog:
[ANDROID] [ADDED] - Image `force-cache` caching control option
Pull Request resolved: https://github.com/facebook/react-native/pull/47426
Test Plan:
New example added to the RNTester under the cache policy examples. Then inspecting that the cache control is set correctly before sending it in the `okhttp3.Request` builder.
```kt
FLog.w("ReactNative", "fetching uri: %s, with cacheControl: %s", uri, cacheControlBuilder.build().toString())
// fetching uri: https:...png?cacheBust=force-cache, with cacheControl: no-store, max-stale=2147483647, only-if-cached
```
This case was a bit more tricky to test in terms of e2e as it would involve some caching in the server as well, I'm open to suggestions to make this more complete.
Reviewed By: javache
Differential Revision: D65490360
Pulled By: Abbondanzo
fbshipit-source-id: f807a9793f85caea39c59a370d057b9a1d450a78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47531
When the activity is paused, or destroyed, we should disable the devsupportmanager. (This performs cleanup).
When the activity is resumed, we should re-enable devsupportmanager. (This performs re-initialization).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65689053
fbshipit-source-id: 99de0906b8cdc84f56b4d334ac0eeecc7b436dd5
Summary:
Follow up from https://github.com/facebook/react-native/issues/47433, adding some missing scenarios in the unit tests for the image component in Android.
## Changelog:
[INTERNAL] [ADDED] - Improving Android `ImageResizeMode` unit tests
Pull Request resolved: https://github.com/facebook/react-native/pull/47527
Test Plan:
```bash
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D65735794
Pulled By: Abbondanzo
fbshipit-source-id: a420274c78d9eadf0439870cfaae4d16247c6034
Summary:
On android the isGrayScaleEnabled method of AccessibilityInfo always returns false due to missing implementation. This PR fills the gap by providing the native module logic for checking grayscale mode.
## Changelog:
- Added native module code to check for grayscale mode on android
- Updated js accessibility info module to return the correct promise instead of default false for isGrayScaleEnabled()
- Moved the test for isGrayScaleEnabled() out of ios scope to common Android and iOS scope
[ANDROID] [ADDED] - logic to check for grayscale mode on android
Pull Request resolved: https://github.com/facebook/react-native/pull/47497
Test Plan:
Tested on :
- Google Pixel 7 Pro (Android 14)
- OnePlus 12 (Android 14)
- Pixel 6 (Android 15)
Reviewed By: cortinico
Differential Revision: D65662583
Pulled By: javache
fbshipit-source-id: 39f9ce37c9375b5380257847395393045eedbadc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47543
TaskCompletionSource is public but it shouldn't, in this diff I'm making it intenral
changelog: [Android][Breaking] Reduce visibility of TaskCompletionSource class
Reviewed By: javache
Differential Revision: D65738324
fbshipit-source-id: 61db35a408162c53398b20e45a52f3eb46de1eae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47540
Continuation is only used inside RN, we should make it internal
changelog: [Android][Changed] Reduce visibility of Continuation to internal, although this interface wasn't being exposed in any public API
Reviewed By: javache
Differential Revision: D65738329
fbshipit-source-id: 6fb1b9e9a253eafad0f6eb1e4c1363d6254846da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47548
changelog: [internal]
This race condition only shows itself with flag `useOptimizedEventBatchingOnAndroid`
# Problem
EventBeat assumes method `induce` will be called repeatedly on every UI tick. This is true for iOS and existing implementation of event beat on Android. The first early exist inside of `induce` method is built with this assumption.
`useOptimizedEventBatchingOnAndroid` on Android changes this. `induce` will only be called after FabricUIManager.onRequestEventBeat is invoked and then it will stop. For one `FabricUIManager.onRequestEventBeat` call, `EventBeat::induce` is called once. And there is a chance for race condition.
Here is a simplified implementation of `induce`. This method may be called many times in sequence. The caller will set [isRequested_](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/renderer/core/EventBeat.cpp#L25) and then invoke [FabricUIManager.onRequestEventBeat](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/jni/react/fabric/AndroidEventBeat.cpp#L43). Notice how `FabricUIManager.onRequestEventBeat` is debounced if `isRequested_` flag is true.
```
void EventBeat::induce() const {
if (!isRequested_ || isBeatCallbackScheduled_) {
// isRequested_ is not set to false in case isBeatCallbackScheduled_) is true.
return;
}
isRequested_ = false;
isBeatCallbackScheduled_ = true;
auto beat = std::function<void(jsi::Runtime&)>(
// on JS queue
isBeatCallbackScheduled_ = false;
// beatCallback_(runtime)
}
runtimeScheduler_.scheduleWork(std::move(beat));
}
```
This can get into a state where `isRequested_` is not reset back to false even though `EventBeat::induce` is called when `isBeatCallbackScheduled_` is true.
`AndroidEventBeat::request` -> `isRequested_` is set to true -> `FabricUIManager::onRequestEventBeat` -> `EventBeat::induce` -> `isRequested_` is set to false -> `isBeatCallbackScheduled_` is set to true -> `AndroidEventBeat::request` -> `FabricUIManager::onRequestEventBeat` -> `EventBeat::induce` (early exit because `isBeatCallbackScheduled_` is true) -> `beat` is executed on the JS thread.
From this point on, subsequent calls to `AndroidEventBeat::request` are always debounced because flag `isRequested_` is true.
Any subsequent event on Android will end up calling `EventBeat::induce` and the mechanism gets unstuck.
# The fix
The fix is simple, any time `EventBeat::induce` is called, make sure `request_` flag is set to false. This then satisfied the expectation of `useOptimizedEventBatchingOnAndroid` optimisation.
Reviewed By: rubennorte
Differential Revision: D65566258
fbshipit-source-id: 5f15da8f5cb722b329f9f72b9ddca8e2cac04144
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47534
This diff is introducing a new method to destroy React instance that allows the caller to be notified when the destroy finishes
This is necessary for apps to act upon destroy of the react instance
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D65721107
fbshipit-source-id: 2d3d9755db38461ba381b86c72df5869c542379b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47383
CatalystInstance is deprecated and will be removed in new architecture
changelog: [Android][Changed] Deprecate CatalystInstance in old architecture
Reviewed By: cortinico
Differential Revision: D65430643
fbshipit-source-id: 96ba91c45760ead8155f9f28b6fad523be75929e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47525
This API is awkward for nullsafe code. Adding an extension allows Kotlin code to use `applyTextTransform()` on either nullable or non-null strings:
```
val a: String = string.applyTextTransform(...)
val b: String? = nullableString?.applyTextTransform(...)
```
Changelog:
[Android][Added] TextTransform ktx
Reviewed By: javache
Differential Revision: D65618709
fbshipit-source-id: 28a0fe61a0eaf27aa9677af39d932982f3b694b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47470
Convert to Kotlin and formalize it being an internal class (some methods were already `protected` in Java)
Changelog:
[Android] [Breaking] - Stable API - Make SwipeRefreshLayoutManager internal
Reviewed By: cortinico
Differential Revision: D65481861
fbshipit-source-id: afc5c624373fbcd3ca2d28b2834d2682de672997
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47478
That's a reland of D65540601
The `UIManager.eventDispatcher` return type is wrong and is causing a breaking change in 0.77
For 0.76 we fixed it in the release branch but we should fix it for good in main as well.
To solve it I had to fix the circular dependency between .bridge and .uimanager.
I wish I could have isolated the .events package better but as everythign is public, any
change we do is going to be a breaking change so I'm being over cautios here.
Changelog:
[Android] [Fixed] - Undo breaking change of UiManager.eventDispatcher return type
Reviewed By: javache
Differential Revision: D65595391
fbshipit-source-id: fc7f6dce78e531c5ec0cc493ed90c0012262b77f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47399
Deletes `unstable_setEnableSyncOnScroll` which we are no longer experirmenting with in React Native.
Changelog:
[Internal] - Deleted `unstable_setEnableSyncOnScroll` on `ScrollView`, which was never part of the React Native Public API.
Reviewed By: tdn120, sammy-SC
Differential Revision: D65449039
fbshipit-source-id: 6608d5ccca477f1da5e0168c4a342cce17014b08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47376
This makes several classes inside `com.facebook.react.views.progressbar` internal:
- ReactProgressBarViewManager
- ProgressBarShadowNode
- ProgressBarContainerView
Those classes should have not been exposed in the first place and users should not depend on them directly.
Marked as Breaking but verified that there are no meaningful usages in OSS.
Changelog:
[Android] [Breaking] - Stable API - Make classes inside `com.facebook.react.views.progressbar` internal
Reviewed By: javache
Differential Revision: D65423290
fbshipit-source-id: dc98fdca996eb648593adb2c32787cbf0d878e3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47472
using ViewManagerDelegates for ReactHorizontalScrollContainerViewManager which extends ReactClippingViewManager will introduce a bug (not updating props that are managed by ReactClippingViewManager)
I'm reverting the migration and we should fix the bug in codegen
This diff is a revert of D65428646
changelog: [internal] internal
Reviewed By: sammy-SC, Abbondanzo
Differential Revision: D65564730
fbshipit-source-id: ff183876321d4d36e51da8f38ff6f381207c7c3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47440
Removing file as it does not seem to be used
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D65457514
fbshipit-source-id: 39efa12176fe65a491fa4285099134f2bf753159
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47457
The `UIManager.eventDispatcher` return type is wrong and is causing a breaking change in 0.77
For 0.76 we fixed it in the release branch but we should fix it for good in main as well.
To solve it I had to fix the circular dependency between .bridge and .uimanager.
I wish I could have isolated the .events package better but as everythign is public, any
change we do is going to be a breaking change so I'm being over cautios here.
Changelog:
[Android] [Fixed] - Undo breaking change of UiManager.eventDispatcher return type
Reviewed By: tdn120
Differential Revision: D65540601
fbshipit-source-id: 4b1f62806baac5f6c3ffdd51b8628ef088447604
Mateo Guzmán
BIKI DAS
Fabrizio Cucci
Alex Hunt
Ramanpreet Nara
oddlyspaced
David Vacca
Samuel Susla
Rubén Norte
Pieter De Baets
Thomas Nardone
Jakub Piasecki
Arushi Kesarwani
Nicola Corti
Alan Lee
Tim Yung
Mathieu Acthernoene
Grace Nichols
Adam Woods-Mccormick