Summary:
Noticed while working in MobileHome with android device, when interacting with the Tasks change progress/priority components (MobileHomeTasksDetailsSelectorToken), which provides `borderRadius` style and `backgroundColor: ifSelected ? value : null`, and when `backgroundColor` is `null`, the line changed in this diff crashes (throwing the `NoSuchKeyException` at `ReadableNativeMap:110` [because of isNull check on `ReadableNativeMap:107`])
Changelog:
[Android][Fixed] - Fixed crash when using style borderRadius: any with backgroundColor: null
Reviewed By: JoshuaGross
Differential Revision: D27932828
fbshipit-source-id: 801b04c856ee9dc5a36bbf3e6e3d81de9b1e81a1
Summary:
This diff replaces all usages of int by int32_t. This is to ensure we always use a fixed size for int that matches what's expected on Java.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27915608
fbshipit-source-id: 634c45796dda1d4434c3ad6ff3e199931c22940b
Summary:
Adds surface id for string logs of the IntBufferBatchMountItem to help debug updates with multiple surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27884232
fbshipit-source-id: c5ec65585830f7aa5b902603bcd1e91b61cfe4c1
Summary:
Refactor MapBufferBuilder to use int to store size of Mapbuffer data
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904646
fbshipit-source-id: 6b8b96fdd30184b6d35c1d612743eae653854d6d
Summary:
DynamicData can contain a big amount of data, refactoring type to use int instead of short
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904643
fbshipit-source-id: 157064b280e27a9c7c4a4f55af310392b178feda
Summary:
Add extra asserts and early deallocation in ReadableMapBuffer::importByteBufferAllocateDirect
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904645
fbshipit-source-id: 075a007c4ec5e005b839add054bd68c233b65801
Summary:
This diff fixes the importByteBufferAllocateDirect method.
This was tested enabling importByteBufferAllocateDirect in ReadableMapBuffer.java
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27867055
fbshipit-source-id: 9ef5e93ff6c7903782598dde1c499daa82cd467b
Summary:
To fix [the CI error](https://app.circleci.com/pipelines/github/facebook/react-native/8708/workflows/d584348e-941f-4653-96c2-46375894dfaa/jobs/196410)
There are two errors:
`error: undefined reference to '__android_log_write'` which solved by adding `-llog` linker flag.
`ld: error: cannot find -lc++` which workaround by static linking.
For the root cause, I am thinking that is after [NDK r19](https://developer.android.com/ndk/guides/other_build_systems),
the `-target` should specificy api level.
However, buck does not add this accordingly, e.g. `-target armv7-none-linux-androideabi`
Given wrong target will make NDK to have `cannot find -lc++` error.
The workaround is to use static linking.
Since it was an oss_cxx_library, the change should not have impact to Facebook internal testing.
## Changelog
[Internal] [Fixed] - Fix CI "Build Tests: Android Instrumentation Tests" errors
Pull Request resolved: https://github.com/facebook/react-native/pull/31352
Test Plan: Make CI green
Reviewed By: JoshuaGross
Differential Revision: D27757838
Pulled By: fkgozali
fbshipit-source-id: 8f9c80a89c6240938218abacb8a82e3e2e71adbc
Summary:
Changelog: [Internal]
Inverts registration of a SurfaceHandler with the scheduler: instead of passing a scheduler to the SurfaceHandlerBinding, we can now query the SurfaceHandler and register it in place.
Reviewed By: JoshuaGross
Differential Revision: D27624541
fbshipit-source-id: db5d7f1375fad72a805309a3fcd5a33080e4a4a7
Summary:
Changelog: [Internal]
Links APIs in Fabric and Venice to create a surface without a view and mount it separately when surface is started the usual way.
Reviewed By: mdvacca
Differential Revision: D27339365
fbshipit-source-id: d1b674ce856957465eb6f3a5d7f26eb0ab625353
Summary:
Changelog: [Internal]
`NativeAnimatedModule` on Android currently enforces all animation operations to be processed in batches to ensure that all associated operations are processed at the same time.
Some operations, however, can be triggered outside of the batching calls (e.g. when using `Animated` for tracking touches `PanResponder`), and they are not processed until the next batch.
This change tracks if we are currently processing a batch and doesn't assign a batch number if an operation was triggered outside of `startOperationBatch`/`finishOperationBatch` pair.
Reviewed By: mdvacca
Differential Revision: D27682424
fbshipit-source-id: 2ea8737c353c81557fa586b15aa5760db3e8813f
Summary:
This diff moves DisplayMode out of SurfaceHandler, this is necessary in order to use it from react/uimanager package
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D27669846
fbshipit-source-id: 274869d8f2907b1b159f51240440acece09a746f
Summary:
Extends https://github.com/facebook/react-native/pull/30694 to fix tests.
OkHttp v4 was released almost a year ago. Even though v3 is still receiving security and bug fixes, most of the new improvements and features are landing in v4. This PR bumps OkHttp from v3 to v4 and addresses backward-incompatible changes.
Side effects of this upgrade:
- OkHttp v4 depends on Kotlin's standard library, so react-native will have a transitive dependency on it.
- The dex method count of test apk has exceeded the maximum, so multidexing had to be enabled for android tests.
## 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] - Bumping OkHttp from v3 to v4.
Pull Request resolved: https://github.com/facebook/react-native/pull/31084
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: fkgozali
Differential Revision: D27597430
Pulled By: ShikaSD
fbshipit-source-id: 967379b41c2bcd7cfd4083f65059f5da467b8a91
Summary:
## Rationale
- AsyncDevSupportManager.loadSplitBundleFromServer() is an override of DevSupportManager.loadSplitBundleFromServer(), which is used by the bridge. However, AsyncDevSupportManager.loadJSBundleFromServer() has no bridge analogue. This is confusing: Are the methods in AsyncDevSupportManager Venice overrides for bridge related methods? It's easy to think yes, but the answer is no.
- AsyncDevSupportManager.loadJSBundleFromServer() is an additional layer of indirection that provides very little value: all it does it create the JSBundleLoader, and call onReactContextCreated. However, it does so in 11 lines of very confusing code.
A discussion we don't have to have now: Inheritance hierarchies are very difficult to understand and de-tangle. So, instead of using inheritance to make DevSupportManager work with Venice (via AsyncDevSupportManager), should we just refactor DevSupportManager so that it can be customized to work with Venice?
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27577591
fbshipit-source-id: b64dcd65e9a7c85b89443d860d441a0635547916
Summary:
Changelog: [Internal]
After D27016919, some mounting instructions can be executed before the view is attached, which is invalid. This change adds additional queue for such items, which can be later dispatched after view is ready.
The new queue is expected to be empty for usual rendering and used in prerendering flows only. In case of prerendering, it should only hold intermediate items between early start of `SurfaceHandler` and view attach.
Reviewed By: mdvacca
Differential Revision: D27291706
fbshipit-source-id: f383c1d0d7050f271993553b51bf2e387efe1e9e
Summary:
Changelog: [Internal]
Adjusts SurfaceMountingManager to allow starting surface without a view and attaching the view while surface is active.
This change is only meant to work with ReactSurface to allow creating `SurfaceHandler` without mounting views.
Reviewed By: mdvacca
Differential Revision: D27016919
fbshipit-source-id: 995383bc4f1bd298953516007743ffae0edf17c2
Summary:
Changes React Native so that when `accessibilityState` is used to change a view from `selected: true` to `selected: false`, the change in state is announced.
This is how `checked` works; it is unclear why Android does not do this for `selected`, too.
Changelog:
[Android][Added] - TalkBack now announces "unselected" when changing `accessibilityState.selected` to false.
Reviewed By: blavalla
Differential Revision: D27449293
fbshipit-source-id: a6d77b55d63655973ad93c4d5e3743742501f378
Summary:
This issue fixes https://github.com/facebook/react-native/issues/30955 and is a follow up to pr https://github.com/facebook/react-native/pull/24608 which added the basic Accessibility functionalities to React Native.
TextInput should announce "selected" to the user when screenreader focused.
The focus is moved to the TextInput by navigating with the screenreader to the TextInput.
This PR adds call to View#setSelected in BaseViewManager https://developer.android.com/reference/android/view/View#setSelected(boolean)
The View#setSelected method definition https://github.com/aosp-mirror/platform_frameworks_base/blob/master/core/java/android/view/View.java
```java
/**
* Changes the selection state of this view. A view can be selected or not.
* Note that selection is not the same as focus. Views are typically
* selected in the context of an AdapterView like ListView or GridView;
* the selected view is the view that is highlighted.
*
* param selected true if the view must be selected, false otherwise
*/
public void setSelected(boolean selected) {
if (((mPrivateFlags & PFLAG_SELECTED) != 0) != selected) {
// ... hidden logic
if (selected) {
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_SELECTED);
} // ... hidden logic
}
}
```
VoiceOver and TalkBack was tested with video samples included below.
## 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] [Fixed] - Fix Selected State does not announce when TextInput Component selected on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31144
Test Plan:
**<details><summary>CLICK TO OPEN TESTS RESULTS</summary>**
<p>
**ENABLE THE AUDIO** to hear the TalkBack announcing **SELECTED** when the user taps on the TextInput
```javascript
<TextInput
accessibilityLabel="element 20"
accessibilityState={{
selected: true,
}} />
```
| selected is true |
|:-------------------------:|
| <video src="https://user-images.githubusercontent.com/24992535/111652826-afc4f000-8807-11eb-9c79-8c51d7bf455b.mp4" width="700" height="" /> |
```javascript
<TextInput
accessibilityLabel="element 20"
accessibilityState={{
selected: false,
}} />
```
| selected is false |
|:-------------------------:|
| <video src="https://user-images.githubusercontent.com/24992535/111652919-c10dfc80-8807-11eb-8244-83db6c327bcd.mp4" width="700" height="" /> |
The functionality does not present issues on iOS
| iOS testing |
|:-------------------------:|
| <video src="https://user-images.githubusercontent.com/24992535/111647656-f401c180-8802-11eb-9fa9-a4c211cf1665.mp4" width="400" height="" /> |
</p>
</details>
</p>
</details>
Reviewed By: blavalla
Differential Revision: D27306166
Pulled By: kacieb
fbshipit-source-id: 1b3cb37b2d0875cf53f6f1bff4bf095a877b2f0e
Summary:
Previously I renamed hasActiveCatalystInstance() API in D27335055 (https://github.com/facebook/react-native/commit/dfa8eb0558338f18ea01f294a64d355f6deeff06), however this API is still used in an OSS class.
In this diff hasActiveCatalystInstance() is added back and marked as Deprecated to avoid breakages and leave the migration choice to OSS users.
Changelog:
[Android][Changed] Mark hasActiveCatalystInstance() as Deprecated
Reviewed By: yungsters
Differential Revision: D27538449
fbshipit-source-id: 30f2f890580ad7f8b41908e18013234b5bac72e9
Summary:
JSI callbacks are only destroyed if the callback is called. If the callback is never called, we're potentially leaking a lot of callbacks.
To mitigate this, we add a wrapper object that is owned by the std::function. Whenever the std::function is destroyed, the wrapper is destroyed and it deallocates the callback as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D27436402
fbshipit-source-id: d153640d5d7988c7fadaf2cb332ec00dadd0689a
Summary:
D26581756 (https://github.com/facebook/react-native/commit/86321a35c03df340b6c1ea740ea7f29e2659b0ab) was hacked for fixing T85822390, which was later properly fixed in D27369721, so I removed it in this diff.
Changelog:
[Android][Fixed] - Remove previous fix for "Fix text in ReactTextView sometimes being vertically displayed"
Reviewed By: mdvacca
Differential Revision: D27501405
fbshipit-source-id: 81417069d355936721868ce659b3fe8ce916302e
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
Sometimes ```hasActiveCatalystInstance()``` is used to check if it's safe to access the CatalystInstance, which will still crash in Venice.
Previously we mitigate this by changing ```reactContext.hasActiveCatalystInstance()``` to ```reactContext.hasActiveCatalystInstance() || reactContext.isBridgeless()```.
To solve this for all and good the plan is:
1, Rename ```hasActiveCatalystInstance()``` to ```hasActiveReactInstance()``` so it won't sounds like CatalystInstance-only.
2, Implement hasActiveReactInstance() for Venice. D27343867
3, Remove previous mitigation. D27343952
This diff is the first step, by xbgs there are **58** non-generated callsites of ```hasActiveCatalystInstance()``` in code base which are all renamed in this diff.
Changelog:
[Android][Changed] - Rename "hasActiveCatalystInstance" to "hasActiveReactInstance"
Reviewed By: mdvacca
Differential Revision: D27335055
fbshipit-source-id: 5b8ff5e09b79a492e910bb8f197e70fa1360bcef
Summary:
`InternalNode` will eventually not have a pointer to its parent. This diff removes one of the usages of the `InternalNode#getParent()` API. `InternalNode` will also not host the `YogaNode` eventually; so this diff also removes one of the usages of the `InternalNode#getYogaNode()` api.
Now the `Inputs#freeze` api will pass the parent's `YogaNode` and the `YogaNode` of the node (this) being measured.
Changelog: [Internal] Passes The YogaNode and parent YogaNode in the Inputs.freeze API
Reviewed By: SidharthGuglani
Differential Revision: D27240229
fbshipit-source-id: efc4ec3249a963c3181111f9b989d8ed9e17feb4
Summary:
We need to do this to break a dependency cycle that would happen if we try to have `view` depend on `mounting` just to add some telemetry to `view`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26827446
fbshipit-source-id: 4c415ebf5be3a02c18c80ea8a4a77068cae0f0fe
Summary:
Create YogaProps Interface; this interface represents the inputs to YogaNode for layout calculation.
Changelog: [Internal] Create YogaProps Interface; this interface represents the inputs to YogaNode for layout calculation.
Reviewed By: mihaelao
Differential Revision: D27229274
fbshipit-source-id: 5205caf2384661369d7a2d7e7f3e49ff831a1c92
Summary:
Instead of annotating individual methods with DoNotStrip, we actually want to ensure that nothing in this class gets stripped out.
This also upgrades the yoga/proguard-annotations package for Gradle builds.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27335181
fbshipit-source-id: 5b696c26faf4d1b32a3fd885e42a996aff23f0be
Summary:
android fbjni dependency bump to 0.2.2
The motivation is to address https://github.com/pytorch/pytorch/issues/34682 that pytorch_android and react-native use different versions of fbjni with the same name libfbjni.so
In case of loading 0.0.2 version it is missing functions in binary
Fbjni is not changing much, that's why this will solve that problem for a long time (Until fbjni changed and versions will not be aligned)
## Changelog
[Android][Added] fbjni version bump to 0.0.3
Pull Request resolved: https://github.com/facebook/react-native/pull/31191
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: passy
Differential Revision: D27330370
Pulled By: IvanKobzarev
fbshipit-source-id: 2ea07d80d23f8dbc80e946a8818c1ecb8eb746e8
Summary:
Changelog: [Internal]
FabricUIManager contains a lot of logic related to mounting items and manipulating dispatch queues, which can be safely extracted outside. Apart from decreased logical complexity, this change enables easier modification of the queuing behavior later in this stack.
Majority of the changes is caused by moving existing logic to a different class, no change in behavior expected.
Reviewed By: JoshuaGross
Differential Revision: D27271116
fbshipit-source-id: 86fe45b19bb839f96fde8ba607f72006f6401cc7
Summary:
This diff contains the code from the 35 diff stack - D27210587
This diff implement and integrates Mapbuffer into Fabric text measure system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27241836
fbshipit-source-id: f40a780df0723f27da440f709a8676cfcca63953
Summary:
The non-Fabric API has a `blockNativeResponder` param in setJSResponder. Make sure to pass that along in Fabric.
On Android this allows us to respect the flag and do the same thing non-Fabric was doing if `blockNativeResponder` is false. It's not clear yet what the impact is on iOS.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27058806
fbshipit-source-id: aa5074fa46191d78f5292a93d9040ab4bb58ca66
Summary:
Media picking wasn't working for Venice because we didn't implement onActivityResult in BridgelessReactFragment so the listener in FBProfileGemstoneReactModule didn't called.
Changelog:
[Android][Changed] - Added Nullable annotation
Reviewed By: mdvacca
Differential Revision: D27045861
fbshipit-source-id: 0ab2961ef0570d92259856b4132507ebb264eb9d
Summary:
On Android we have the notion of "virtual views", which are defined consistently but the logic is scattered and duplicated throughout the codebase.
The logic exists to mark nodes that exist in the ShadowTree, but not the View tree. We want to CREATE, UPDATE, and DELETE them on the platform, but not INSERT or REMOVE
them. They basically exist as EventEmitter objects.
The only issue with this is (1) duplicated code, which opened the possibility for inconsistent definition (2) StubViewTree did not account for virtualized views, which caused
assert crashes in debug mode for certain LayoutAnimations on Android.
By moving the definition to ShadowViewMutation and accounting for it in StubViewTree, asserts are correct and consistent on all platforms.
This was not caught until recently, because, until recently, no asserts actually ran on Android.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27001199
fbshipit-source-id: eb29085317037ba8a286d7813bdd57095ad4746f
Summary:
In DevSupportManagerBase.java->updateLastErrorInfo(), errorType was not recorded like errorMessage and errorStack, we could either remove errorType as a parameter or recorded it for future use. This diff recorded it since it would make the error info complete.
Changelog:
[Android][Changed] - Record latest error type in dev support
Reviewed By: PeteTheHeat
Differential Revision: D26884647
fbshipit-source-id: 712d82667bdc4b3410f4c83a3df9a456af6d9061
Summary:
Changelog: [Internal]
We were using RN util to get pixel density, but it depends on the surface being created after venice instance is initialized. Given that we have context every time we update constraints, it makes sense to use it directly.
Reviewed By: mdvacca
Differential Revision: D26959430
fbshipit-source-id: 78701786efd82857812df689a725ba094fbd226e
Summary:
Just adding more logs I found useful while playing around with the last diff (to verify that these methods were not actually implicated at all).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26972725
fbshipit-source-id: 0e048e1edbfbe5ed32c5277f17a7197e0afdc04f
Summary:
When the height of a HorizontalScrollView changes and there is a `layout` event, it can cause the underlying platform View code to scroll slightly to the right.
I'm... not really sure why, even after looking at the View code for a while. But it is clearly detectable and mirrors issues with RTL that were fixed recently.
This might warrant more investigation, but I believe the fix is relatively safe - we detect if there's an autoscroll only if the height changes and only if the scroll happens in "layout". That scopes the hack pretty well to just this bug.
There aren't really times when we actually want layout to scroll to the right, so... I think this is reasonable.
Changelog: [Changed][Android] Fixed issue that causes HorizontalScrollView to shift to the right when a TextInput is selected and keyboard pops up
Reviewed By: mdvacca
Differential Revision: D26972710
fbshipit-source-id: 441b1a3f07b9b68195a9e5e9a0c8d75c9d24a109
Summary:
Does not impact prod or even debug builds unless you switch on the debug flag. The issue is that we were trying to coerce booleans to integers.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D26970274
fbshipit-source-id: 3327029ae3afc307dd19b089c23c190cb9e3150c
Peter Laraia
David Vacca
Andrei Shikov
Lulu Wu
CodemodService FBSourceBuckFormatLinterBot
Kudo Chien
Mike
Araz Abishov
Ramanpreet Nara
grgr-dkrk
Tim Yung
fabriziobertoglio1987
Joshua Gross
Samuel Susla
Aditya Sharat
Ivan Kobzarev
generatedunixname89002005287564
