Summary:
Could not repro myself, but logview shows steady low number of crashes coming from this mid. Current fix returns early if the layout is not defined, relying on the following layout passes to position view correctly.
Changelog: [Android][Fixed] Exit early from layout in textview if text layout is null
Reviewed By: JoshuaGross
Differential Revision: D29636040
fbshipit-source-id: 876ce80222cbc5ff09450224f6808f9f6433c62a
Summary:
Issue https://github.com/facebook/react-native/issues/30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list.
## Changelog
[Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list
Pull Request resolved: https://github.com/facebook/react-native/pull/31630
Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list.
Reviewed By: kacieb
Differential Revision: D29599351
Pulled By: blavalla
fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
Summary:
Douring our routine crash report check we are occasionally seeing reports of exceptions like this in the wild from our crash stack:
```
java.lang.NullPointerException: bio == null
at com.android.org.conscrypt.NativeCrypto.SSL_pending_written_bytes_in_BIO(NativeCrypto.java)
at com.android.org.conscrypt.NativeSsl$BioWrapper.getPendingWrittenBytes(NativeSsl.java:660)
at com.android.org.conscrypt.ConscryptEngine.pendingOutboundEncryptedBytes(ConscryptEngine.java:566)
at com.android.org.conscrypt.ConscryptEngineSocket.drainOutgoingQueue(ConscryptEngineSocket.java:584)
at com.android.org.conscrypt.ConscryptEngineSocket.close(ConscryptEngineSocket.java:480)
at okhttp3.internal.Util.closeQuietly(Util.kt:501)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFile:245)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFile:106)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFile:74)
at okhttp3.internal.connection.RealCall.initExchange$okhttp(ExchangeFile:255)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ExchangeFile:32)
...
```
This appears to only be happening on devices running Android 10 and 11. This happens because there is concurrency issue in Conscrypt where two threads race to close an SSLEngine-based SSLSocket and access to the underlying BIO is unsynchronized.
**The OkHttp team already released a fix for this issue on version 4.9.1** this PR aims to update our OkHttp package to version 4.9.1.
Related discussion:
[https://issuetracker.google.com/issues/177450597](https://issuetracker.google.com/issues/177450597)
[https://publicobject.com/2021/01/30/bio-null/](https://publicobject.com/2021/01/30/bio-null/)
cc dulmandakh fkgozali
## Changelog
[Android] [Changed] - Bumping OkHttp from 4.9.0 to 4.9.1.
Pull Request resolved: https://github.com/facebook/react-native/pull/31822
Test Plan: Manual & Automated from CI
Reviewed By: fkgozali
Differential Revision: D29590198
Pulled By: ShikaSD
fbshipit-source-id: 4228bfd3472114253e13acb436dc1dd9287a148d
Summary:
At risk of hiding errors, given the low volume, I think it's safe to cause this to crash in debug and continue gracefully in release-mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29618047
fbshipit-source-id: 19b19d8f6e27703227de4947ed01f7f2177f463b
Summary:
This diff fixes a NullPointerException that is caused when the method ReactInstanceManager.getViewManagerNames is called at the same time ReactInstanceManager is being destroyed.
Following the stacktrace I noticed that this crash can only happen when RN was destroyed by another thread while this method was being executed
This diff fixes the NullPointerException, but it doesn't fix the root cause race condition that cuases this bug
changelog: [Android][Fixed] Fix NullPointerException caused by race condition in ReactInstanceManager.getViewManagerNames method
Reviewed By: JoshuaGross
Differential Revision: D29616401
fbshipit-source-id: 6ae8ecdd765d2fe3529fef3237f08b182d8ed243
Summary:
It is possible for receiveEvent to be called concurrently with/after destruction of FabricUIManager. Drop events if we are able to detect that case.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29596271
fbshipit-source-id: 1fa50d9c3cff0bf578316d905966e1bdfffe94d1
Summary:
As a followup to T91209139, ship "state update scroll race" in code. This also ships it for HorizontalScrollView since it's been validated for vertical scroll views.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29595601
fbshipit-source-id: 64b6a23e2dab2c13123e132d9d899fb769d03172
Summary:
I suspect that T94864568 is caused by TouchEvents being dispatched after they've been recycled. This needs further analysis, but to stop the bleeding, we can drop events at the point they'd be dispatched before the crash, and log a soft error.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594749
fbshipit-source-id: f50df8df2125b83126616ceaf4e529127d154c7c
Summary:
It is unlikely but possible that the crash T94864568 is caused by a TouchEvent being initialized with a null MotionEvent. Regardless, we should guard against this case.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594750
fbshipit-source-id: 3a409b716a9f1eec8017002ae7e23273677e53ba
Summary:
Upgrade folly for the https://github.com/facebook/folly/pull/1593 fix for NDK 21 failure
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Changed] - Upgrade folly to 2021.06.28.00
Pull Request resolved: https://github.com/facebook/react-native/pull/31802
Test Plan:
`./gradlew :ReactAndroid:installArchives`
`./gradlew packages:rn-tester:android:app:installJscRelease`
`./gradlew packages:rn-tester:android:app:installHermesRelease`
Reviewed By: RSNara
Differential Revision: D29547027
Pulled By: ShikaSD
fbshipit-source-id: a10c7c65f459091bd0e7cca750a9b9e067189b73
Summary:
See comments in ReactClippingProhibitedView for details and motivation behind this new feature.
You may have a View class inherit from the ReactClippingProhibitedView interface in order to enable this feature for instances of that View type.
This can be added to Views that should /never/ be clipped from the View hierarchy - namely, TTRC components or other telemetry components that always need to be rendered in order for some feature to function.
Changelog: [Added] Opt-in mechanism to allow native Android Views to be marked as "not clippable", soft exceptions will be logged if these Views are clipped from the View hierarchy
Reviewed By: sshic
Differential Revision: D29472439
fbshipit-source-id: b3be53df836b452aed5dc40514ff585ce0ad812b
Summary:
@public
When PlatformColor is used with backgroundColor, this line would throw, as the object type is not convertible to int.
Changelog:
[Android][Fixed] - Fix Crash in ViewProps.isLayoutOnly
Reviewed By: JoshuaGross
Differential Revision: D29430151
fbshipit-source-id: a1fe801925430dad3a17871bdebb79d942775280
Summary:
Immediately destroy EventEmitterWrapper on update instead of waiting for Java GC. This can resolve JSI::~Pointer deallocation crashes by clearing out EventEmitter and therefore EventTarget sooner, before RN teardown.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29415386
fbshipit-source-id: 05517bfd9e2cc2bd1b8c58d4f84c84f6f547268a
Summary:
This prevents us from leaking things via this static field.
Changelog: [Android][Changed] Native ScrollView listeners list maintains weak references to listeners to avoid memory leaks
Reviewed By: JoshuaGross
Differential Revision: D29317937
fbshipit-source-id: 4daeb8b5533cccaebcb03acf3d595dfa58de7883
Summary:
Changelog: [internal]
Reland of D29131766 (https://github.com/facebook/react-native/commit/18165367b0347fc46cd52a6ac00afcf62d05cb30) which had to reverted because it caused binary size regression in instagram.
Size check for `automation_instagram_stablesize_release` and `automation_igtv_release`
{F626711916}
Reviewed By: JoshuaGross
Differential Revision: D29263302
fbshipit-source-id: cc8f5609ebaed9ddf666f7c57cdbf3dbf77a8f78
Summary:
Because of T92179998, T93607943, and T93394807, we are still seeking resolution to tricky crashes wrt the use of EventEmitters.
I believe the recent spike is because of two recent changes: we pass in EventEmitters earlier, during PreAllocation; and we clean them up earlier, during stopSurface, to avoid jsi::~Pointer crashes.
Additionally, the gating previously added around the PreAllocation path was incorrect and led to more nullptrs being passed around as EventEmitters.
To mitigate these issues:
1) I am adding/fixing gating to preallocation and early cleanup paths
2) I am making EventEmitterWrapper more resilient by ensuring EventEmitter is non-null before invoking it.
3) I am making sure that in more cases, we pass a non-null EventEmitter pointer to Java.
4) I am backing out the synchronization in EventEmitterWrapper (java side) as that did not resolve the issue and is a pessimisation
There are older, unchanged paths that could still be passing in nullptr as the EventEmitter (Update and Create). As those have not changed recently, I'm not going to fix those cases and instead, we can now rely on the caller to ensure that the EventEmitter is non-null before calling.
Changelog: [internal]
Differential Revision: D29252806
fbshipit-source-id: 5c68d95fa2465afe45e0083a0685c8c1abf31619
Summary:
Because of the "disable preallocation of virtual views" experiment, for some reason, some views are being preallocated multiple times instead of not being preallocated at all.
This isn't really a problem for CreateView, and Preallocate is actually more strict here than it needs to be. I'm going to downgrade this to a soft error and will continue to analyze more. This is more of a perf issue than a correctness issue, so this should be fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29206416
fbshipit-source-id: 9490a1a705c2b39def3a3e56086634439543515e
Summary:
Changelog: [internal]
We should be calling invokeUnique if event can be coalesced, not the other way around.
Reviewed By: JoshuaGross
Differential Revision: D29194528
fbshipit-source-id: 36e4ae71254420ef47deea436cad20eec09712fc
Summary:
Changelog: [internal]
Why does the crash happen?
We call method on invalid address. We crash on `std::weak_ptr::lock` because that's the first accessed ivar.
In D29020768 (https://github.com/facebook/react-native/commit/25e8fbe8ffa1c91522e91819a781434093f8b759), eventEmitter may be destroyed before an event is dispatched. Calling destroy on hybrid object destroys only C++ part.
Reviewed By: JoshuaGross
Differential Revision: D29194906
fbshipit-source-id: ae8d9d90aa8d98d69d29884e80d6b930b1e66870
Summary:
Changelog: [internal]
It is recommended to not use `using namespace` in the header file. It changes namespace for anything that imports the header file.
Also keeping imports in header file to minimum is recommended to lower build times.
Reviewed By: JoshuaGross
Differential Revision: D29131371
fbshipit-source-id: ad1868f6200c00023a62a00859d9a05140a12849
Summary:
This PR bumps NDK_VERSION to 21.4.7075529, and patches FileUtil.cpp from folly based on patch from https://github.com/facebook/folly/pull/1593. We can remove the patch once PR lands in Folly and bump Folly version in RN.
FYI, NDK 20 is deprecated and 21 is LTS release.
## Changelog
[Android] [Changed] - Bump NDK to 21.4.7075529
Pull Request resolved: https://github.com/facebook/react-native/pull/31731
Reviewed By: mdvacca
Differential Revision: D29166690
Pulled By: ShikaSD
fbshipit-source-id: 0792691404f718aaf5af1369f66f0cba046b4e20
Summary:
Rationale:
- This makes the element inspector button consistent with the Fast Refresh, Perf Monitor and other buttons in the DevMenu
- This makes the button more informative
Changelog: [Android][Changed] Rename the "Toggle Inspector" DevMenu item to "Hide/Show Element Inspector"
Reviewed By: JoshuaGross
Differential Revision: D29146871
fbshipit-source-id: 8e8c19217ea2ff2f1d176521aa22200058e7e643
Summary:
Changelog: [internal]
RuntimeScheduler needs to be created and registered in the runtime before any JS is allowed to run. This diff moves the registration right after the runtime is initialised.
This diff removes funnelling of Fabric events through RuntimeScheduler. This will be added in subsequent diff to keep the complexity low.
Reviewed By: JoshuaGross
Differential Revision: D29131766
fbshipit-source-id: cbc650f6fbce95e4b9c2c9695e8e0aba5beac635
Summary:
Changelog: [internal]
Remove `RuntimeScheduler` from `SchedulerToolbox` and all of its uses.
`RuntimeScheduler` needs to be allocated before `Scheduler` and therefore its presence in the toolbox is redundant.
Reviewed By: JoshuaGross
Differential Revision: D29134769
fbshipit-source-id: fa00c5dcc4b565d6941e6d742c6aefade37b31c4
Summary:
Before the DevMenu would just open up as a DialogBox. After this change, the DialogBox will have a title. This should help distinguish between the Bridgeless DevMenu and the Bridge DevMenu.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29071185
fbshipit-source-id: 72533f10b73b36cd890fe152c6de901c867159f2
Summary:
With bridgeless mode enabled, there can be two instances of DevSupportManager. Previously, both of them wrote to the same files on disk. After this change, each instance will write the bundle to different files on disk.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29068794
fbshipit-source-id: 67270be17d084cc89ab618ea54f729f9b595b5f7
Summary:
Google Chrome debugging is only supported by the bridge. So, it makes sense to move it to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29031514
fbshipit-source-id: 4d6b6bb3bc298be5fe4d9f96c0d019676fe256db
Summary:
This diff prevents a NullPointerException caused by a race condition in the tear down of React Native.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29135942
fbshipit-source-id: 76d5a1f16c2ca63a146b56c761f5f9595dcfe2a5
Summary:
The mount items executed before the view attach can fail with the RetryableMountingLayerException, which we should either retry or skip the item. This change updates logic for such items to catch these exceptions.
Instead of passing `MountingManager` to execute the items, this change now passes a reference to the `MountItemDispatcher` (abstracted through interface to resolve cycle between the manager and dispatcher). The dispatcher executes the queue directly and schedules retry together with the next batch.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29068063
fbshipit-source-id: 04030b21db188d5617c3448322d25ba77d5fbb9f
Summary:
This feature is still causing some number of crashes, though prod impact is not yet determined. For safety I'm adding a feature flag so we can disable this if necessary.
Changelog: [internal]
Reviewed By: kacieb
Differential Revision: D29117957
fbshipit-source-id: 3b19bac9dd00735f51f5c9cba606378b2a62975e
Summary:
This PR bumps Fresco to 2.5.0, which is first version on MavenCentral since jCenter announcement.
## Changelog
[Android] [Changed] - Bump Fresco to 2.5.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31699
Test Plan: CI is green
Reviewed By: TheSavior
Differential Revision: D29031847
Pulled By: passy
fbshipit-source-id: 486ffbf5461d07d736c0ebe17c0c7726937db344
Summary:
## Rationale
The public methods of PackagerCommandListener should not be a part of the public API of DevSupportManagerBase. It's cleaner to just create a new PackagerCommandListener object inline, when we need it. This way, there're are less methods to think about when reasoning about the public API of DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006835
fbshipit-source-id: 0eea86c22e7d676c94d29b240a1f39955d8216ab
Summary:
## Rationale
This reduces the surface area of DevSupportManager's public API.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006836
fbshipit-source-id: 579364f6c556b8588f3b6bac79df3deb244a92e5
Summary:
## Rationale
This DevSupportManagerBase constructor isn't used anywhere, aside from VeniceDevSupportManager. Even in VeniceDevSupportManager, we should use the more specific constructor, because it informs readers of the class what specifically is being nullified in the base class. So, this diff gets rid of the smaller arity constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004542
fbshipit-source-id: 74e20db93cf1871a364bf228dc089cd7d124297f
Summary:
## Rationale
DevSupportManagerBase.handleReloadJS() implements reloads for the bridge. Therefore, it's best to move this method to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004541
fbshipit-source-id: f77244e9c44cd442e7e0ab2845f78d699b143e66
Summary:
## Rationale
Throughout DevSupportManagerBase, we show/hide the DevLoadingView and simultaneously write to the `mDevLoadingViewVisible` boolean. This diff pulls all those boolean writes into methods, so that subclasses of DevSupportManagerBase can show/hide the DevLoadingView without accessing the boolean directly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004062
fbshipit-source-id: d54d79701e31f9ac8d1d1d44019199718fe1c8c0
Summary:
## Rationale
DevSupportManagerBase.loadSplitBundleFromServer() uses the bridge. So, it's best to move it to DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004064
fbshipit-source-id: 9acfb769d57a44ee4871e1997ff0950c3d66b757
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
In T92179998, there is a crash when an EventEmitterWrapper is deallocated after the JS VM is torn down, and the EventEmitterWrapper tries to free its JSI::Pointer reference (double-free).
To make sure this happens less/not at all, free EventEmitterWrappers on ViewState when a view is deleted, instead of waiting for all of RN to be torn down.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29020768
fbshipit-source-id: 9d72a23bc9966992ef56c1e3ee523405d4333194
Summary:
Fixes https://github.com/facebook/react-native/issues/30502.
This PR fixes a crash caused by a `NullPointerException` when updating the `snapToOffsets` property.
I noticed this crash on production, you'll find the stack trace below.
Cause: `snapToOffsets` is annotated `Nullable` but there are no nullability check before calling `snapToOffsets.size()`.
## Changelog
[Android] [Fixed] - Fixed a crash when updating `snapToOffsets` to a null value
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/31681
Test Plan:
Passing `snapToOffsets={undefined}` to a `FlatList` used to crash on Android. Not anymore.
## Stacktrace
```
com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'snapToOffsets' of a view managed by: RCTScrollView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:102)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:87)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'int com.facebook.react.bridge.ReadableArray.size()' on a null object reference
at com.facebook.react.views.scroll.ReactScrollViewManager.setSnapToOffsets(ReactScrollViewManager.java:107)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:87)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
```
Reviewed By: ShikaSD
Differential Revision: D28965864
Pulled By: JoshuaGross
fbshipit-source-id: f08f1df371c1892935e1290806cc67d34394203b
Andrei Shikov
Anas Khurshid
Agastya Darma
Joshua Gross
David Vacca
Kudo Chien
Pieter De Baets
David Alves
Samuel Susla
Luna Wei
Dulmandakh
Ramanpreet Nara
Maxime Bertheau
