Summary:
Fixes redbox/yellowbox symbolication when the Java delta client is enabled. Previously the modules would get concatenated in a nondeterministic order (owing to Metro's parallelism) which differed from their order in the source map, where they're explicitly sorted by module ID.
This diff changes the data structure holding modules in memory from a `LinkedHashMap` (which iterates in insertion order) to a `TreeMap` (which iterates in key order).
NOTE: Similar to this change in the Chrome debugger's delta client: https://github.com/react-native-community/cli/pull/279
Reviewed By: dcaspi
Differential Revision: D15301927
fbshipit-source-id: 27bdecfb3d6963aa358e4d542c8b7663fd9eb437
Summary:
When running Android app for the first time, the packager is requesting delta bundles from metro instead of a bundle (in dev settings delta bundles are disabled by default and marked as experimental). UI of dev settings is not consistent with the current state, to turn off delta bundles you have to enable them and then disable.
[Android] [Fixed] - Disable delta bundles on the first app run
Pull Request resolved: https://github.com/facebook/react-native/pull/24848
Differential Revision: D15334059
Pulled By: cpojer
fbshipit-source-id: 384a8abba64c54db3656a4d5d0e24acc825870c8
Summary:
The files in `ReactAndroid/src/androidTest/js` use Haste names; this commit migrates them to use path-based imports. This helps us move RN towards standard path-based requires. All the requires in `androidTest` have been rewritten to use relative requires.
[General] [Changed] - Migrate "androidTest" JS from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24813
Differential Revision: D15318108
Pulled By: cpojer
fbshipit-source-id: dddc68f992b8dea48afb01fd4481bd5b846231ca
Summary: The existing implementation of JSCallInvoker holds a reference to Instance (aka the bridge). This diff makes JSCallInvoker an abstract base class that's extended by BridgeJSCallInvoker, which is what's returned by CatalystInstance to initialize TurboModules. This will allow us to add another class that derives from JSCallInvoker that doesn't rely on the bridge.
Reviewed By: shergin
Differential Revision: D15252375
fbshipit-source-id: 75eee2ca149235a63e2a2cd8cdd361b163d1d1ab
Summary:
We are getting errors where views are being dropped twice.
This is following from logic that viewManagers are only removed from `mTagsToViewManagers` from `dropView`.
This log will hopefully identify if we are getting improper operations because we shouldn't be re-using tags
Reviewed By: mdvacca
Differential Revision: D15152869
fbshipit-source-id: 914ee9c1772fa066adefde0753075ecba6377a0c
Summary:
This diff ensures the method scheduler.constraintSurfaceLayout is executed before the JS run application start.
This is necessary to properly set the pointScaleFactor for the Root before running JS.
This is a workaround to fix a bug when the pointScaleFactor changes over time for the rootShadowNode. The bug is easily reproducible when rendering the "fabric" indicator on Fabric screens. During the first render of a Fabric screen this method was called before "JS run application" starts, and the Fabric indicator was render correctly.
Beacuse of timing of measure APIS, the second time a Fabric screen is rendered the method is called after the "JS run application process started", as a consecuence the Fabric indicator is not rendered correctlly (the pointScaleFactor is incorrectly assigned into the layout metrics of the Fabric indicator text).
We still need to analyze why the pointScaleFactor is not correctly assigned when it is set after the "JS run application process started", but this will be part of another diff.
Reviewed By: shergin
Differential Revision: D15303554
fbshipit-source-id: 7d985cefee20fd40dbe04166c1a1358b3f3ddc85
Summary: `YogaStylableProps.yogaStyle` is designed to be consumed by Yoga only. Making it `protected` allows us to avoid confusion and misuse of this props.
Reviewed By: JoshuaGross
Differential Revision: D15296474
fbshipit-source-id: cf9e416afee99fb426d72765557b34d303a63dbe
Summary:
Fixes#13351
Two root causes:
1. Android Spinner will reset selection to undefined after setAdapter()
which will trigger onValueChange().
The behavior is not expected for RN.
And the solution is to setSelection() explicitly
2. In original implementation, it setups `items` immediately,
but delays the `selected` setup after update transaction.
There will be some race condition and incosistency
if update `items` only.
The fix will do the setup all after update transaction.
[Android] [Fixed] - Fix#13351 PickerAndroid will reset selected value during items update.
Pull Request resolved: https://github.com/facebook/react-native/pull/24793
Differential Revision: D15293516
Pulled By: cpojer
fbshipit-source-id: 5a99a60015c7e1b2968252cdc0b2661d52a15b9d
Summary:
Fixes this issue:
https://github.com/facebook/react-native/issues/24468
It was incorrectly closed by a fix on react-native-community CameraRoll implementation. CameraRoll in react-native still crashes when finding a file with # sign
[Android] [Fix] - Fix Android Camera Roll crash on mime type guessing
Pull Request resolved: https://github.com/facebook/react-native/pull/24780
Reviewed By: mdvacca
Differential Revision: D15281062
Pulled By: lunaleaps
fbshipit-source-id: ca3364c8478d9bfc9a0a6657b531ffb384145d8c
Summary: In the future we're planning to decouple ThemedReactContext from the bridge (CatalystInstance). For now, we just need to be able to create a ThemedReactContext with a ReactContext that has no Catalyst instance.
Reviewed By: mdvacca
Differential Revision: D15246442
fbshipit-source-id: 99ebda6521f4df72969011ea0e6ea41b046875c8
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D15246287
fbshipit-source-id: 4b8c53e68112af7eded47d8c31311500cc296dfe
Summary: Right now TurboModuleManager gets the JSCallInvokerHolder from the bridge in its constructor; this diff changes the constructor to make the JSCallInvokerHolder a required argument so that TurboModuleManager doesn't directly depend on the bridge.
Reviewed By: axe-fb, RSNara
Differential Revision: D15227184
fbshipit-source-id: b16e6abaa727587986a132d0e124163acdf55408
Summary:
@public
`YGNodeGetInstanceCount` was only ever meant for tests, and caused data races in multi-threaded environments.
It was completely replaced with event-based counting for tests.
Here we remove public API around the counter, and the counter itself.
Reviewed By: SidharthGuglani
Differential Revision: D15174857
fbshipit-source-id: 228e85da565bac9e8485121e956a2e41910b11c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/24764
The `test_android` CI build was failing:
```
./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Not using buckd because watchman isn't installed.
Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
PARSING BUCK FILES: FINISHED IN 1.1s
No build file at ReactAndroid/src/main/libraries/fbjni/BUCK when resolving target //ReactAndroid/src/main/libraries/fbjni:java.
This error happened while trying to get dependency '//ReactAndroid/src/main/libraries/fbjni:java' of target '//ReactAndroid/src/main/java/com/facebook/react/turbomodule/core:jscallinvokerholder'
Exited with code 1
```
The problem was that I was using `react_native_dep("libraries/fbjni:java")` to access JNI classes like `HybridData`. In open source this target translates to the path `//ReactAndroid/src/main/libraries/fbjni`, which doesn't exist. Instead, the actual classes are available at the path `//ReactAndroid/src/main/java/com/facebook/jni`. Therefore, I changed the target to `react_native_dep("java/com/facebook/jni:jni")`. This is exactly how the bridge (i.e: `//ReactAndroid/src/main/java/com/facebook/react/bridge:bridge`) accesses JNI clases.
Reviewed By: hramos
Differential Revision: D15261218
fbshipit-source-id: 659a5627389bbca3603db7de347618cd400d4ffc
Summary:
AccessibilityInfo.announceForAccessibility is currently only available on iOS. I've added the Android specific implementation, updated RNTester, and the documentation.
[Android] [Added] - Added AccessibilityInfo.announceForAccessibility for Android
[General] [Added] - RNTester example for AccessibilityInfo.announceForAccessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/24746
Differential Revision: D15258054
Pulled By: cpojer
fbshipit-source-id: 3e057a5c32b28e30ea2ee74a18854b012cd2dbfd
Summary:
In https://github.com/facebook/react-native/pull/23865, RN introduced support for custom fonts the Android Way. But it introduced performance regression because it'll lookup for a font using getIdentifier() every time fontFamily changed. This PR fixes regression by requiring custom fonts to be listed in **fonts** array, and populating **mTypeCache** at first use using the list.
[Android] [Changed] - Require custom fonts to list in **fonts** array. Fixes performance regression.
Pull Request resolved: https://github.com/facebook/react-native/pull/24595
Reviewed By: mdvacca
Differential Revision: D15184590
Pulled By: fkgozali
fbshipit-source-id: e3feb2396609583ebc95101130186a1f5af931da
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary:
In #24095, we removed the code that changes the underlying Android view's enabled state to false when "disabled" is included in the accessibility states, which seems correct. The Android view's state shouldn't mirror the accessibility state, it should be the other way round-- the accessibility state should represent the state of the view.
It seems that the existing test is brokenly setting the disabled state in the Javascript object, and then querying the Android view's enabled state to confirm the change. If the Button implementation is actually the culprit, then IMHO, the correct fix would be to have the Button implementation manipulate the Android View's enabled state, not the accessibilityStates code.
[android] [fix] - Fix internal test case around disabled state of buttons
Pull Request resolved: https://github.com/facebook/react-native/pull/24678
Differential Revision: D15237590
Pulled By: cpojer
fbshipit-source-id: d7ebefbcba9d4d9425da4285175302e4b6435df7
Summary: I'm not sure if this is a good idea. Right now FabricUIManager creates a ThemedReactContext in addRootView() using the RAC you pass in. If you pass in an RAC without a Catalyst instance, this will throw; this diff makes it so it'll throw the next time you try to actually try to access the CatalystInstance, instead. I don't know if we're really relying on this right now, but we need to be able to create a ThemedReactContext without a CatalystInstance for Venice (for now, until we actually go through and get rid of TRC's dependency on the CatalystInstance entirely - but that'll be a lot more work)
Reviewed By: mdvacca
Differential Revision: D15194220
fbshipit-source-id: 64689cbe79c84ae33fe16e3dc396e3c69ec8e20f
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D14817741
fbshipit-source-id: f314a526c6534792714e5ba55dd873f1728c6b9f
Summary:
[General] [Fix] - Reorder operations of native view hierarchy
When we update the native view hierarchy in `manageChildren` we:
1. iterate through all views we plan to remove and remove them from the native hierarchy
2. iterate through all views we plan to add and add them to the native hierarchy
3. iterate through all views we plan to delete and delete them (remove them from memory)
This covers these cases:
a. A view is moved from one place to another -- handled by steps 1 & 2
b. A view is added -- handled by step 2
c. A view is deleted -- handled by step 1 & 3
> Note the difference between remove and delete
Everything above sounds fine! But...
The important bit:
**A view that is going to be deleted asynchronously (by a layout animation) is NOT removed in step 1. It is removed and deleted all in step 3.** See: https://fburl.com/ryxp626i
If the reader may recall we solved a similar problem in D14529038 where we introduced the `pendingIndicesToDelete` data structure to keep track of views that were marked for deletion but had not yet been deleted. An example of an order of operations that we would've solved with D14529038 is:
* we "delete" the view asynchronously (view A) in one operation
* we add a view B that shares a parent with view A in subsequent operation
* view A finally calls its callback after the animation is complete and removes itself from the native view hierarchy
A case that D14529038 would not fix:
1. we add a view B in one operation
2. we delete a view A in the same operation asynchronously because it's in a layout animation
3. ... etc.
What we must remember is that the index we use to add view B in step 1 is based on the indices assuming that all deletions are synchronous as this [comment notes](https://fburl.com/j9uillje): removals (both deletions and moveFroms) use the indices of the current order of the views and are assumed independent of each other. Whereas additions are indexed on the updated order (after deletions!)
This diff re-arranges the order in how we act upon the operations to update the native view hierarchy -- similar to how UIImplementation does its operations on the shadow tree here: https://fburl.com/j9uillje
By doing the removals and deletions first, we know that the addAt indices will be correct because either the view is removed from the native view hierarchy or `pendingIndicesToDelete` should be tracking an async delete already so the addAt index will be normalized
Reviewed By: mdvacca
Differential Revision: D15112664
fbshipit-source-id: 85d4b21211ac802183ca2f0fd28fc4437d312100
Summary:
This diff forces the eager initialization of some additional classes into FabricJSIModuleProvider.loadClasses().
This is a "hack" that will be removed in the near future
Reviewed By: JoshuaGross
Differential Revision: D15208977
fbshipit-source-id: 2e2c7856839b6c6888452800ef6da7f269e46735
Summary: When passing StateWrapper objects across the JNI, we were not ensuring that the Java objects would own the C++ state. This was initially done because I assumed that in Java, State would either be used immediately or discarded, so this wouldn't be unsafe. As it turns out, it makes sense in some cases to store the StateWrapper in Java and use it later, potentially even in other threads, so we need to make sure we maintain ownership of the C++ object from the Java object.
Reviewed By: shergin
Differential Revision: D15206194
fbshipit-source-id: a437d921ba00b194cf08bad80666bd99baf11d52
Summary: This diff implements encapsulating all time metrics in a single class for better extensibility and readability.
Reviewed By: JoshuaGross
Differential Revision: D15179835
fbshipit-source-id: 62bdf94435a0d37a87ad9bad613cc8e38043a235
Summary:
`CatalystInstanceImpl.cpp` now depends on `JSCallInvoker` and `JavaJSCallInvokerHolder`. Therefore, we need to correctly adjust the OSS builds to include these dependencies into the `libreactnativejni.so` file.
I made `ReactCommon/turbomodule/jscallinvoker` a static library `libjscallinvoker.a`. I then made `ReactAndroid/src/main/jni/react/jni`'s `libreactnativejni.so` depend on that static library. Also, because the Android NDK build system doesn't support header namespaces, I had to use the filesystem to simulate them. This is why all the `.cpp` and `.h` files for `JSCallInvoker` were moved to a `jsireact` folder.
Reviewed By: mdvacca
Differential Revision: D15194821
fbshipit-source-id: 0cee682e41db53d0619f56ad017d5882f6d554aa
Summary:
`TurboModuleManagerDelegate` is an abstract base class with the following API:
```
public TurboModule getModule(String name, ReactApplicationContext reactApplicationContext);
public CxxModuleWrapper getLegacyCxxModule(String name, ReactApplicationContext reactApplicationContext);
```
```
std::shared_ptr<TurboModule> getTurboModule(std::string name, jni::global_ref<JTurboModule> turboModule, std::shared_ptr<JSCallInvoker> jsInvoker) override;
std::shared_ptr<TurboModule> getTurboModule(std::string name, std::shared_ptr<JSCallInvoker> jsInvoker) override;
```
On the C++ side, when asked to provide a TurboModule with name `name`:
1. First, is this a CxxModule? If so:
1. Create the CxxModule and return
2. Otherwise:
1. Somehow get a Java instance of the TurboModule
2. If this Java object represents a CxxModule, like `FbReactLibSodiumModule`:
1. Grab the C++ part of this object, and wrap it in a `TurboCxxModule.cpp` and return.
3. Otherwise:
1. Wrap the Java object in a C++ HostObject and return.
This pseudocode demonstrates how we'd use `TurboModuleManagerDelegate` to implement `__turboModuleProxy`.
```
__turboModuleProxy(name, jsCallInvoker):
let cxxModule = TurboModuleManagerDelegate::getTurboModule(name, jsCallInvoker)
if (!cxxModule) {
return cxxModule;
}
// JNI Call that forwards to TurboModuleManagerDelegate.getLegacyCxxModule
let javaCxxModule : CxxModuleWrapper = TurboModuleManager.getLegacyCxxModule(name)
if (!javaCxxModule) {
return std::shared_ptr<react::TurboCxxModule>(javaCxxModule.getModule())
}
// JNI Call that forwards to TurboModuleManagerDelegate.getModule
let javaModule : TurboModule = TurboModuleManager.getModule(name)
if (!javaCxxModule) {
return TurboModuleManagerDelegate::getTurboModule(name, javaModule, jsCallInvoker)
}
return null
```
Reviewed By: mdvacca
Differential Revision: D15111335
fbshipit-source-id: c7b0aeda0e4565e3a2729e7f9604775782b6f893
Summary:
JSCallInvoker requires a `std::weak_ptr<Instance>` to create. In our C++, `CatalystInstance` is responsible for creating this `Instance` object. This `CatalystInstance` C++ initialization is separate from the `TurboModuleManager` C++ initialization. Therefore, in this diff, I made `CatalystInstance` responsible for creating the `JSCallInvoker`. It then exposes the `JSCallInvoker` using a hybrid class called `JSCallInvokerHolder`, which contains a `std::shared_ptr<JSCallInvoker>` member variable. Using `CatalystInstance.getJSCallInvokerHolder()` in TurboModuleManager.java, we get a handle to this hybrid container. Then, we pass it this hybrid object to `TurboModuleManager::initHybrid`, which retrieves the `std::shared_ptr<JSCallInvoker>` from the `JavaJSCallInvokerHandler`.
There were a few cyclic dependencies, so I had to break down the buck targets:
- `CatalystInstanceImpl.java` depends on `JSCallInvokerHolderImpl.java`, and `TurboModuleManager.java` depends on classes that are packaged with `CatalystInstanceImpl.java`. So, I had to put `JSCallInvokerHolderImpl.java` in its own buck target.
- `CatalystInstance.cpp` depends on `JavaJSCallInvokerHolder.cpp`, and `TurboModuleManager.cpp` depends on classes that are build with `CatalystInstance.cpp`. So, I had to put `JavaJSCallInvokerHolder.cpp` in its own buck target. To make things simpler, I also moved `JSCallInvoker.{cpp,h}` files into the same buck target as `JavaJSCallInvokerHolder.{cpp,h}`.
I think these steps should be enough to create the TurboModuleManager without needing a bridge:
1. Make `JSCallInvoker` an abstract base class.
2. On Android, create another derived class of `JSCallInvoker` that doesn't depend on Instance.
3. Create `JavaJSCallInvokerHolder` using an instance of this new class somewhere in C++.
4. Pass this instance of `JavaJSCallInvokerHolder` to Java and use it to create/instatiate `TurboModuleManager`.
Regarding steps 1 and 2, we can also make JSCallInvoker accept a lambda.
Reviewed By: mdvacca
Differential Revision: D15055511
fbshipit-source-id: 0ad72a86599819ec35d421dbee7e140959a26ab6
Summary: Convert FabricUIManager.measure params to floats. Currently we convert parameters to ints across the JNI boundary, and then back to floats several times in Java. This is unnecessary and actually makes measurements trickier. The new implementation uses floats across the JNI boundary and uses Float.POSITIVE_INFINITY to represent unconstrained values, which is consistent with Fabric C++ as well.
Reviewed By: shergin, mdvacca
Differential Revision: D15176108
fbshipit-source-id: cf849b3773007637f059279460163872f300a4aa
Summary: This new target provides dependencies for using folly futures
Reviewed By: willholen
Differential Revision: D15018282
fbshipit-source-id: c38ad4775102b9f0c10b3a52c5a18f00aa398322
Summary: This make iteration work better without needing to clean as much
Reviewed By: willholen
Differential Revision: D15018285
fbshipit-source-id: 034f5529e2e51711aeaa75360ad10bb1f85c7fb8
Summary:
The path to copy log_severity.h could refer to the
destination, which would result in an empty file being copied on some
rebuilds.
Reviewed By: willholen
Differential Revision: D15018283
fbshipit-source-id: 0081526a9686de8c74753738c165753de6dda18d
Summary:
When acquiring the `PARTIAL_WAKE_LOCK`, Android requires a tag to identify the source, normally the class name. This tag will show on dumpsys call and Google Play developer console.
`getSimpleName` will work fine as long as not enable ProGuard, in my case, it transformed the class name to just `"c"`, and I take my half day to find where the `c` comes from.
`getCanonicalName` will add the package path, which is more friendly for developers.
Later we can even let the developer choose the tag name, but this will require API break changes.
[Android] [Changed] - Use class canonical name for PARTIAL_WAKE_LOCK tag
Pull Request resolved: https://github.com/facebook/react-native/pull/24673
Differential Revision: D15164306
Pulled By: cpojer
fbshipit-source-id: fd65f9e5250c180b0053940b17877fe36af5d48b
Summary: The map of sComponentNames ONLY contains the names of components that are different between JS and Android. This diff adds a method to unify the way we use this map.
Reviewed By: shergin
Differential Revision: D15076549
fbshipit-source-id: 9df750dca305e55cb44037bc63f3ebb6476c8b81
Summary: Trivial diff that adds extra logging information on Exceptions that are thrown by the FabricViewTest
Reviewed By: shergin
Differential Revision: D14817899
fbshipit-source-id: 32e1d1fcd1292715dfcf2750d3f14c668927c8b8
Summary:
This diff fixes a bug that is reproducible when a view is reordered in a different level of hierarchy in the react tree.
Even if this is not supported by react, this can still happen because of viewFlattening.
Reviewed By: shergin
Differential Revision: D14817452
fbshipit-source-id: 13425b0e6a280affe681e80b4a6daa17ee56251a
Summary: This diff refactors the way we synchronize in ReactChoreographer using a lock object
Reviewed By: ejanzer
Differential Revision: D14913056
fbshipit-source-id: e86c4395d5d3c3fd5b7330b72c14920b536f74ce
Summary:
This fixes a regression on Android introduced by f3e5cce where JS errors thrown during bundle load were lost (shown only as UnknownCppException). It is especially tough to debug (custom) bundling errors without seeing the javascript error.
Root cause hypothesis: since switching to clang, `JSError`s thrown in ReactCommon's `JSCRuntime::checkException` were never matched as `std::exception` in ReactAndroid's `convertCppExceptionToJavaException` due to these missing flags.
I'm a bit shy on low-level details concerning how C++ rtti works exactly around catching exceptions thrown in other libraries. All I can say that with this change, a `bundle.android.js` that only contains `throw new Error("wtf");` now nicely outputs a message and stack trace in the logcat. Before (and since DanielZlotin's switch to clang) it just outputted:
```
2019-04-29 12:17:59.365 1162-1306/com.rntest E/unknown:ReactNative: Exception in native call
com.facebook.jni.UnknownCppException: Unknown
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:214)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
[Android] [Fixed] - JS errors during bundle load were reported as UnknownCppException.
Pull Request resolved: https://github.com/facebook/react-native/pull/24648
Differential Revision: D15123525
Pulled By: mdvacca
fbshipit-source-id: 74b5ce9ebae38d172446b6e31739d795c601947b
Summary:
Hello Everyone, this series of commits helps to fix problems related to ART on Android. The main problem in here is that the ART components would disappear if the user turns off the screen and then turn it on again. It's important to note that this behaviour only occurs after Android N (7.1 or higher).
Pull Request resolved: https://github.com/facebook/react-native/pull/22624
Differential Revision: D15122573
Pulled By: cpojer
fbshipit-source-id: e7fb8b9280b4c52562e3d0c1a89759d4d31cd53d
Summary:
On android when borderXColor is null it causes the app to crash with:
```
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: com.facebook.react.bridge.NoSuchKeyException: borderBottomColor
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:111)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:115)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:158)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.uimanager.ViewProps.isLayoutOnly(ViewProps.java:246)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.uimanager.NativeViewHierarchyOptimizer.isLayoutOnlyAndCollapsable(NativeViewHierarchyOptimizer.java:482)
```
Basically it is missing a `isNull` check on the props map before trying to access the value.
Fixes#22727
[Android] [Fixed] - Fix a crash when borderXColor is null
Pull Request resolved: https://github.com/facebook/react-native/pull/24640
Differential Revision: D15120182
Pulled By: cpojer
fbshipit-source-id: bc41da572f04d8abf733b5a4e94a74a0f40acda1
Summary:
Convert root Gradle script to Kotlin DSL, and cleanup. Currently, there is not much benefit or advantage over Groovy scripts, except IDE support and it'll cache compiled KTS scripts on first run.
[Android] [Changed] - Convert root Gradle script to Kotlin DSL, and cleanup.
Pull Request resolved: https://github.com/facebook/react-native/pull/24631
Differential Revision: D15120190
Pulled By: cpojer
fbshipit-source-id: 86691db5c7746e71bb243ebc263c1a3075ee9a9e
Summary:
This PR bumps Android Gradle Plugin to 3.4.0, which enables R8 shrinker by default and improves build performance significantly.
Disabled R8 for ReactAndroid because it'll strip out AndroidX and other libraries bundled in ReactAndroid.
[Android] [Changed] - bump Android Gradle plugin to 3.4.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24463
Differential Revision: D15107117
Pulled By: hramos
fbshipit-source-id: 35a03dc9955e889c9399faeaf9a862e0fc044fc4
Summary: 9079beda9b wasn't enough to blacklist the strings.xml files from FB infra. So this is a better workaround. According to https://developer.android.com/guide/topics/resources/string-resource the .xml file names doesn't really matter, so this shouldn't break the ability to get the string resource in code, like `R.strings.foo`.
Reviewed By: yungsters
Differential Revision: D15103303
fbshipit-source-id: 6d5174a8dc9598930670d35434e1494f9eaea059
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes DialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
**BREAKING CHANGE**: Brown field apps must extend FragmentActivity or its subclasses.
[Android] [Changed] - DialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23365
Differential Revision: D14021986
Pulled By: cpojer
fbshipit-source-id: b0ede60ef19cec48111a12701659a8bc1f66c331
Summary: These strings shouldn't be translated by FB system because each app has its own set of languages and/or translation outputs. We're keeping just values/strings.xml in the repo.
Reviewed By: cpojer
Differential Revision: D15087192
fbshipit-source-id: c4b6112f6dd010d317060ac6640b34e4b725c695
Summary:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary:
We are seeing crash reports that the webview is missing. In this case
it should fail gracefully so that a missing webview does not block
from using an app built with React Native.
The contains could also be changed to check for "webview" in general
to catch all webview related exception. It's currently checking on
for the specific string that I'm seeing in our app's crashreporting tool.
<img width="1507" alt="Screen Shot 2019-04-19 at 11 26 19 AM" src="https://user-images.githubusercontent.com/741767/56438307-5e1c2f80-6297-11e9-970b-a5095d18e9d7.png">
<img width="935" alt="Screen Shot 2019-04-19 at 11 32 58 AM" src="https://user-images.githubusercontent.com/741767/56438213-fa920200-6296-11e9-8008-5eb344eca8a8.png">
[Android] [Fixed] - The ReactCookieJarContainer/ForwardingCookieHandler now handles the missing WebView gracefully.
Pull Request resolved: https://github.com/facebook/react-native/pull/24533
Differential Revision: D15062824
Pulled By: cpojer
fbshipit-source-id: 80805a47494f0d924b7ee029ce8ca0504eaeee57
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
React Native Environment Info:
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 1.12 GB / 15.55 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 3.5.2 - /usr/bin/npm
SDKs:
Android SDK:
API Levels: 16, 19, 22, 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
npmPackages:
react: 16.8.6 => 16.8.6
react-native: git+https://github.com/facebook/react-native.git#v0.59.5 => 0.59.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
The workaround implemented in https://github.com/facebook/react-native/pull/21117 tries to fix
https://issuetracker.google.com/issues/112385925 scroll direction (according to the latest comments, the scroll direction problem has been reverted in security patches so not sure if the workaround is still valid).
But... proposed solution in fling method is using signum which leads to zero computedVelocityY in case of zero mOnScrollDispatchHelper.getYFlingVelocity() on old devices(Samsung s4 mini) even when real velocityY is non zero
```
final int correctedVelocityY = (int)(Math.abs(velocityY) * Math.signum(mOnScrollDispatchHelper.getYFlingVelocity()));
```
Proposed solution is to take signum from original velocityY in case of zero
```
float signum = Math.signum(mOnScrollDispatchHelper.getYFlingVelocity());
if (signum == 0) {
signum = Math.signum(velocityY);
}
final int correctedVelocityY = (int)(Math.abs(velocityY) * signum);
```
The symptoms are the same as described in issue https://github.com/facebook/react-native/issues/22925, but proposed workaround doesn't work.
[Android][fixed] - Fix smooth scrolling on old devices (SDK >=16)
Pull Request resolved: https://github.com/facebook/react-native/pull/24545
Differential Revision: D15044834
Pulled By: cpojer
fbshipit-source-id: 3f523eb1a438df774e22387aecded433b9031ab9
Summary:
If an app [builds from RN source](https://facebook.github.io/react-native/docs/building-from-source), there was an error for jsc-android not found.
It is a side effect of my previous [JSC as node dependency change](8e375850de)
For building from RN source case, the jsc-android is located at `/path/to/app/node_modules/jsc-android`.
Original gradle task will try to find it at `/path/to/app/node_modules/react-native/ReactAndroid/../node_modules/jsc-android`, as ReactAndroid project path was being override inside node_modules.
The change fixes the building from source case.
N/A
This change does not need to publish into changelog, as it is a master branch building fix.
Pull Request resolved: https://github.com/facebook/react-native/pull/24547
Differential Revision: D15044703
Pulled By: cpojer
fbshipit-source-id: a7d824b1a14064d46c4a2ec9ea28255179174c83
Summary:
libreactnativejni does not need to link against libjsc directly:
that library is only needed by libjscexecutor.
Reviewed By: mhorowitz
Differential Revision: D15017942
fbshipit-source-id: fb545c9127221dab28434321fe9c116fe72f7507
Summary:
`MountingTransaction` encapsulates all artifacts of `ShadowTree` commit, particularly list of mutations and meta-data.
We will rely on this heavily in the coming diffs.
Reviewed By: JoshuaGross
Differential Revision: D15021795
fbshipit-source-id: 811da7afd7b929a34a81aa66566193d46bbc34f8
Summary: It seems like ReactContext isn't actually needed in measure functions. Changing the signature of ViewManager.measure() to take a Context instead.
Reviewed By: lunaleaps
Differential Revision: D14940330
fbshipit-source-id: b29987fd1d7f9c191a5f26138151082ca61cb351
Summary:
React Native has a `NativeModule` to manipulate programmatically the dev menu options (live reload, hot reload, remote debugging, etc), called [`DevSettings`](https://github.com/facebook/react-native/blob/master/React/Modules/RCTDevSettings.mm#L120). However this module is only available for iOS.
This PR brings the same `DevSettings` for Android, making it a cross-platform NativeModule.
Motivation: Right now if your app needs to programmatically reload RN, one option is to install [`react-native-restart`](https://www.npmjs.com/package/react-native-restart). It's a tiny dependency, but it's annoying to have to install it, while the code to do so is inside RN codebase. According to NPM, react-native-restart has ~12k weekly downloads, shows it's a recurring feature for many apps (my case).
Thus making `NativeModules.DevSettings` is a small increment in the codebase, just exposing the dev menu methods, to improve the Development Experience
[Android] [Added] - Add DevSetting native module (making it cross-platform)
With expection of `setIsShakeToShowDevMenuEnabled`, the following methods will be available for both platforms:
* reload
* setHotLoadingEnabled
* setIsDebuggingRemotely
* setIsShakeToShowDevMenuEnabled
* setLiveReloadEnabled
* setProfilingEnabled
* toggleElementInspector
Pull Request resolved: https://github.com/facebook/react-native/pull/24441
Differential Revision: D14932751
Pulled By: cpojer
fbshipit-source-id: 465e6a89c3beb5fd1ea22e80ea02e9438f596a09
Summary:
In order to meet our accessibility requirements we need to have full support for keyboard navigation. The Touchable components works with press/tap with a finger, but doesn't respond to 'enter' when using a keyboard. Navigation works fine. This PR adds an onClick listener to touchable views that have the onPress prop defined.
[Android] [Added] - Add View.OnClickListener to Touchable components when onPress is defined
Pull Request resolved: https://github.com/facebook/react-native/pull/24359
Differential Revision: D14971230
Pulled By: cpojer
fbshipit-source-id: ca5559ca1308ee6c338532a00dcea4d00fa57f42
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:
@public
This allows short methods defined in class declarations to occupy a single line.
The change makes class declarations more readable.
Reviewed By: SidharthGuglani
Differential Revision: D14950012
fbshipit-source-id: 1321949475184181c6cceb86613f730e430763e2
Summary:
Would like feedback from the community as this may not be the best solution for all
I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.
This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.
To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature #21302 .
[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045
Differential Revision: D14939754
Pulled By: sahrens
fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
Summary:
For a small subset of Android devices, the following line of code caused the device to crash
```
output.transferFrom(input, 0, Long.MAX_VALUE);
```
According to the [Java docs](https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/FileChannel.html), this is what the function does.
> Transfers bytes into this channel's file from the given readable byte channel.
An attempt is made to read up to count bytes from the source channel and write them to this channel's file starting at the given position. An invocation of this method may or may not transfer all of the requested bytes; whether or not it does so depends upon the natures and states of the channels. Fewer than the requested number of bytes will be transferred if the source channel has fewer than count bytes remaining, or if the source channel is non-blocking and has fewer than count bytes immediately available in its input buffer.
Hence, using `Long.MAX_VALUE` seemed to be the standard way to transfer all bytes from one channel to the other.
However, it appeared that for some reason on a subset of old Android devices, the device tries to allocate `count` bytes of memory before transferring the bytes. Obviously, this caused a crash because no device has that much memory. This was fixed transferring bytes using a 1MB buffer.
Differential Revision: D14921778
fbshipit-source-id: 7fa46e10c656e23ae7d5679c72b278188f09ad0a
Summary:
Closes: https://github.com/facebook/react-native/issues/24016
React Native 0.57 introduced cross-platform `accessibilityRole` and `accessibilityStates` props in order to replace `accessibilityComponentType` (for android) and `accessibilityTraits` (for iOS). With #24095 `accessibilityRole` and `accessibilityStates` will increase, receiving more options, which seems to be a good moment to remove deprecated props.
Remove deprecated `accessibilityComponentType` and `accessibilityTraits` props.
[General] [Removed] - Remove accessibilityComponentType and accessibilityTraits props
Pull Request resolved: https://github.com/facebook/react-native/pull/24344
Reviewed By: rickhanlonii
Differential Revision: D14842214
Pulled By: cpojer
fbshipit-source-id: 279945e503d8a23bfee7a49d42f5db490c5f6069
Summary: Create views with props in one call instead of two. Backwards-compatible.
Reviewed By: shergin
Differential Revision: D14846424
fbshipit-source-id: cb53225579089f7e51d4e9d1fc9fc2e331a994c1
Summary: Similar to iOS, here we provide the basic impl of unimplemented view.
Reviewed By: mdvacca
Differential Revision: D14895706
fbshipit-source-id: 9053edfb2175b370d9070b6921794dbcafa1f37a
Summary:
Motivation is following - I'm sure many people encountered this because it has been like this for a long time.
1 . you're developing something on android, HMR and dev mode is enabled
2 . you go to dev settings, you disable dev mode because you want to see how something behaves
3 . you reload the app because that's what is required for the change to take effect
4 . you wait for the bundle to be compiled and served, and when that is done, you get an error message about HMR not being a registered callable module - because HMR is not available when `__DEV__ === false` (todo screenshot)
this fixes the described case by checking if HMR is enabled and dev mode disabled when reloading (step 3) and disables HMR in that case.
this also fixes the case when dev mode is disabled and without knowing it, you try to enable HRM (will enable both dev hmr and dev mode).
[Android] [Changed] - improve developer experience around Dev mode and HMR interop
Pull Request resolved: https://github.com/facebook/react-native/pull/24377
Differential Revision: D14890695
Pulled By: cpojer
fbshipit-source-id: 95b6ff4131c6d05a32aadd09a9d5ed11f602122c
Summary: Running animations sometimes fail in Android. we are ignoring those failures temporarly
Reviewed By: fkgozali
Differential Revision: D14884510
fbshipit-source-id: 66d6113e12b1bd67e8bcc564943b423825b4cea6
Summary: This diff adds extra debug information in the mounting manager
Reviewed By: shergin
Differential Revision: D14817456
fbshipit-source-id: 5619c94eb76cdc20f5d7767f1aa4263e63f8d021
Summary: This diff ensure that only views created by RN are taken into consideration for recycling.
Reviewed By: fkgozali
Differential Revision: D14874678
fbshipit-source-id: ea7dd5a0f29f6acf0dce8573fc77b012395476bd
Summary:
Android API 26 and Android Support Library 26 added support for font resource type and native/downloadable fonts. It allows apps to easily download fonts from online providers, but also use of various font weights other than normal and bold, like medium. So it deprecated APIs for asset fonts, and should be removed in the future.
Advantages:
- Just copy font files in res/font and use it specifying filename (without extension) in fontFamily
- Define custom font-family using XML file (in res/font) and font files, it may have many weights and styles. See PR for example.
- Define configuration to download fonts from online font providers, and use it.
See https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml and https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts
[Android] [Changed] - add support for custom/downloadable fonts
Pull Request resolved: https://github.com/facebook/react-native/pull/23865
Differential Revision: D14506542
Pulled By: hramos
fbshipit-source-id: 67ba3148fb4b548cdbc779213cf6c1b2c3baffd2
Summary:
This diff removes the copyToClipBoardMiddleware. This was exposing the /copy-to-clipboard endpoint that allowed unauthenticated access to writing to a developers clipboard.
This was only used in a single place, the Android red box dialog, so I've removed it from there.
Reviewed By: cpojer
Differential Revision: D14790813
fbshipit-source-id: 80e044eefd9658b8c5885643cdadf7947c00d34a
Summary: Remove dependency on ReactRootView in ReactInstanceManager by creating a rough interface (ReactRoot) so that either a Surface or ReactRootView can be attached to ReactInstanceManager.
Reviewed By: ejanzer, mdvacca
Differential Revision: D14158890
fbshipit-source-id: b7ab4654b1e0ef8343230a3c15023653a7f23a4b
Summary:
Fixes#22511
I understand the motivation of adding extraRadiusForOutline to corner radius: without it there can be an empty space between border and view's background color.
So I add simple check: if corner radius is more than zero we still add extraRadiusForOutline. And if not, we don't add it to prevent all the corners to become slightly curved.
[GENERAL] [Fixed] - fix of Android's bug that causes all the corners to become slightly curved if only specific corners' radius should be more than zero.
Pull Request resolved: https://github.com/facebook/react-native/pull/24390
Differential Revision: D14870476
Pulled By: cpojer
fbshipit-source-id: df40fc584a2f8badc499413cb3c4e4d96b9e18cf
Summary: This will simplify updating the JSI API from upstream in the future.
Reviewed By: mhorowitz
Differential Revision: D14762674
fbshipit-source-id: fa4a86f08425943e301da4ef3df9893ebaa1493e
Summary:
@public
compiler flags were pushed to C++14, but we don’t currently have any code that requires it. Setting to `-std=c++11` in order to fix the OSS build.
Reviewed By: SidharthGuglani
Differential Revision: D14833737
fbshipit-source-id: df2cd7da8c7124e89863c90d7b77bcf86c495618
Summary: Need to force the double thing in more places.
Reviewed By: cpojer
Differential Revision: D14835792
fbshipit-source-id: fb7a5435675b322d5fbbe9858e08804e9abe65db
Summary: Adding JNativeRunnable to exported headers in react/jni/BUCK so I can use it outside of CatalystInstance.
Reviewed By: axe-fb
Differential Revision: D14817655
fbshipit-source-id: 15aa794e50f273778da337956c887c235a5aec3d
Summary:
In #20288, we solved `com.facebook.react.uimanager.NativeViewHierarchyManager.dropView (NativeViewHierarchyManager.java:536)` by adding codes that prevent to run method on `view` object when `view.getId()` is null.
But if `view` is null, `view.getId()` can make error about NullPointerException. So, I think `dropView` method needs to check if `view` is null.
If you need more information, Please read #24346.
[Android] [Fixed] - Ignore dropView method when view is null.
Pull Request resolved: https://github.com/facebook/react-native/pull/24347
Differential Revision: D14833822
Pulled By: cpojer
fbshipit-source-id: 88b6a05090ea8e8d6737c1f10b40e93649fab151
Summary: Android plumbing for State and LocalData update mount items. See other commits in stack for usage
Reviewed By: mdvacca
Differential Revision: D14663522
fbshipit-source-id: 5604a6a9af292805e9ce46c68e5ce7472eef0218
Summary:
In origin approach, we packed libjsc.so inside react-native.aar and it is difficult for user to choose different JSC variants. E.g., [the Intl supported version](https://github.com/react-native-community/jsc-android-buildscripts#international-variant).
This change list allows application to determine JSC versions or variants by npm/yarn package.
There is a |useIntlJsc| flag in build.gradle, it will use the same JSC version but with Intl support.
`yarn add jsc-android@canary`
[Android] [Changed] - Allow application to select different JSC variants
**MIGRATION**
Note that there are some changes in build.gradle.
Existing application needs to change their android/build.gradle and android/app/build.gradle.
Hopefully, the rn-diff-purge should handle the case well.
Pull Request resolved: https://github.com/facebook/react-native/pull/24276
Differential Revision: D14752359
Pulled By: cpojer
fbshipit-source-id: a4bfb135ad8e328f404a2d1a062412f40ebf4622
Summary:
Since text and selection has dependency, handle text selection in
updateExtraData as well.
The root cause is due to setText is handled on extra data update but setSelection is handled on set property. And extra data update will be handled after all properties are handled. Since selection and text has dependency, move selection to extra data update as well.
Changelog:
----------
[Android] [Fixed] - Fix crash when set text and selection on textinput at the same time
Pull Request resolved: https://github.com/facebook/react-native/pull/22723
Differential Revision: D14783791
Pulled By: cpojer
fbshipit-source-id: a4065f3e151d23f4813d76e91d68362cfd4daaf4
Summary: We've identified a couple of remaining issues that need to be re-tested before we can ship this more broadly.
Reviewed By: fred2028
Differential Revision: D14775730
fbshipit-source-id: 22402149066c5fbe72c36fcf7f547d63feaf5241
Summary:
React Native on Android has currently been focused and targeted at using an [Activity](https://developer.android.com/reference/android/app/Activity.html) for its main form of instantiation.
While this has probably worked for most companies and developers, you lose some of the modularity of a more cohesive application when working in a "brown-field" project that is currently native. This hurts more companies that are looking to adopt React Native and slowly implement it in a fully native application.
A lot of developers follow Android's guidelines of using Fragments in their projects, even if it is a debated subject in the Android community, and this addition will allow others to embrace React Native more freely. (I even assume it could help with managing navigation state in applications that contain a decent amount of Native code and would be appreciated in those projects. Such as sharing the Toolbar, TabBar, ViewPager, etc in Native Android)
Even with this addition, a developer will still need to host the fragment in an activity, but now that activity can contain native logic like a Drawer, Tabs, ViewPager, etc.
**Test plan (required)**
* We have been using this class at Hudl for over a couple of months and have found it valuable.
* If the community agrees on the addition, I can add documentation to the Android sections to include notes about the potential of this Fragment.
* If the community agrees on the addition, I can update one or more of the examples in the `/Examples` folder and make use of the Fragment, or even create a new example that uses a native layout manager like Drawer, Tabs, Viewpager, etc)
Make sure tests pass on both Travis and Circle CI.
_To Note:_
* There is also talk of using React Native inside Android Fragment's without any legit documentation, this could help remedy some of that with more documentation included in this PR https://facebook.github.io/react-native/releases/0.26/docs/embedded-app-android.html#sharing-a-reactinstance-across-multiple-activities-fragments-in-your-app
* Others have also requested something similar and have a half-baked solution as well http://stackoverflow.com/questions/35221447/react-native-inside-a-fragment
[ANDROID][FEATURE][ReactAndroid/src/main/java/com/facebook/react/ReactFragment.java] - Adds support for Android's Fragment system. This allows for a more hybrid application.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/12199
Differential Revision: D14590665
Pulled By: mdvacca
fbshipit-source-id: b50b708cde458f9634e0c14b3952fa32f9d82048
Summary: Before D14297477, the pre-allocation of views was ONLY necessary when react was running in the JS Thread, this is because the batch of mount items used to contain mount items for creation of views. After D14297477, views are only created during pre-allocation, that means that pre-allocation of views need to be trated the same way independently the thread where it is running.
Reviewed By: shergin
Differential Revision: D14714933
fbshipit-source-id: 7bd19cd33b624a5b0daaafabb476bb06707eea17
Summary: A previous commit changed the signature of the Instance (the arg to JSCallInvoker) to be a weak ref, so this callsite needs updating.
Reviewed By: mmmulani
Differential Revision: D14757188
fbshipit-source-id: 1a8663e56a42b26c6202881c57a7caafa71da2ab
Summary:
@public
In order to get out of pre-releases again, we move `YGSetUsedCachedEntries` from `Yoga.h` to `Yoga-internal.h`.
This way, it’s obvious that the function is not public, and we can remove it from future versions without breaking semver contracts.
Reviewed By: SidharthGuglani
Differential Revision: D14726029
fbshipit-source-id: 8d7e747e843bf5c4b5e1d4cfbfa37ca9d240dffb
Summary: All animations are scheduled by the UIManager while it processes a batch of changes, so we can just wait to see what the longest animation is and cancel+reschedule the callback.
Reviewed By: mdvacca
Differential Revision: D14656733
fbshipit-source-id: 4cbbb7e741219cd43f511f2ce750c53c30e2b2ca
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: Add additional logging around the exception to figure out what kind of uris are causing the exception for `getContentTypeForFileName`
Reviewed By: PeteTheHeat
Differential Revision: D14715917
fbshipit-source-id: 46299d2ff3f1f06991d7800784a025a85815ae8c
Summary:
It seems that the content view can sometimes be null when onOverScrolled is called (presumably when the scrollview gets unmounted while it's in the middle of scrolling?).
Changelog: [Android][fixed] - Guard against content view being null in onOverScrolled.
Reviewed By: mdvacca
Differential Revision: D14737534
fbshipit-source-id: e88ec6f585e50517b734a8809fc3843c0b22df10
Summary: This moves the Java files to FB internal and updates all the buck files
Reviewed By: TheSavior
Differential Revision: D14622521
fbshipit-source-id: a8d293e9f9e08868cca3ed2986a08d0db16dec15
Summary:
Try to prevent the crash described in https://github.com/facebook/react-native/issues/17530
There seems to be a bug in `Drawable.mutate()` in some devices/android os versions even after you check the constant state. This error is hard to reproduce and to fix, so just try to catch the exception to prevent crash.
[Android][Fixed] Prevent random crash when setting underlineColorAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/24183
Differential Revision: D14710484
Pulled By: cpojer
fbshipit-source-id: 3af20a5cb0ecd40839beaf85118c0f5aa6905414
Summary:
Potential breaking change: The signature of ReactShadowNode's onBeforeLayout method was changed
- Before: public void onBeforeLayout()
- After: public void onBeforeLayout(NativeViewHierarchyOptimizer nativeViewHierarchyOptimizer)
Implements same feature as this iOS PR: https://github.com/facebook/react-native/pull/7304
Previously, only Text and Image could be nested within Text. Now, any view can be nested within Text. One restriction of this feature is that developers must give inline views a width and a height via the style prop.
Previously, inline Images were supported via FrescoBasedReactTextInlineImageSpan. To get support for nesting views within Text, we create one special kind of span per inline view. This span is called TextInlineViewPlaceholderSpan. It is the same size as the inline view. Its job is just to occupy space -- it doesn't render any visual. After the text is rendered, we query the Android Layout object associated with the TextView to find out where it has positioned each TextInlineViewPlaceholderSpan. We then position the views to be at those locations.
One tricky aspect of the implementation is that the Text component needs to be able to render native children (the inline views) but the Android TextView cannot have children. This is solved by having the native parent of the ReactTextView also host the inline views. Implementation-wise, this was accomplished by extending the NativeViewHierarchyOptimizer to handle this case. The optimizer now handles these cases:
- Node is not in the native tree. An ancestor must host its children.
- Node is in the native tree and it can host its own children.
- (new) Node is in the native tree but it cannot host its own children. An ancestor must host both this node and its children.
I added the `onInlineViewLayout` event which is useful for writing tests for verifying that the inline views are positioned properly.
Limitation: Clipping
----------
If Text's height/width is small such that an inline view doesn't completely fit, the inline view may still be fully visible due to hoisting (the inline view isn't actually parented to the Text which has the limited size. It is parented to an ancestor which may have a different clipping rectangle.). Prior to this change, layout-only views had a similar limitation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23195
Differential Revision: D14014668
Pulled By: shergin
fbshipit-source-id: d46130f3d19cc83ac7ddf423adcc9e23988245d3
Summary:
D14423742 introduced a regression on OSS test_android due to androidx.core.os not being available. I spent some time investigating a fix forward this morning, with no success. Reverting.
Changelog:
[Android] [Changed] - Revert 92f019c666
Reviewed By: cpojer
Differential Revision: D14668728
fbshipit-source-id: c7542992805551dc4302626e1536759794efaa82
Summary:
Add the ability to set a custom handler on ReactWebViewManager to handle client certificate challenges during TLS authentication.
[Android][Added] - Public method setCustomClientCertRequestHandler to the native com.facebook.react.views.webview.ReactWebViewManager, that allows using a custom response for client certificate challenges.
Reviewed By: mjhu
Differential Revision: D14609697
fbshipit-source-id: 567c95458af638d1f8233fc3ca0d9cefc061c2bf
Summary: Because it's kinda more logical and we will rely on this in comming diffs.
Reviewed By: mdvacca
Differential Revision: D14587124
fbshipit-source-id: 94ae9410b4ffeffd0fcb4da4a0518f0bb0d2ba63
Summary:
Using a config flag to switch between different implementations of transferring layout outputs
- YogaNodeJNI uses multiple access of java fields to pass all properties like width, height, margin etc...
- YogaNodeJNIBatching uses a float array to pass all the data in one java field access
Reviewed By: davidaurelio
Differential Revision: D14378301
fbshipit-source-id: 0da5b28e6a67ad8fd60eb7efe622d9b2deaf177f
Summary: This diff adds the logic to transfer layout outputs using a float array
Reviewed By: davidaurelio
Differential Revision: D14368120
fbshipit-source-id: d1f22283bcea051d15657f42c15b90edaa0a8a7a
Summary: This diff adds a test for reset method in YogaNodeJNI to verify all layout outputs are reset properly
Reviewed By: davidaurelio
Differential Revision: D14643926
fbshipit-source-id: fffbcd07ccb6d2df83fc0bf187d992ef194f3bd0
Summary:
Moved layout outputs transfer logic from YogaNodeJNIBase to YogaNodeJNI.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14642995
fbshipit-source-id: 5d0bc7fa18c1985be7e216d7351f5eab2e03861d
Summary:
Temporarily disable View Pooling in Fabric
Naming of classes will change in the near future
Reviewed By: JoshuaGross
Differential Revision: D14685009
fbshipit-source-id: 83573dd09af0202a67d0d0aa11e37c1660c3991f
Summary: With the recent change, JSCallInvoker now expects `Instance` to be passed in, not just the `MessageQueueThread`. There needs to be more plumbing to get the instance of `Instance` from the Java side, but this commit is just to unbreak the build temporarily.
Reviewed By: JoshuaGross
Differential Revision: D14687622
fbshipit-source-id: 42e0173ee8336fc5660fe8188a1e1f8517611521
Summary:
This diff fixes the scrolling of Android Horizontal Scroll View, the root cause was that Binding was mounting a ScrollView instead of an AndroidHorizontalScrollView component.
This will be automatically fixed when all the View components are autogenerated.
Reviewed By: shergin
Differential Revision: D14594622
fbshipit-source-id: 7c477ca167188ea9c473f61145461d3cf1696e17
Summary: Simple diff that refactors the usage of the sComponentNames to not require components to be part of the mapping when the name in JS is the same as the name in Native side.
Reviewed By: shergin
Differential Revision: D14594659
fbshipit-source-id: d1948b27e04686fefbf9b6e2b06d4f9317b97062
Summary: Adds debug logging in FabricUIManager and the mounting layer of Fabric.
Reviewed By: shergin
Differential Revision: D14594521
fbshipit-source-id: a5c0ee39e1bac8a340849ca3e044694cbee5427e
Summary: This diff exposes the collapsable prop as part of LayoutShadowNode, fixing the bug of the collapsable prop being filtered by JS in Fabric
Reviewed By: shergin
Differential Revision: D14594522
fbshipit-source-id: a892ba8228e76f11232acc6fe5c8d75e991d8fc6
Summary:
This diff removes the `WebView` export from React Native. Internally, we are requiring `WebView` directly now and externally people will have to use the community maintained module. This diff does not yet move the WebView files from the repo, this will happen in a follow-up.
Note that I had to remove a test for Cookies that displayed data in a WebView. I don't think there is an easy way to retain this (debugging) information that likely very few people ever take a look at so I think it is fine.
Reviewed By: TheSavior
Differential Revision: D14613077
fbshipit-source-id: b1d412f970d09d7d70ecac2c23e62cfdd09d7c8e
Summary:
Add the ability to build on top of the OkHttpClient.Builder by defining a lambda that gets called on network requests
[Android][Added] - Public method `setCustomClientBuilder` to the native `com.facebook.react.modules.network.NetworkingModule`, that allows customizing the OkHttpClient per-request for greater control over HTTP requests.
Reviewed By: hramos
Differential Revision: D14288613
fbshipit-source-id: 34df0ff3e18eeea1d565ccfcf97408379900120b
Summary:
I was working to use more Android Support Library in RN core, but wasn't able to finish it. So this PR is for only Systrace and TraceCompat only.
[Android] [Changed] - Use TraceCompat in Systrace
Pull Request resolved: https://github.com/facebook/react-native/pull/23780
Differential Revision: D14423742
Pulled By: hramos
fbshipit-source-id: e3c3e2dfd95eac3d2484313f9be69df1c85904cf
Summary:
We want the ability to use Linkify on android text elements. This only adds this property to Text and not TextInput since there are some functional differences with how the types could be used between iOS and android - iOS allows one or many types while Linkify restricted us to providing only one option (using the masks).
Performance is affected ONLY FOR TEXT ELEMENTS USING THIS FEATURE since Linkify is searching for patterns.
Pull Request resolved: https://github.com/facebook/react-native/pull/19216
Differential Revision: D14621883
Pulled By: cpojer
fbshipit-source-id: cb692021d314140b9a92b29e23384afd7fd1b09e
Summary: This diff fixes a NoSuchElementException that was being thrown at ReactChoreographerDispatcher.doFrame(). The root cause was a lack of syncronization in removeFrameCallback().
Reviewed By: shergin
Differential Revision: D14619386
fbshipit-source-id: 80bc9e44866218d2a8703b3186f6958c145f260b
Summary:
[Android] [Fixed] - LayoutAnimations cause invalid view operations
The dating team has found a consistent repro where following an order of steps will get you the following exception:
https://lookaside.facebook.com/intern/pixelcloudnew/asset/?id=2113362972287761
The exception is due to the fact that the following operation
`delete child tag 17 from parent tag 481 which is located at index 2`
cannot be performed because parent tag 481 only has 2 children.. and they also happen to not have the tag 17 as a child. Somehow the operations and the tree they act upon are out of sync.
RN receives operations from React via the native module `UIManagerModule`. The operations use tags (an identifier for a view) and indices to determine what view is updated. These operations (grouped together as a batch) are then passed to the UI thread where we perform them on the platform views.
LayoutAnimations are implemented per batch in RN. When LayoutAnimations are on, qualified view updates are animated. Because the delete operation is animated, RN doesn't remove the view from the platform view hierarchy immediately but asynchronously -- after the animation is complete. This is problematic for other view operations that rely on an index on where to insert or delete a view because during the creation of those operations, it was assumed all prior operations were performed synchronously.
This is what was occurring in the repro and there were silent view errors occurring before the exception was thrown.
This diff proposes a solution to track all pending delete operations across operations.
We introduce a map that is keyed on view tags and has a value of a sparse array that represents child index -> count of views that are pending deletion.
`{11: [0=1], 481: [2=1]}` where this would be interpreted as for index 0 under view tag 11, there is one async view deletion that has not completed and under tag 481 there is one async view deletion at index 2.
We use the map to adjust indices on add / delete operations. We also update the count when the deletion animation is complete and remove the tag from the map when it is deleted.
Regarding worst case sizing of the map => O(# of platform views rendered)
Reviewed By: mdvacca
Differential Revision: D14529038
fbshipit-source-id: 86d8982845e25a2b23d6d89ce27852fd77dbb060
Summary:
Allow interpolation of strings with useNativeDriver. This allows animating much more of react-native-svg. This PR adds support for native animation of lengths with units, path data, colors etc. Plus, fixing the redundantly created nodes and (and thus, previously incorrect) connection of native animated nodes, improving performance.
Docs will need to change, specifying that string interpolation works with the native driver as well.
[GENERAL] [Added] Add support for native driven string interpolation in Animated
[GENERAL] Fix exception: Expected node to be marked as "native"
[GENERAL] Fix connection of AnimatedNodes and creation of redundant AnimatedNodes
Pull Request resolved: https://github.com/facebook/react-native/pull/18187
Differential Revision: D14597147
Pulled By: cpojer
fbshipit-source-id: 82a948a95419236be7931a8cc4ff72f41e477e9c
Summary:
Moved layout outputs transfer logic from YogaNodeJNIBase to YogaNodeJNI.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14368107
fbshipit-source-id: 75ca330c1e7f07adc0ab8e7a5927d93977088918
Summary:
setNativeProps ends up calling UIManager.updateView which fails to find the view tag in the Paper UIManager and crashes.
This diff simply checks if the tag is managed by fabric, and calls `fabricUIManager.synchronouslyUpdateViewOnUIThread` if it is.
Not the ideal fix, but it generally works (js-driven animations work as well as in Paper) and it's better than crashing or not working at all.
Reviewed By: JoshuaGross
Differential Revision: D14414523
fbshipit-source-id: 0acd404f55094f8ce8eda39cb87ab58c727fb068
Summary: Removes useArrayNativeAccessor and everything needed to support it, similar to D14486283
Reviewed By: mdvacca
Differential Revision: D14487244
fbshipit-source-id: 7cfa91f7cf322c648c82be5951f3622cd6468961
Summary:
This was quite a rabit hole of remove deps -> delete dead code -> repeat.
Waaay simpler now with less duplicate lookups, redundant type verification, and extra function calls.
Reviewed By: mdvacca
Differential Revision: D14486283
fbshipit-source-id: 035db30181755d046a1ae99760468b954b2449df
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 fixes an IllegalStateException that is thrown when the user click is on a edit text and tap 'Next' on the keyboard to focus on the next view, but the next view is hidden.
Reviewed By: lunaleaps, mmmulani
Differential Revision: D14598410
fbshipit-source-id: 2999cc468ed24bedff163eedcfaec50f6ee005d6
Summary: This is based on the work done in D8686586. Removed the logger instance from JSIExecutor constructor and installed it into the runtimeInstaller at all call sites.
Reviewed By: mhorowitz
Differential Revision: D14444120
fbshipit-source-id: 0476fda4230c467573ea04102a12101bcdf36c53
Summary: This diff removes BatchedExecutionTime from the metrics that are measured in Fabric. This does not add much value and it is not easy to compare against current version of RN
Reviewed By: shergin
Differential Revision: D14541976
fbshipit-source-id: c488e0951815306a978dd7a4246ec8a16d663218
Summary:
@public
After changing native methods to return `long` rather than `YogaValue`, we switch them to JNI fast calls, as there is no more interaction with the Java GC.
Reviewed By: pasqualeanatriello
Differential Revision: D14576815
fbshipit-source-id: b5a33caef7343ba1de3d9634a50dc82ab3148cc7
Summary:
@public
Passing primitive data via JNI is more efficient than passing objects.
Here, we avoid creating `YogaValue` (Java) instances via JNI, and rather pass a `long` back to Java. The instance is then created by extracting the necessary bytes on the Java side.
Reviewed By: foghina
Differential Revision: D14576755
fbshipit-source-id: 22d09ad50c3ac6c49b0a797a0dad639ea4829df9
Summary:
@public
Moving all native methods in a single class provides the benefit of not having to load native bindings eagerly when just creating config objects in the startup paths, or setting Java-only values on them.
Loading native bindings triggers additional class loads (`YogaConfig` / `YogaNode`), and can lead to problems in multi-dex scenarions.
Reviewed By: pasqualeanatriello
Differential Revision: D14560658
fbshipit-source-id: 14e31e3c3b560675b5a752a38ae75ab80a565ea1
Summary:
It crashes with IllegalStateException in case you pass a wrong URL.
It crashes if it meets unexpected symbols in the header name and value,
while standard says it is not recommended to use those symbols not that
they are prohibited.
The headers handing is a special use case as a client might have an auth token in the header. In this case, we want to get 401 error response
from the server to find out that token is wrong. In case of the onerror
client will continue to retry with an existing token.
[ANDROID][Fixed] - Networking: Passing invalid URL not crashes the app instead onerror callback of HttpClient is called. Invalid symbols are stripped from the headers to allow HTTP query to fail with 401 error code in case of the broken token.
Pull Request resolved: https://github.com/facebook/react-native/pull/21231
Reviewed By: axe-fb
Differential Revision: D10222129
Pulled By: hramos
fbshipit-source-id: b23340692d0fb059a90e338fa85ad4d9612275f2
Summary:
@public
Yoga's Java license headers were not in the correct format.
Reviewed By: muraziz
Differential Revision: D14541087
fbshipit-source-id: 5b3cff398875bd59dadeaddbb43020700ef027e2
Summary:
Google recommends to use Gravity.START and Gravity.END instead of Gravity.LEFT and Gravity.RIGHT to support RTL better.
[Android] [Changed] - Improve RTL support
Pull Request resolved: https://github.com/facebook/react-native/pull/24069
Differential Revision: D14541569
Pulled By: cpojer
fbshipit-source-id: 5c104d8bd666e1270d5410216c7f2efa6152692a
Summary:
Added a child class of YogaNodeJNIBase which will be used to separate layout outputs transfer logic.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14368098
fbshipit-source-id: e0f10fb61cd09ee47cf9ce41fb400f4cfb3dd795
Summary:
@public
Contexts of nodes only hold a bit mask after we got rid of weak JNI refs.
We can simply store that data in a pointer-sized unsigned int.
Here, we replace all context heap allocations with usage of the node context (`void *`) as bitmask. We also add a couple of utility operators in order to keep the code comprehensible.
Reviewed By: fabiomassimo
Differential Revision: D14425742
fbshipit-source-id: f32c2184a1f09268c39dbb8cd09ac96517339674
Summary:
Renamed class from YogaNodeJNI to YogaNodeJNIBase.
This change set is for adding experiment for layout outputs batching using a float array where we will have two separate classes which will override how layout outputs are transferred to java YogaNode object.
We needed two separate classes because having everything in one class was causing memory issues as both the individual fields for width, height etc. and float array for batching needs to be present in code.
Reviewed By: davidaurelio
Differential Revision: D14368069
fbshipit-source-id: 0e98e28c8c7a9788345ccb92b2cd0f2cd4a53525
Summary: Refactor the fix from d4aa1e7a52 into something that follows the same convention used in 36957dcedd
Reviewed By: mdvacca
Differential Revision: D14485427
fbshipit-source-id: e6118284fcffa4b43c8392c94991764a07094403
Summary:
There is a small gap in the SynchronizedWeakHashSet implementation - the containsKey method of the WeakHashMap is modifying hence calling it during the iteration might cause ConcurrentModificationException. Added a command DO_IF_CONTAINS to safely handle this case.
[Android] [Bugfix] - Should fix a ConcurrentModificationException in onResume.
Pull Request resolved: https://github.com/facebook/react-native/pull/24015
Reviewed By: mdvacca
Differential Revision: D14507342
Pulled By: fkgozali
fbshipit-source-id: 2998bffb06e2cbacd8df1780964355842b1cc4a0
Summary:
Use AndroidX in ReactAndroid/build.gradle, and remove androidx dependency from template and RNTester app because it's already exposed/exported from ReactAndroid.
[Android] [Changed] - Land AndroidX in gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/24014
Differential Revision: D14508774
Pulled By: mdvacca
fbshipit-source-id: c96b97876571a5a7f2b400dd29188cfdf1f84a4c
Summary:
Currently, the behavior of saving in the `CameraRoll` module varies depending on the platform.
On iOS, remote URIs are supported and will save a remote image to the local storage. However, on Android it can only be used for local images, making this function much less useful.
This change allows the Android version of the `CameraRoll` module to have the same behavior, at least for http and https scheme URIs, which will probably cover the vast majority of the use cases.
Reviewed By: sahrens
Differential Revision: D14483943
fbshipit-source-id: e63ca786240e6657c8c8e0292be9fb08efa40ef1
Summary:
This PR adds support to use Conscrypt as Security Provider if available runtime. Consscrypt supports TLS 1.2 on Android 4.x and TLS 1.3 on all Android versions. Fixes issues (ex https://github.com/facebook/react-native/issues/23151) with HTTPS connections on Android 4.x.
Just add below to your project build.gradle and it'll use it.
```gradle
implementation('org.conscrypt:conscrypt-android:2.0.0')
```
[Android] [Changed] - Add TLS 1.3 support to all Android versions using Conscrypt.
Pull Request resolved: https://github.com/facebook/react-native/pull/23984
Differential Revision: D14506000
Pulled By: cpojer
fbshipit-source-id: 58bf18f7203d20519fb4451bae83f01e2f020a44
Summary:
This fixes#23816, which states that `getSize()` does not function correctly on Android. The original PR for this is now outdated as there have been merges into master that would create merge conflicts.
[Android] [Fixed] - Added correct handling for `getSize()` to avoid warnings being thrown.import
Pull Request resolved: https://github.com/facebook/react-native/pull/23961
Differential Revision: D14505183
Pulled By: cpojer
fbshipit-source-id: 3d8976fd518de0903d7736a8cbd8371987eb1b2d
Summary:
This will create a cross-platform and safe way to programmatically open the app's settings into the iOS /Android Settings app.
Right now it's possible to open the app's settings, but _**only for iOS**_ via `Linking.openURL("app-settings:")`
To do the same for Android, you need to either create NodeModule or install a dependency such as [react-native-open-settings](https://github.com/lunarmayor/react-native-open-settings).
Why this new method is useful: since Android 6, app permissions work similar to iOS. It's granular and it's requested in the app runtime.
https://developer.android.com/guide/topics/permissions/overview#runtime_requests_android_60_and_higher
> If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the user isn't notified of any app permissions at install time. Your app must ask the user to grant the dangerous permissions at runtime. When your app requests permission, the user sees a system dialog telling the user which permission group your app is trying to access. The dialog includes a Deny and Allow button.
Thus, if the user checks the **"Never ask again box"** and taps **"Deny"**, for some specific permission, the only way to change the permission is going to the Android Setting app.
And that's where this new method becomes useful. It'll allow our apps to programmatically send the the user to settings app.
Also, `openSettings()` doesn't receive a parameter to redirect to specific subsections of the Settings app because there's no public API to do it on iOS ([there's a way to have, via private API, but it causes the app to get rejected.](https://github.com/mauron85/cordova-plugin-background-geolocation/issues/394))
Create `Linking.openSettings()` for iOS and Android;
[General] [add ] - Add openSetting method to Linking module
Pull Request resolved: https://github.com/facebook/react-native/pull/23965
Differential Revision: D14502910
Pulled By: cpojer
fbshipit-source-id: d27d62282b9df499845c78d983d3b6936c36ea39
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:
fixes#23962, where trackColor is reset when value changed. This PR will set trackColor corresponding trackColor every-time value changes.
[Android] [Changed] - Fix Switch trackColor
Pull Request resolved: https://github.com/facebook/react-native/pull/23977
Differential Revision: D14495206
Pulled By: hramos
fbshipit-source-id: d712f540cd3f8359d6e85f79c12732689870a112
Summary:
Upgrade mobile `BUCK` and `.bzl` files to use C++14.
Let's see what happens.
Reviewed By: mzlee
Differential Revision: D14223329
fbshipit-source-id: ff642ca017103d9415c4d7f5beaf5ded07ef7ff1
Summary: JS Deltas have been killing productivity of RN engineers lately. There's been several posts and questions asked that end in "Turn off JS Deltas". Disabling them until we can make them more stable.
Reviewed By: fkgozali
Differential Revision: D14491774
fbshipit-source-id: 29b1c8e5e72369882c2890e3b6347ecd2fe4bed1
Summary:
Autofill Hints were added in [Android API 26](https://developer.android.com/reference/android/view/View.html#setAutofillHints(java.lang.String...)). Without this runtime check, pre-26 devices will crash.
[Android][Fixed] - Fixes crash on pre-26 Android devices when setting text content type
Reviewed By: lunaleaps
Differential Revision: D14479468
fbshipit-source-id: 238c1efd6aea682a93ecb45e1123aaed6bdcd9e3
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Summary:
Moved all layout outputs fields which are set always on yoga node java object.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14355025
fbshipit-source-id: 371d9c49fcb631efa8a79b62f8051ba5a17c232c
Summary: These constants are used for setting bit fields so they should be in power of 2
Reviewed By: davidaurelio
Differential Revision: D14384999
fbshipit-source-id: fa1f6994c874aff7a039ca98d5947cba317fa749
Summary:
…ake sure Android does not crash from bad params when using useNativeDriver
Android apps crash when using Animated useNativeDriver: true and the toValue is not a number. See issue here with test case. [Issue](https://github.com/facebook/react-native/issues/23810)
[Android] [fixed] - Fix crash when using Animated with useNativeDriver and a non Number toValue
Pull Request resolved: https://github.com/facebook/react-native/pull/23812
Differential Revision: D14436113
Pulled By: cpojer
fbshipit-source-id: 89fb3180c08cc5ffb817b3984dacda0a80b4f703
Summary:
This adds new functionality to the `Image` component by allowing you to retrieve the width and height of an image just like you'd do with [`Image.getSize`](https://facebook.github.io/react-native/docs/image.html#getsize) but _with_ the ability to provide headers to your request.
Why would you need this you ask? Well, imagine that you have an image that you're loading into your `Image` component that is protected and you get access by using a token in a header (or something similar). That would work. However, getting the dimensions isn't possible since you can't provide those same headers.
This is something that is bothering me when using a third-party library (https://github.com/archriss/react-native-image-gallery) and instead of implementing this just for that single library I imagined that it would be useful for anyone else that needs to get the image dimensions before displaying it.
[Android] [Added] - Added Image.getSizeWithHeaders
[iOS] [Added] - Added Image.getSizeWithHeaders
Pull Request resolved: https://github.com/facebook/react-native/pull/18850
Differential Revision: D14434599
Pulled By: cpojer
fbshipit-source-id: 56d5e58889ddf7ddc12d5f6f7d9dc6921fa17884
Summary:
@public
Removes the configuration field to avoid weak JNI refs. It is no longer used.
Reviewed By: marco-cova
Differential Revision: D14424594
fbshipit-source-id: f0877022615a11ac5079354e0977c6893b7d58d7
Summary:
@public
Completely removes the usage of weak JNI refs.
This is great, because node allocation and deallocation no longer go through a VM-global lock to access the weak reference table.
This is also great, because we can no longer overflow that ref table.
Performance is comparable to weak refs.
Reviewed By: marco-cova
Differential Revision: D14423068
fbshipit-source-id: 62003d2d6fd971e91460a26fb3477046f26e2ba5
Summary:
Right now we have a raw pointer to the js runtime in Java and we pass that to EventBeatManager's constructor; this diff adds a setter for the runtime ptr and removes it from the member initializer list, so that you can set it later from cpp instead.
Q: Should I just rewrite this to use RuntimeExecutor instead?
Reviewed By: shergin
Differential Revision: D14318893
fbshipit-source-id: 1221dd5959927967bad870f15c901c15e5455874
Summary: Easy cleanup of commented code in TextLayoutManager, I kept the TODOs to complete the code in the future
Reviewed By: shergin
Differential Revision: D14372356
fbshipit-source-id: ff87f9b09e9f40ed021256f463e39299467b3e0e
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:
@public
GCC up until v7 flags our way of reading edges in `YGNodeSetStyleInputs` as unused variables. I managed to work around that by rearranging the casts a bit.
Reviewed By: SidharthGuglani
Differential Revision: D14299439
fbshipit-source-id: eec0266185504d1b790b9ef574bd4a83c0059d3a
Summary:
@public
Moves all Java classes used from C++ to their own header + implementation file. In `YGJNI.cpp`, we only call methods on these objects deriving from `jni::JavaClass`.
This is only a bit of cleanup, no functional change.
Reviewed By: SidharthGuglani
Differential Revision: D14261043
fbshipit-source-id: 2db1d81cb7f56a4cdc24b182b2166e1d7e24ba3c
Summary:
Now that pre-allocation of views update props, we can just force the execution of "pre-allocation" instead of "create" mount item.
This diff removes the methods that were used by view creation
This way we reduce the amount of mountItems that are created during commit phase.
This should improve TTI (I'm running a MobileLab)
Reviewed By: shergin
Differential Revision: D14297477
fbshipit-source-id: a100bab798467e9f0fa9773e0206ba1ded472298
Summary:
Now that pre-allocation of views update props, we can just force the execution of "pre-allocation" instead of "create" mount item.
This diff adds systraces to the execution of pre-mountItems during commit
This should reduce the amount of mountItems that are created during commit phase.
This should improve TTI (I'm running a MobileLab)
Reviewed By: shergin
Differential Revision: D14297478
fbshipit-source-id: d8e515d34cf6edacce53c0903f74a08029259f6f
Summary:
Now that pre-allocation of views update props, we can just force the execution of "pre-allocation" instead of "create" mount item.
This should reduce the amount of mountItems that are created during commit phase.
This should improve TTI (I'm running a MobileLab)
Reviewed By: shergin
Differential Revision: D14297476
fbshipit-source-id: 3ade662848ed836dc3221abe78611bb4a2b94e00
Summary:
Cleaning up <android/log.h> from includes
We use LOG
```
LOG(INFO) << "message";
```
to log
Reviewed By: shergin
Differential Revision: D14297264
fbshipit-source-id: 1a9a760a092b6947cca7d7d59b66c574b3e41ad8
Summary: This diff removes the "isLayoutable" parameter from SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation. This now can be infered from the shadowView parameter
Reviewed By: shergin
Differential Revision: D14296481
fbshipit-source-id: b200504f9c2bef41f0a70257f1f5a274fbe97cbb
Summary:
Update Props during pre-allocation avoiding re-updating the same props during mounting
MobileLab test showed an improvement of:
MARKETPLACE_YOU_TTI_SUCCESS: -3.34% = 58ms
Reviewed By: shergin
Differential Revision: D14252170
fbshipit-source-id: 1f4e9ad5dcecbc06651fa065135ffeed4892d984
Summary: This diff introduces the concept of "updateProps" as part of InsertMutation and it changes the diffing algorithm to populate this field.
Reviewed By: shergin
Differential Revision: D14289608
fbshipit-source-id: 642f00d03d294a12ea7fa7482c72e701b756f3d4
Summary:
Before only the props of Images components were being applied during the pre-allocation phase.
Now that we have a limit of time that pre-allocations will be executed we can update props for any component
Reviewed By: shergin
Differential Revision: D14252171
fbshipit-source-id: afea4b71a32b7ae2c184b0cdce97f778bc3a47d2
Summary: This diff implements a limit on the execution of pre-allocation of views, taking into consideration the time it is left on the frame, with a maximum of 8 ms / frame
Reviewed By: shergin
Differential Revision: D14252172
fbshipit-source-id: 1780a489122a8bc476d6ec7c92b45fdc58993e1d
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
This was originally landed in D14214844 and then backed out in D14247897
Reviewed By: shergin
Differential Revision: D14286232
fbshipit-source-id: 8437f57f9473eb22ef98d80531b4020ee5fbb9ae
Summary: `YGConfigContext` was using `global_ref` instances for the config, leading to the config object never being freed. Since we no longer need it after getting rid of cloning, we can make the context a pointer to a `global_ref` to the logger.
Reviewed By: SidharthGuglani
Differential Revision: D14258571
fbshipit-source-id: cce632499839a680eef00a3854f61ab74ae2a87a
Summary: Flesh out how surface will be used with a flag in ReactRootView
Reviewed By: mdvacca
Differential Revision: D14112897
fbshipit-source-id: adf6078048dbf83452d3523f0530a4d6dca7b3e8
Summary:
We set flags to true when setting margin, padding, border, position individually
Doing the same for batching API
Reviewed By: davidaurelio
Differential Revision: D14207550
fbshipit-source-id: ddfdcd5056bea0dd76bd6762f47e90370e26c9e1
Summary:
Added a new API `YGNodeSetLayoutStyleInputs` to pass layout style inputs from java to native code.
All the style inputs are passed in a float array in [key1, key2, value2, key3, value3a, value3b .....] format over JNI layer.
There are three types of style inputs
- do not need any value to be passed along with them like WidthAuto, HeightAuto
- need one value to be passed like Width, Height
- need two values to be passed like Margin, Padding (edge value and actual margin, padding value)
Reviewed By: davidaurelio
Differential Revision: D14166948
fbshipit-source-id: 4bea64d6a429959c3962c87e337914dcd99199fd
Summary:
We have now create a yoga node context which consists of weak reference to java yoga node object and flag which tells us whether margin, padding , border are set or not.
This flag was initially in java layer and we have moved this to native layer as it will help us with enabling the bacthing API for setting style inputs.
Reviewed By: davidaurelio
Differential Revision: D14243378
fbshipit-source-id: fed935ef18c1abf2b07e5d69d9ca79ced51699f2
Summary: We are now not setting flags when we set style inputs margin, padding, border and position on yoga node.
Reviewed By: davidaurelio
Differential Revision: D14224000
fbshipit-source-id: deef4c1ab1a60fbc4909183bc2aa59fa23939d43
Summary:
`Platform.isTesting` returns false when running SSTs. This diff changes that to true.
See https://our.intern.facebook.com/intern/qa/9690/how-to-detect-when-running-as-sst for inspiration.
I fixed this for iOS in D13981728.
Reviewed By: cpojer
Differential Revision: D14244606
fbshipit-source-id: ed95b772cc4206cf7c835aed7415aa5fc5fbdf7d
Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary:
This is a back-out of D14214844, we noticed that this regressed TTI for Marketplace You screen running in Fabric
Original commit changeset: b81005f2bf49
Reviewed By: JoshuaGross
Differential Revision: D14247897
fbshipit-source-id: de0cea92b437b2fbcd075f0d6a0066156800e3f0
Summary:
@public
The cloning features of YogaNode don’t seem to be used. Let’s remove them.
Reviewed By: SidharthGuglani
Differential Revision: D14165624
fbshipit-source-id: 5b710964a4abf1b35f3bcc25b143ffc719a03cec
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Summary: Due to the way (initial) surface implementation plays with ReactRootView (RRV), the react tag from the UIManagerModule is now set on the surface container view rather than on RRV as it was historically done. RRV still caches the react tag but just doesn't use it as an id on the view so `RRV.getViewId()` no longer equals `RRV.getReactTag()`.
Reviewed By: mdvacca
Differential Revision: D14110104
fbshipit-source-id: 6dbcc41c85fd7a6c32c7250f68f4a84bed4e075a
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
Reviewed By: shergin
Differential Revision: D14214844
fbshipit-source-id: b81005f2bf494f62f421dc24846e1561e13b9a87
Summary:
This mechanism is heavily abused inside of the react-native and inside of the various native modules.
The main problem is that people don't remove their listeners and as result, we have memory leaks.
Some modules like UIManager, NativeAnimatedModule have resources holding Activity context. Those modules are held through a pretty long chain of dependencies.
In order to allow GC to collect those listeners, I replaced the CopyOnWriteSet by WeakHashMap and synchronized access. It is not such a big deal in terms of performance as those listeners are not called/modified too frequently but this prevents hard to debug memory leaks.
Changelog:
----------
Help reviewers and the release process by writing your own changelog entry. When the change doesn't impact React Native developers, it may be ommitted from the changelog for brevity. See below for an example.
[Android] [Fixed] - ReactContext - lifecycle listeners don't cause the leaks even if not removed.
Pull Request resolved: https://github.com/facebook/react-native/pull/22318
Reviewed By: mdvacca
Differential Revision: D13106915
Pulled By: hramos
fbshipit-source-id: d506e5035a7f7bea1b57a6308fb5d9b5fcb277a7
Summary:
Signed-off-by: yukai <yk3372@gmail.com>
In some Android device such as Samsung S8, the ModalHostView's child view can't fill the screen.
before:
The JS ModalHostView can't fill the bottom, the area is device's navigation bar.
In class ModalHostShadowNode, follow code calculate is error:
`Point modalSize = ModalHostHelper.getModalHostSize(getThemedContext());`
This way not care the device's navigation bar, so the height is smaller than real.
For Samsung S8, real height is 2220 and modalSize.y is 2076.
Pull Request resolved: https://github.com/facebook/react-native/pull/18615
Differential Revision: D14206830
Pulled By: cpojer
fbshipit-source-id: abe35ce1ab253aa1472d2c798543b515218be445
Summary:
Currently, the final field mMainComponentName is used. This field is
initialized in the constructor of ReactActivityDelegate, and the
ReactActivityDelegate itself is initialized in the constructor of
ReactActivity. This means that the only way you can pass a main
component name to ReactActivityDelegate, is when your ReactActivity
subclass is constructed. At this point in the lifecycle of an
activity, the getIntent() value that the activity was initialized by
returns null, making it impossible to set the mainComponentName
dynamically based on data passed to the activity via an intent.
The mMainComponentName final field is also only used in onCreate of
the delegate, so it's not actually needed by the ReactActivityDelegate
at construction time. So the above limitation is not fundamental, it's
just a side effect of the API design.
By allowing subclasses of ReactActivityDelegate to implement a
getMainComponentName method, the subclass then has full control of how
to initialize the value. So an implementation of getMainComponentName
could be:
public String getMainComponentName() {
return getIntent().getStringExtra("reactMainComponentName");
}
This commit doesn't remove anything and only adds a new method, so it
should be fully backwards compatible.
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/19814
Differential Revision: D14206644
Pulled By: cpojer
fbshipit-source-id: 8532560f944362fe0cce263a7f9a503df8ae539f
Summary:
1. add role description for heading
2. add talkback navigation support for link and header
Fixes#22440
Pull Request resolved: https://github.com/facebook/react-native/pull/22447
Differential Revision: D14205822
Pulled By: cpojer
fbshipit-source-id: 86bfc3bfc851f3544b1962012abaf8d1a357a9d2
Summary: This diff changes the onMeasure method of the RootView to optimize the amount of times we call updateRootLayoutSpecs in Fabric
Reviewed By: shergin
Differential Revision: D14198155
fbshipit-source-id: ff2deee04540899c25d4e38b0bd93333f74c6ace
Summary: This diff adds a new metric in Fabric to measure time it takes to Fabric finish transaction in CPP
Reviewed By: shergin
Differential Revision: D14198153
fbshipit-source-id: 987d1db1ae669906192060cc9b9e077901da6787
Summary:
Add nullable annotations to BaseViewManager and ViewManager methods. This will improve Kotlin developer experience and help Android Studio to offer better autocomplete.
[Android] [Changed] - add nullable annotations to BaseViewManager and ViewManager methods. Might break ViewManagers in Kotlin.
Pull Request resolved: https://github.com/facebook/react-native/pull/23610
Differential Revision: D14198630
Pulled By: mdvacca
fbshipit-source-id: c596c88254e1d02f0af233a466f685200fac8917
Summary:
This commit fixes a bug introduced in a previous attempt (https://github.com/facebook/react-native/pull/23580) to address an issue where okhttp appended `charset=utf-8` to the Content-Type header when otherwise not specified.
In that commit, I converted all characters to UTF-8, however it should instead use an existing encoding when possible.
Related issues:
https://github.com/facebook/react-native/issues/8237#issuecomment-466304854
[Android][fixed] - Respect existing character set when specified in fetch() POST request
Pull Request resolved: https://github.com/facebook/react-native/pull/23603
Differential Revision: D14191750
Pulled By: hramos
fbshipit-source-id: 11c1bfd98ccd33cd8e54ea426285b7d2ce9c2d7c
Summary: "Critical" or "Fast" JNI methods are enticing by their name, but carry dangers that are not trivially visible.
Reviewed By: davidaurelio
Differential Revision: D14184560
fbshipit-source-id: 89ec70f53bb2cb89ff568d8b1fe222ede86c9824
Summary: This diff makes updateRootLayoutSpecs to run synchronously on any thread instead of schedulling this to run in the JS thread
Reviewed By: shergin
Differential Revision: D14142306
fbshipit-source-id: 746f9c51f13e6d987fd9bca35a7c502cc8622f7b
Summary:
@public
If `jni_YGNodeFree` is called while GC is running, the weak reference table lock is held by the GC, leading to deadlock.
Here, we revert the method to being a regular native method, solving that problem.
Reviewed By: SidharthGuglani
Differential Revision: D14184220
fbshipit-source-id: 2882fa10586617cea2df99550a7dd8885376d11e
Moti Zilberman
wojteg1337
James Ide
Emily Janzer
Luna Wei
David Vacca
Valentin Shergin
Kudo Chien
Maciej Srokowski
David Aurelio
Joshua Gross
Ramanpreet Nara
Alan Kenyon
Dulmandakh
Piotr Trocki
Marc Mulcahy
Eileen Zhang
Marc Horowitz
Tim Wang
Michał Pierzchała
Emiel Mols
Guilherme Iscaro
Janic Duplessis
Kevin Gozali
Build Service
Thorben Primke
Christoph Nakazawa
Pavel Rotek
Will Holen
Estevão Lucas
Sam Mathias Weggersen
Rick Ratmansky
Taylor123
Alston Lin
Mike Diarmid
Vojtech Novak
Sebastian McKenzie
Пётр Потапов
Spencer Ahrens
landon
YuTeh Shen
Pieter De Baets
John Shelley
Aditya Sharat
Nurzhan Bakibayev
Sunny Luo
Adam Comella
Héctor Ramos
Gábor Siffel
Sidharth Guglani
Ram N
Ioannis Kokkinidis
Alexander Vasyuk
Kyle Pinkham
Mikael Sand
Dhaval Kapil
Yuan Du
Sergei Dryganets
Ryan Elliott
Max Komarychev
Yedidya Feldblum
Peter Argany
Peter van der Zee
Eric Schlanger
Andrew Schenk
Sébastiaan Versteeg
Vishwesh Jainkuniya
yukai1
August Lilleaas
Wei Yang
Nate Hunzaker
Chris Sarbora
