Summary:
While buildling locally, those two warnings pop up.
- ANDROID_LD being unused by the CMake toolchain. I'm removing it.
- The Download task encountering a weak eTag. I'm updating it:
https://github.com/michel-kraemer/gradle-download-task
Changelog:
[Internal] [Changed] - Fix a couple of warnings in the ReactAndroid:hermes-engine build
Reviewed By: dmytrorykun
Differential Revision: D42738919
fbshipit-source-id: 7bd8785ad5b7431d557e2f8c8876b7c3f7294a43
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary: Changelog: [Internal] Infer whether a pointer supports hover or not by presence of events
Reviewed By: vincentriemer, NickGerleman
Differential Revision: D42589958
fbshipit-source-id: aa42affc98ef78ebbf9a6e420684ed098869b905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35897
Fixes https://github.com/facebook/react-native/issues/35894
Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (1e48274223) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.
An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.
From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.
Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events
Reviewed By: christophpurrer
Differential Revision: D42604176
fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Summary:
This removes some unused flags which will cause Yoga to layout every tree twice, then diffing the tree, reporting whether the whole tree is different. This is too expensive to run outside of local experimentation, but we have more nuanced ways to implement the `YGNodeLayoutAffectedByQuirk` I am wanting to add.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D42406917
fbshipit-source-id: b415ed02768f6b59de3a6fa90c60c750d56fd4b0
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35857
It seems like there is an incompatibility between NDK 23 (shipped in 0.71)
and the usage of custom `CMAKE_BUILD_TYPE` we do for Hermes.
Specifically the `-DCMAKE_BUILD_TYPE=Release` we specify for the debug
variant of Hermes is partially ignored by the new Android native build toolchain.
See https://github.com/android/ndk/issues/463 for mentions on how the
toolchains requires CMake 3.20+
As AGP 7.3 defaults to use CMake 3.18 unless specified, and NDK 23 unless specified.
AGP 7.4 defaults to use CMake 3.22 unless specified, and NDK 23 unless specified.
See: https://developer.android.com/studio/releases/gradle-plugin#7-4-0
Here I'm:
1. Bumping the docker image to an image that contains the CMake 3.22
2. Updating the logic for building `react-native` & `hermes-engine` to use 3.22
3. Provide fallbacks if the user specified `CMAKE_VERSION`
Template tests will run on AGP 7.3 and will still use CMake 3.18, but I forecast
no problem there as the user is not supposed to specify custom `CMAKE_BUILD_TYPE`.
This is only a problem as we build `hermes-engine` with custom build types.
Changelog:
[Android] [Fixed] - Bump CMake to 3.22.1 to properly honor CMAKE_BUILD_TYPE
Reviewed By: cipolleschi
Differential Revision: D42544864
fbshipit-source-id: efd0f51120370fb808337c201df31d71f4ddfdbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35851
Yoga moved away from fbjni, to use vanilla JNI. This removes fbjni, and proguard annotations (see last stack) as Yoga dependencies from the OSS RN Buck build.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42538671
fbshipit-source-id: c940d370d9d34bdb905c5dc9331e0bd57b5d49db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35841
X-link: https://github.com/facebook/litho/pull/928
X-link: https://github.com/facebook/yoga/pull/1216
The Yoga JNI bindings use Reflection, so we need to let ProGuard know not to strip certain annotated fields.
This is done internally using a single copy of `com.facebook.proguard.annotations` from fbandroid (sometimes), which is then repackaged externally, and published as its own whole Yoga specific package. We never actually inform the stock Gradle project of the rules for the annotations though, so apps must add these manually.
This simplifies the setup, where Yoga has its own self-contained annotations/rules. The rules are exposed for Gradle/Buck dependencies, but RN and Litho both consume Yoga via dirsync + custom Gradle logic, so we need to duplicate the proguard rules to them instead of them being propagated automatically.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D42406641
fbshipit-source-id: c2b12fd498f93f144e5651917ca878d2a5050e08
Summary:
Fixes https://github.com/facebook/yoga/issues/850https://github.com/facebook/yoga/issues/850 describes a conformance issue where positioning of an absolute child using percentages is not calculated against the correct box size.
This takes the fix for that in https://github.com/facebook/yoga/pull/1028, regenerates tests, and fixes tests so that the experimental feature can be enabled. Goal is to run this as an experiment internally to see if we can enable by default.
Changelog:
[Internal]
X-link: https://github.com/facebook/yoga/pull/1201
Reviewed By: yungsters
Differential Revision: D42282358
Pulled By: NickGerleman
fbshipit-source-id: 57c0dd9b0f1c47cb9335ff6e13d44b4646e5fa58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35789
Changelog: [Internal]
This diff is reverting D41069547 (fee9510b2d) D41062668 (4c40014d43) D40984397 (05968d16e1)
D40984397 (05968d16e1) has been identified to be causing the following test or build failures:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
allow-large-files
Differential Revision: D42371475
fbshipit-source-id: daa01c9215811c397f5cef958fd4620f36295b60
Summary:
This PR implements logical border-radius as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `borderEndEndRadius`, equivalent to `borderBottomEndRadius`.
- `borderEndStartRadius`, equivalent to `borderBottomStartRadius`.
- `borderStartEndRadius`, equivalent to `borderTopEndRadius`.
- `borderStartStartRadius`, equivalent to `borderTopStartRadius`.
## Changelog
[GENERAL] [ADDED] - Add logical border-radius implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/35572
Test Plan:
1. Open the RNTester app and navigate to the `RTLExample` page
2. Test the new style properties through the `Logical Border Radii Start/End` section
https://user-images.githubusercontent.com/11707729/206623732-6d542347-93f9-40da-be97-f7dcd5f66ca9.mov
Reviewed By: necolas
Differential Revision: D42002043
Pulled By: NickGerleman
fbshipit-source-id: a0aa9783c280398b437aeb7a00c6eb3f767657a5
Summary:
With the current implementation, it's possible to get a reference to the list of view managers while it's being populated, which in some cases results in `ConcurrentModificationException` thrown [here](9c57a7f209/ReactAndroid/src/main/java/com/facebook/react/uimanager/UIManagerModuleConstantsHelper.java (L80)). This PR updates the logic, so the reference to the list is updated (and returned) only when it's ready.
## Changelog
[ANDROID] [FIXED] - Fix possible `ConcurrentModificationException` in `UIManagerModuleConstantsHelper::createConstants`
Pull Request resolved: https://github.com/facebook/react-native/pull/35770
Reviewed By: cortinico
Differential Revision: D42342107
Pulled By: rshest
fbshipit-source-id: 8d799535c811edeefa1903fbf7a46bff22691e59
Summary:
This diff fixes accessibility value setter in BaseViewManager.java when the accessibility value is null. This is needed when we reset the value and would like to make sure the content description reflects the expected state, instead of the stale state when the value is set last time.
Changelog:
[Android][Fixed] - Reset accessibility value when it gets a null value
Reviewed By: NickGerleman
Differential Revision: D42160904
fbshipit-source-id: a8115a268461c8340d38350ab6fd3f21e4b14959
Summary:
- there was a bug when `contentOffset` was set to {x:0, y:0} and there were items lazy loaded in with prop changes- the View would consistently scroll back to the top after loading in new items
- to avoid this, we store the offset value when it's first set, and only run the `scrollTo` logic then
Changelog:
[Internal][Fixed] - Fix contentOffset forcing scroll to top behavior
Reviewed By: fkgozali, mdvacca
Differential Revision: D42089871
fbshipit-source-id: 3968d98341728a45bec28e8783c9977e91dd4d2c
Summary:
Fixes incorrect logging that I found whilst debugging
## Changelog
[Android] [FIXED] - Fixed incorrect logging of `isCatalystInstanceAlive` in exception handler
Pull Request resolved: https://github.com/facebook/react-native/pull/35708
Test Plan: N/A as change is related to logging
Reviewed By: christophpurrer
Differential Revision: D42233178
Pulled By: robhogan
fbshipit-source-id: f48e5abc036393a40f836cf0bf8c1d69f03ca848
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35743
Changelog:
[Android][Added] - For supporting Dev Loading View across multiple platforms, altering the javascript implementation of Loading view of android to also rely on native implementation as iOS instead of Toast, thereby unifying both platforms
Reviewed By: rshest
Differential Revision: D42258041
fbshipit-source-id: 1be56c1e5696b1024ba09a0aa11da96e0a08f210
Summary:
[Changelog][Internal]
Both iOS and Android platforms are at this point using the same native implementation of `performanceNow`, based on `std::chrono` (it used to be different some time ago).
This diff unifies the implementations, so it comes from one place in C++ code for all platforms.
The context is that I am developing event timing instrumentation and need a consistent way to get current timestamp from either JS or native (C++) side. The latter is now possible via calling `JSExecutor::performanceNow()`, which is guaranteed to be the same as called from JS.
Reviewed By: christophpurrer
Differential Revision: D42267898
fbshipit-source-id: dcb592f37d6567340ea59faddbf3b6d2b8507d50
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
- Use ThemedReactContext explicitly to reduce confusion, "addLifecycleEventListener()" and "removeLifecycleEventListener" should be forced to call on ThemedReactContext
- Migrate "getNativeModule" and "handleException" calls from ThemedReactContext to ThemedReactContext.getReactApplicationContext
Changelog:
[Android][Changed] - Use ThemedReactContext explicitly to reduce confusion
Reviewed By: mdvacca
Differential Revision: D42101979
fbshipit-source-id: be34b7397ccf4f58477bab6cfa8c58eedd99e225
Summary:
This diff is moving all relevant cxx component classes out of react-native-github, this is necessary to make it easy to iterate on their APIs
We will move them back again to OSS once we make the API stable
changelog: [internal] internal
Reviewed By: arhelmus
Differential Revision: D42018363
fbshipit-source-id: bacf0c667e2e8df57b4b57e257bf937586b8e6f7
Summary:
This diff is fixing a NullPointerException occuring when using Placeholder in TextInput. In some particular scenarios Placeholder is being updated before the TextInput is even layed out.
In this diff I'm setting a defult LayoutParams to avoid NullPointerException to be thrown by android EditTextView. This change should not affect layout for TextInput components because layout will be overriden on the next Fabric commit.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D42078080
fbshipit-source-id: 294376e7f78d6ed58fc9f893553356553accba6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35619
Reference https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4353534
I'm exposing `ReactAndroid/src/main/jni/react/cxxcomponents` to be consumed via prefab.
It will be available to both: `react_nativemodule_core` and `reactnativejni`
Changelog:
[Internal] [Changed] - Expose ReactAndroid/src/main/jni/react/cxxcomponents via prefab
Reviewed By: cipolleschi
Differential Revision: D41965512
fbshipit-source-id: 3a5a7473267e2e161d9d7fb0e8dfa74593b47b6e
Summary:
This is a two step (1/2) fix to a race that could caused a `DELETE`...`CREATE` mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ, yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This race condition could cause a view to get deleted at the end of one UI frame, yet the mount instructions generated from animation in the next frame still need to access the deleted view and caused crashes like T112157805. Note that even though such crash is recorded as `RetryableMountingLayerException` and is a soft crash (which only gets logged but not crash in production), the out-of-order mount instructions could lead to illegal view state and make the surface unusable, like what's shown here:
{F820669000}
The diff fixes this issue by removing the `DELETE` [conflict animation](https://fburl.com/code/5ctckvz3) keyframe, as well as the `CREATE` [immediate mutations](https://fburl.com/code/txyomytd) from the layout animation. The Fabric mounting layer assumes no combination of `DELETE...CREATE` in the same frame from differ + [layout animation overrides](https://fburl.com/code/zn17uqch).
Reviewed By: sammy-SC
Differential Revision: D41895427
fbshipit-source-id: d6df02663ba707af6db4a63a325ac776ca54d18e
Summary:
This diff adds support for String props on C++ Components
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D41784029
fbshipit-source-id: 3065186074e1feca3dd0dd724105f1596146ee1d
Summary:
Previous diff D41486648 is causing crashes and a sev S311353, which is due to usages of an old Android API that only work after level 24 (D36500518 (0fc42fd35c)). ~~This diff updates the implementation to use a compatible API, but with worse runtime complexity.~~
~~https://fburl.com/txd0r89e is a good explanation on the two algorithm to calculate a streaming median value. This diff uses the approach described in https://stackoverflow.com/a/4903642.~~
## Update
Following suggestion from sshic, I preserved the existing algorithm but with a custom comparator approach.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D41505143
fbshipit-source-id: 494e07fa627b5cf8bad7971fa5de86d270a7412c
Summary:
Delete references of CppComponentRegistry from the internals of React Native Android renderer, since it's not necessary anymore
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41638890
fbshipit-source-id: c4b08853722874dbb21891817836862225469dd9
Summary:
This diff deletes the first implementation of C++ ViewManagers integrated into the internals of Fabric
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41638894
fbshipit-source-id: 2e7aebff587e2e57b7f3fbf37a24b04943c74573
Summary:
Changelog:
[Android][Changed] - Include the inspector in all build modes, and only turn it off/on at runtime.
Reviewed By: jpporto
Differential Revision: D40248901
fbshipit-source-id: f13c58f631e4617a6f157df8899e128959af450a
Nicola Corti
Janic Duplessis
Luna Wei
Nick Gerleman
Elias Nahum
Ruslan Lesiutin
Kudo Chien
Nick Gerleman
Gabriel Donadel Dall'Agnol
Joshua Selbo
Zhiyao Zhou
Jakub Piasecki
Xin Chen
Sharon Zheng
jonathancaley
Arushi Kesarwani
Ruslan Shestopalyuk
Samuel Susla
Lulu Wu
David Vacca
generatedunixname89002005325672
fabriziobertoglio1987
Fredia Huya-Kouadio
Michael Anthony Leon