Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32770
Fest is EOL and is replaced by assertj, originally a fork of Fest. This change replaces the usages in internal tests and removes the dependency.
Changelog:
[Internal][Android] Replace fest with assertj
Reviewed By: genkikondo
Differential Revision: D33143454
fbshipit-source-id: c1cbe5b064d007018f73858b2913806c11aa08af
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:
This diff refactors the createViewInstance method in order to ensure that viewID is set before props are updated in the view.
This is necessary because there are components that deliver events at the same time their props are set. This means that some components might not have their viewId set correctly when events are delivered.
Since viewId is used to determine if a view belongs to Fabric or Paper, there are cases when the events are not delivered to the right renderer
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D25667987
fbshipit-source-id: 4acfa8f80d66e9e59514354481957d7d3b571248
Summary:
This comment shouldn't be committed, and should just be part of the template that generates new BUCK files.
Changelog: [Internal]
Differential Revision: D23225700
fbshipit-source-id: a1728e1a4ac0f3f94c4d1330d489bfae7a76a82d
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
For some components, we will have state as soon as the ShadowNode is created that may be meaningful. In those cases, ViewManagers should be able to use State to create or preallocate views.
FB: This will be used in following diffs for Litho support.
Reviewed By: mdvacca
Differential Revision: D15343702
fbshipit-source-id: 8fd672251cb88dea662b5cae5a9efc96877d28a9
Summary:
This is a reconstitution of #24190. It extends accessibility actions to include both a name and user facing label. These extensions support both standard and custom actions.
We've also added actions support on Android, and added examples to RNTester showing how both standard and custom accessibility actions are used.
## Changelog
[general] [changed] - Enhanced accessibility actions support
Pull Request resolved: https://github.com/facebook/react-native/pull/24695
Differential Revision: D15391408
Pulled By: cpojer
fbshipit-source-id: 5ed48004d46d9887da53baea7fdcd0e7e15c5739
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary: Create views with props in one call instead of two. Backwards-compatible.
Reviewed By: shergin
Differential Revision: D14846424
fbshipit-source-id: cb53225579089f7e51d4e9d1fc9fc2e331a994c1
Summary: This code was shipped as part of the initial open-source release but was never used.
Reviewed By: sahrens
Differential Revision: D14649389
fbshipit-source-id: 0c068ca69b91d275008f4a7af77a23a4f1470c18
Summary:
Changes our property access pattern to iterate through props once and pass the Object value directly rather than looking the value up in the map with the key.
Note some ViewManagers methods (especially yoga related ones on shadow nodes) expect a `Dyanamic`, so this diff also creates Dynamic's only when needed by the hand-written code, and introduces a new `DynamicWithObject` to create them that simply wraps the underlying object (as opposed to `DynamicWithMap` which wraps the map and does a lookup any time the `Dynamic` is accessed.
Reviewed By: mdvacca
Differential Revision: D14453300
fbshipit-source-id: df98567b6eff1e6b7c611f179eb11e413fb94e5d
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary:
androidx files were not being instrumented properly which meant we would have exceptions thrown by powermock
Robolectric Instrumentation config was changed by hand, the remainder is a codemod using abgs + xargs + sed
Differential Revision: D14323745
fbshipit-source-id: 56aa97dad5d7197f4eb0ba1fdd80b1583bcad6ac
Summary:
Unused loads still take time to process and pollute
execution environment.
drop-conflicts
Reviewed By: passy
Differential Revision: D13054018
fbshipit-source-id: a8fe58d1c55c031925c2c0267e24e67f021cd91d
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
Summary:
We're currently getting a redbox in Turkish when we try to convert the string 'easeInEaseOut' to an InterpolatorType. This is because I use toLowerCase() to compare the string without setting a locale; in Turkish, the capital letter 'I' doesn't convert to 'i' when you lowercase it, but rather to 'ı' (http://www.i18nguy.com/unicode/turkish-i18n.html).
Passing in a locale param to `toLowerCase()` fixes it. Also updating the test.
Differential Revision: D10315474
fbshipit-source-id: 54be3ff1d3f91cb2ec765ff705ac364b976b8c6f
Summary: Adding a test for the newly added InterpolatorType.fromString()
Reviewed By: axe-fb
Differential Revision: D10203814
fbshipit-source-id: f3c70db1a5754c79b1bdd881d266bec110934494
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Accessibility roles are enums that are looked up by matching a string accessibility role from JS to the enum's name using .toUpperCase(). .toUpperCase() causes issues in certain languages such as Turkish because the "i"s translate to "?".
D9402330 tried to address this by forcing the .toUpperCase to use Locale.US, but now it sometimes translates to "?"
Use .equalsIgnoreCase() instead to avoid translations.
Reviewed By: mdvacca, mmmulani
Differential Revision: D9497494
fbshipit-source-id: 0f8b7f2071b08ccb86655fee7bfd2d009ddde8eb
Summary:
Implemented a version of accessibility Hints on android by adding hint text to the end of contentDescription. There is already an existing prop on js and iOS implementation.
Changes involve:
* adding a prop on native android code for accessibilityHints
* setting the accessibilityDelegate after the props are all loaded.
* Instead of directly updating the accessibility delegate, the prop setters now update state by setting the values of the variables. Once all props are set, the accessibility delegate is set based on the props
* BaseViewManager keeps track of whether or not accessibility props have been set
* AccessibilityDelegateUtil keeps track of what the props have been set to. (Renamed AccessibilityRoleUtil to AccessibilityDelegateUtil)
Currently, this is the easiest way of emulating the way accessibility hints work on iOS, and I think having an android counter part is better than having nothing.
It's different from iOS in that it will announce the hint before the role, and also cannot be turned off.
Ex:
if I set the accessibility like this:
```
<View
style={styles.container}
accessible={true}
accessibilityLabel="accessibility label"
accessibilityRole="button"
accessibilityStates={['selected']}
accessibilityHint="accessibility Hint">
<Text> Tester </Text>
</View>
```
Talk back will read:
`accessibility label, accessibility Hint, button, selected`
In the future for next steps, I plan on investigating the process of making a second announcement after the first
Reviewed By: achen1
Differential Revision: D9037226
fbshipit-source-id: 8d484e1114eb69aa5f5314b3755b351b8ea80b09
Summary:
@public
This diff deprecates and deletes the UIImplementationProvider class.
It is not required to create an UIImplementation provider anymore, from now on the UIImplementation is created inside the UIManagerModule.
If you are using the UIImplementationProvider to create a ReactInstanceManager
e.g.:
```
ReactInstanceManager =
getReactInstanceManagerBuilder()
...
.setUIImplementationProvider(...)
...
.build();
```
Then you should just remove that line:
```
ReactInstanceManager =
getReactInstanceManagerBuilder()
.set.....
.build();
```
Reviewed By: achen1
Differential Revision: D8650376
fbshipit-source-id: 8d883295d8bf6578a99685edf6a2a84c6d0df0cf
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
👋 Hello! Thanks for react-native, it’s a great project.
I was digging into the Android implementation in _ReactAndroid_ and noticed a couple typos in the documentation. I went through and tried to fix all the typos I could find using [aspell](http://aspell.net).
Not applicable: these changes are only to comments, and CI should be skipped.
[ANDROID][ENHANCEMENT][*] - Correct comment and docblock typos
Closes https://github.com/facebook/react-native/pull/17049
Differential Revision: D6472182
Pulled By: shergin
fbshipit-source-id: 7e62cab118609596b483d1cf16c3abf651d6753b
Summary:
Abstract class `ReactBaseTextShadowNode` was decoupled from `ReactTextShadowNode` to separate two goals/roles:
* `ReactBaseTextShadowNode` represents spanned `<Text>` nodes, which can bear text attributes (both `RCTText` and `RCTVirtualText`);
* `ReactTextShadowNode` represents anchor `<Text>` view in Yoga terms, which can bear layout attributes (`RCTText` and `RCTTextInput`).
`ReactVirtualTextShadowNode` now inherits `ReactBaseTextShadowNode`.
The same architectural changes was applited to view managers.
Why?
* This is just a better architecture which represents the nature of this objects.
* Bunch of "negative" logic which turn off excessive features for some suclasses was removed.
* Memory efficiency.
* Now we can improve `<TextInput>` component using right inheritance. Yay!
Reviewed By: achen1
Differential Revision: D5715830
fbshipit-source-id: ecc0764a03b5b7586fe77ad31f149cd840f4da41
Summary:
This PR fixes an issue with rotation decomposition matrix on android.
The issue can be illustrated with this sample code https://snack.expo.io/r1SHEJpVb
It surfaces when we have non-zero rotation in Y or X axis and when rotation Z is greater than 90deg or less than -90deg. In that case the decomposition code doesn't give a valid output and as a result the view gets rotated by 180deg in Z axis.
You may want to run the code linked above on android and iOS to see the difference. Basically the example app renders first image rotated only by 89deg and the next one by 91deg. As a result you should see the second view being pivoted just slightly more than the first image. Apparently on android the second image is completely flipped:
iOS:
Android:
The bug seemed to be caused by the code that decomposes the matrix into axis angles. It seems like that whole code has been overly complicated and we've been converting matrix first into quaternion just to extract angles. Whereas it is sufficient to extract angles directly from rotation matrix as described here: http://nghiaho.com/?page_id=846
This formula produces way simpler code and also gives correct result in the aforementioned case, so I decided not to debug quaternion code any further.
sidenote: New formula's y angle output range is now -90 to 90deg hence changes in tests.
Closes https://github.com/facebook/react-native/pull/14888
Reviewed By: astreet
Differential Revision: D5414006
Pulled By: shergin
fbshipit-source-id: 2e0a68cf4b2a9e32f10f6bfff2d484867a337fa3
Summary:
Android API 15 still have 1.5~2.0% distribution (refer: [Dashboard - Android Developer](https://developer.android.com/ndk/guides/standalone_toolchain.html#creating_the_toolchain)).
React Native is a good tec but many companies cannot endure loose their consumer. [Choreographer](https://developer.android.com/reference/android/view/Choreographer.html) triggered UI operation is the only reason that React Native Android sdk use minSdkVersion 16, so we can use a backward solution **only in API 15**: [Handler](https://developer.android.com/reference/android/os/Handler.html).
In this PR, the biggest change is :
- Make core operation of ReactChoreographer to an interface: ReactUIDriver;
- Impl ReactUIDriver by Handler => UIDriverHandlerImpl, refactor ReactChoreographer to UIDriverChoreographerImpl;
- Let UIDriverFactory to choose which one impl would be in use. (Only use handler in api 15).
Closes https://github.com/facebook/react-native/pull/12396
Reviewed By: AaaChiuuu
Differential Revision: D4588399
Pulled By: astreet
fbshipit-source-id: 76408e53664314dd926e6a553cde6bafbd37779e
Joshua Selbo
Pieter De Baets
Ron Edelstein
Andres Suarez
Andrei Shikov
fabriziobertoglio1987
David Vacca
Sahil Jain
Tom Underhill
Oleksandr Melnykov
Joshua Gross
Sharon Gong
Rick Ratmansky
Spencer Ahrens
Taras Tsugrii
Tim Yung
Emily Janzer
Héctor Ramos
Jonathan Kim
Andrew Chen (Eng)
Ziqi Chen
Sophie Alpert
Cory Reed
Dmitry Zakharov
Valentin Shergin
Alexey Lang
Krzysztof Magiera
Aaron Chiu
desmondyao
Michael Bolin
Michael Lee
Konstantin Raev
