Summary:
We're seeing a lot of crashes from `PermissionsModule` not being able to access the current activity, mentioned in #10009 and here: https://github.com/facebook/react-native/issues/9310#issuecomment-245657347
As far as I can tell, there is no way to ensure the Activity exists since the `ReactContext` holds a `WeakReference` to the current Activity and it appears that the lifecycle calls are happening in the right order (so not the same as #9310).
This will at least allow people to catch the error in JS and update the UI or try again as opposed to crashing the app.
I'm working on some bigger changes in #10221 but this is a smaller change and important to get fixed I think.
Closes https://github.com/facebook/react-native/pull/10351
Differential Revision: D4010242
fbshipit-source-id: 7a76973bb2b3e45817d4283917740c89a10ec0b0
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary: Instead of sending a list of modules over to JS on startup (and actually blocking script execution) instead provide a proxy object that constructs each of these lazily.
Reviewed By: lexs
Differential Revision: D3936979
fbshipit-source-id: 71bde822f01eb17a29f56c5e60e95e98e207d74d
Summary:
This allows the React JS code that's running from a Service (ie GcmListenerService) to check permissions (ie check for VIBRATE permissions before delivering notifications)
**Test plan (required)**
I've run this code from a GcmListenerService subclass, and it works correctly.
Closes https://github.com/facebook/react-native/pull/10229
Differential Revision: D3980853
fbshipit-source-id: 026b1f0c953d7093b5af2bec0b4a93ebd228f62e
Summary: This way `UIImplementation` can hold on to it and use it outside of calls from the `UIManagerModule`.
Reviewed By: lexs
Differential Revision: D3899774
fbshipit-source-id: 01e4956c4540bcdf30774a3f40a625e934714ee9
Summary:
Gradle unit tests started failing, this PR fixes mockito to be one specific version instead of loose 1.+
**Explain the **motivation** for making this change. What existing problem does the pull request solve?**
Circle CI started failing without any specific reason https://circleci.com/gh/facebook/react-native/tree/master, looks like a dependency error.
Alas it is, I can reproduce the error on master with clean caches.
**Test plan (required)**
After the fix:
```
bestander-pro:react-native bestander$ ./gradlew :ReactAndroid:testDebugUnitTest
Incremental java compilation is an incubating feature.
:ReactAndroid:preBuild UP-TO-DATE
:ReactAndroid:preDebugBuild UP-TO-DATE
:ReactAndroid:checkDebugManifest
:ReactAndroid:preDebugAndroidTestBuild UP-TO-DATE
:ReactAndroid:preDebugUnitTestBuild UP-TO-DATE
:ReactAndroid:preReleaseBuild UP-TO-DATE
:ReactAndroid:preReleaseUnitTestBuild UP-TO-DATE
:ReactAndroid:prepareComAndroidSupportAppcompatV72301Library UP-TO-DATE
:ReactAndroid:prepareComAndro
Closes https://github.com/facebook/react-native/pull/10239
Differential Revision: D3968396
Pulled By: matryoshcow
fbshipit-source-id: 63374261303fb98dc252898dfd5d3b3346597e4f
Summary:
When using webview on android and trying to link to an html file located on device (using `file://`), the application would crash with an error specifying that nothing handles the fired intent. This is due to [`33a1f28`](33a1f28654) which attempts to intercept all non `http(s)` links.
This is a simple fix so hopefully it can make it into the next stable release.
Closes https://github.com/facebook/react-native/pull/9668
Differential Revision: D3956485
fbshipit-source-id: 5a752abc21802a44e3a26e88669ccb6852076992
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
The hack for the status bar height is not necessary any longer, so we can remove
all code related to it
Reviewed By: lexs
Differential Revision: D3943770
fbshipit-source-id: 2d70f4ea10dd76ea6e6a73bb6edccae388bde1c0
Summary:
On tablets, using Display.getRotation() returned ROTATION_0 or ROTATION_180 when it was in landscape, not portrait as it does on phones. This resulted in the Modal being sized incorrectly on tablets. Using size and comparing width and height is the only way I can think of to figure out the device orientation and give the modal the correct size. With this change, all issues listed in #7708 should be resolved.
**Test plan**
Modal should correctly fill screen on Android phone and tablet in both portrait and landscape.
Closes https://github.com/facebook/react-native/pull/10159
Differential Revision: D3950369
Pulled By: andreicoman11
fbshipit-source-id: 9488c4302a76cc48e4f8a4026eb5770d40b6e3d2
Summary:
I noticed that the example doesn't match the definition below.
cc bestander
Closes https://github.com/facebook/react-native/pull/10175
Differential Revision: D3943967
Pulled By: bestander
fbshipit-source-id: 6941d4d663e1fd42f8723cd722eb8a5712a63dc8
Summary: Provide a base `HeadlessJsTaskService` class that can be extended to run JS in headless mode in response to some event. Added `HeadlessJsTaskEventListener` for modules that are interested in background lifecycle events, and `HeadlessJsTaskContext` that basically extends `ReactContext` without touching it. The react instance is shared with the rest of the app (e.g. activities) through the `ReactNativeHost`.
Reviewed By: astreet
Differential Revision: D3225753
fbshipit-source-id: 2c5e7679636f31e0e7842d8a67aeb95baf47c563
Summary:
This changes modal behavior to resize when the keyboard appears/disappears.
Previously, the modal would not react in any way, or it would pan above to bring the
TextInput into view. Resizing is the correct behavior for android.
This is not trivial, as in, setting the flag, because of the combination of
react native laying out all views and the system reacting to the keyboard
appearance in a weird way. Namely:
- if `windowTranslucentStatus` is not set, the system will just call
`onSizeChanged` on the dialog's content view, and everything works nicely
- with `windowTranslucentStatus` set, the system will consider the dialog as a
full screen view that doesn't resize. In order for it to resize, the base
view of the layout needs to have
`setFitsSystemWindows(true)` called on it. This is needed, so that the system
can call layout on that base view with the new value of `paddingBottom` that
coincides with the height of the keyboard. Neat.
We fix this by wrapping our existing content view (mHostView) in a simple
FrameLayout that has `setFitsSystemWindows` set. That way, `mHostView` will have
`onSizeChanged` called on itself with the correct new size of the dialog.
This has the fortunate consequence of our layout now also getting `paddingTop` as the size of the
status bar, which means that we can remove the JS `top` hack in Modal, which
was necessary for no view getting drawn under the status bar.
This behavior is set as default, since that is the default correct Android behavior.
Reviewed By: astreet
Differential Revision: D3913784
fbshipit-source-id: 4378ada21f466dc7ac6e357abeca10b88009ca3f
Summary:
After D3876927 this test started failing on CI.
Locally we can't reproduce it, and it will take some time to understand what this test is intended for so that we could remove the variable part.
More investigation will follow, t13583009
Reviewed By: emilsjolander
Differential Revision: D3930334
fbshipit-source-id: 279f67eb5a77b5d4250afd48c8b94c828da6925c
Summary:
`ReactSwipeRefreshLayout` extends `SwipeRefreshLayout` which does not play nice with Android's touch handling system.
There are two problems:
1. `SwipeRefreshLayout` overrides and swallows `requestDisallowInterceptTouchEvent`, which means that Views underneath the `SwipeRefreshLayout` will not interact correctly with parent Views of
`SwipeRefreshLayout`. We've seen this in practice by H-ScrollViews having their touches intercepted by an enclosing ViewPager. This is fixed by passing `requestDisallowInterceptTouchEvent` up to the parents of `SwipeRefreshLayout`.
2. `SwipeRefreshLayout` overrides `onInterceptTouchEvent` and never calls `super.onInterceptTouchEvent`, therefore ignoring the value of `disallowIntercept`. That means that it will intercept some touches when it
shouldn't. One such case is again the H-ScrollView, which should receive all horizontal scrolls and stop `SwipeRefreshLayout` from intercepting any touch events after scrolling. Currently, after the H-ScrollView starts scrolling, it is still possible to get the `SwipeRefreshLayout` to detect and emit refresh events. This is fixed by checking and blocking on horizontal scrolls.
Reviewed By: foghina
Differential Revision: D3929893
fbshipit-source-id: e6f8050fb554e53318a7ca564c49c20cb5137df9
Summary:
Combining 2 animated values via addition, multiplication, and modulo are already supported, and this adds another one: division.
There are some cases where an animated value needs to invert (1 / x) another animated value for calculation. An example is inverting a scale (2x --> 0.5x), e.g.:
```
const a = Animated.Value(1);
const b = Animated.divide(1, a);
Animated.spring(a, {
toValue: 2,
}).start();
```
`b` will then follow `a`'s spring animation and produce the value of `1 / a`.
The basic usage is like this:
```
<Animated.View style={{transform: [{scale: a}]}}>
<Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>
```
In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out.
Also added this to native animated implementation.
Reviewed By: foghina, mmmulani
Differential Revision: D3922891
fbshipit-source-id: 32508956c4b65b2deb7574d50a10c85b4809b961
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
The styles that get applied to the Dialogs that are created in RN are set in
`themes.xml`, so I'm moving `windowTranslucentStatus` there as well so that we
have all of them collocated.
Reviewed By: astreet
Differential Revision: D3913402
fbshipit-source-id: 8f23e84fb017c8810634ffe8279171061292b351
Summary: Utilizes the build time annotation processor ReactModuleSpecProcessor that creates ReactModuleInfos for modules annotated with ReactModule and listed in the ReactModuleList annotation of LazyReactPackages. This way we don't have to instantiate the native modules to get the name, canOverrideExistingModule, and supportsWebWorkers values of the native modules. In the NativeModuleRegistry, we either store these ReactModuleInfos inside of a ModuleHolder or if we can't get the ReactModuleInfo for a specific module we instantiate that module to get the values (as we previously did) to store in a LegacyModuleInfo.
Reviewed By: astreet
Differential Revision: D3796561
fbshipit-source-id: f8fb9b4993f59b51ce595eb2f2c3425129b28ce5
Summary: Create separate buck library for image events so you can depend on that without depending on all of fresco
Reviewed By: brosenfeld
Differential Revision: D3907894
fbshipit-source-id: dca7a00d38b8b8bb5bab05b6883f6933fff3fa76
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10057
Differential Revision: D3913431
Pulled By: bestander
fbshipit-source-id: c761640839ce0e85196ffd7fc1a4e1c615078b06
Summary:
The dialog intercepts all key events, we need to redirect some of them to the
activity so that it can display the dev menu.
Reviewed By: foghina
Differential Revision: D3894503
fbshipit-source-id: fb62346a4da783f28a73c5a9e20566a451177629
Summary:
In some cases, the size of the content view changes before we add views to the
Modal. That means that the size of that view will not be set through the
`onSizeChanged` method. This can result in some apps apparently freezing,
since the dialog is created, but there are no actual views in it.
For that reason, we still need the ModalHostShadowNode to set the size of the
initial view, so that by the time the view gets added it already has the correct
size.
There's a new helper class so that we can reuse the modal size computation.
Reviewed By: foghina
Differential Revision: D3892795
fbshipit-source-id: 6a32bd7680a74d9912a21bfebb4ebd7a3c3c3e38
Summary:
Since API 18, Android locations have had the `isFromMockProvider()` function, to verify the validity of a provided location. This was one of many methods one could verify location data, but as of Marshmallow, the other ways of detecting if "Mock Locations" is on in developer settings has been deprecated or defunct.
This means some devices can only detect location mocking by exposing the method on the location object.
This change provides that exposure.
Closes https://github.com/facebook/react-native/pull/9390
Differential Revision: D3858205
Pulled By: bestander
fbshipit-source-id: 3bae429cc0596ea01926c5be204f4403e4a2414f
Connor McEwen
Emil Sjolander
Satyajit Sahoo
Pieter De Baets
Andrew Y. Chen
Aaron Chiu
Mike Lambert
Felix Oghina
Konstantin Raev
Andy
Hoa Dinh
Alexander Pantyuhov
Andrei Coman
Dave Pack
Nicolas Charpentier
Chris Hopman
Marc Horowitz
Kevin Gozali
Don Yu
Aaron Chiu
Brad Daily
Gant Laborde