Crashes with the error: java.lang.NullPointerException: Attempt to read from field 'int android.view.View.mViewFlags' on a null object reference in method 'void android.view.ViewGroup.dispatchGetDisplayList()'

[rpyoyo]

Description

I customized a Modal component using the Animated.View component with entering and exiting props. When the Modal closes and navigates to another screen, the app crashes with the error: java.lang.NullPointerException: Attempt to read from field 'int android.view.View.mViewFlags' on a null object reference in method 'void android.view.ViewGroup.dispatchGetDisplayList()'.
I tried removing the exiting prop, and the crash didn't happen.
Not all devices crash—most crashes are related to Oppo/Realme, etc.

Steps to reproduce

1. create a project with expo (npx create-expo-app@latest)
2. reset project (npm run reset-project)
3. install dependency (npx expo install ahooks react-native-get-random-values uuid react-native-keyboard-controller react-native-paper)
4. prebuild (expo prebuild)
5. add two screen (index and test)
6. add Modal component
7. add a button to open a drawer on index screen
8. navigate to test screen on Modal callback "onConfirm"
9. build a release app and install to a device (oppo or realme)
10. open the app in default index screen, click the button to open the drawer and then click the action
11. the screen change to test screen and then the app crash

Snack or a link to a repository

https://github.com/rpyoyo/crash-reproduction-react-native-reanimated.git

Reanimated version

4.1.3

Worklets version

0.6.1

React Native version

0.81.4

Platforms

Android

JavaScript runtime

Hermes

Workflow

Expo Dev Client

Architecture

New Architecture (Fabric renderer)

Build type

Release app & production bundle

Device

Real device

Host machine

Windows

Device model

Realme GT Neo (RMX3350) Android 13

Acknowledgements

Yes

[rpyoyo]

By the way, the same code works fine with expo@53 and react-native-reanimated@3.17.4. I just upgraded the Expo version to 54, and the related react-native-reanimated was forced to upgrade to 4.1.3.

[patrycjakalinska]

hi @rpyoyo, thanks for opening the issue! Could you add reproduction code? Unfortunately we can't do much without it, thanks

[rpyoyo]

hi @rpyoyo, thanks for opening the issue! Could you add reproduction code? Unfortunately we can't do much without it, thanks

I just created a minimal reproduction repo.

With the app built by this repo, I found that on a Realme GT Neo (RMX3350) device running Android 11, it works normally, but crashes on another Realme GT Neo (RMX3350) device running Android 13.

Here is a video record test on OPPO Reno6 5G running Android 13.

20251020-175107.mp4

[arasrezaei]

I have exactly same problem, problem occurs in production build (dev is fine, but not always)

[michael-pingo-ai]

Same issue — it’s critical and affects all our users on Chinese devices (OPPO, Huawei, etc.). It occurs when performing an exit animation during navigation using @react-navigation/native-stack. I’ve detailed my findings here as well: GSTJ/react-native-magic-modal#155. I think this is a react-native-reanimated issue as when I make the exit animations duration of 1 millisecond, it doesn't happen as often.

[Jeius]

Same issue. I am using a Realme Device (Realme 14 5g). For me, it occurs when navigating away from the screen that has a reanimated component with exiting and layout animation. Specifically, it crashes when navigating away from the screen while it is still animating (exiting/layout animations).

package.json:

"expo": "~54.0.13",
"react-native-reanimated": "~4.1.2",
"react-native-worklets": "^0.5.1",
"react-native-gesture-handler": "~2.28.0",

[tomekzaw]

I was able to reproduce the crash using provided repro https://github.com/rpyoyo/crash-reproduction-react-native-reanimated on a Realme GT2 with the following stacktrace:

FATAL EXCEPTION: main
Process: com.rpyoyo.test, PID: 20027
java.lang.NullPointerException: Attempt to read from field 'int android.view.View.mViewFlags' on a null object reference in method 'void android.view.ViewGroup.dispatchGetDisplayList()'
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4561)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4589)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4562)
	at android.view.View.updateDisplayListIfDirty(View.java:22213)
	at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:682)
	at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:688)
	at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:790)
	at android.view.ViewRootImpl.draw(ViewRootImpl.java:4842)
	at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:4537)
	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3723)
	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2442)
	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9375)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1388)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1396)
	at android.view.Choreographer.doCallbacks(Choreographer.java:1033)
	at android.view.ChoreographerExtImpl.checkScrollOptSceneEnable(ChoreographerExtImpl.java:408)
	at android.view.Choreographer.doFrame(Choreographer.java:900)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1371)
	at android.os.Handler.handleCallback(Handler.java:942)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:240)
	at android.os.Looper.loop(Looper.java:351)
	at android.app.ActivityThread.main(ActivityThread.java:8355)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:584)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1013)

[hannojg]

I am working on this in parallel as this is impacting a client of ours.

Sharing my findings & understanding:

• The problem only happens when using react-native-screens / native-stack

• The issue is that the view hierarchy is modified while we are drawing (which we always have to avoid on android)

• RNS dispatches progress updates here: https://github.com/software-mansion/react-native-screens/blob/1443bd9e95618839b3b9687f81a4833598b35372/android/src/main/java/com/swmansion/rnscreens/stack/anim/ScreensAnimation.kt#L16

• This will be intercepted by REAs NodeManager, which will call performOperations:
  

  react-native-reanimated/packages/react-native-reanimated/android/src/main/java/com/swmansion/reanimated/NodesManager.java

  Lines 190 to 192 in 3380da1

  	if (UiThreadUtil.isOnUiThread()) {
  	handleEvent(event);
  	performOperations();

• performOperations will sync execute a render transaction here (which was introduced here):
  

  react-native-reanimated/packages/react-native-reanimated/Common/cpp/reanimated/NativeModules/ReanimatedModuleProxy.cpp

  Lines 654 to 663 in 3380da1

  	void ReanimatedModuleProxy::performOperations() {
  	ReanimatedSystraceSection s("ReanimatedModuleProxy::performOperations");
  	auto flushRequestsCopy = std::move(layoutAnimationFlushRequests_);
  	for (const auto surfaceId : flushRequestsCopy) {
  	uiManager_->getShadowTreeRegistry().visit(
  	surfaceId, [](const ShadowTree &shadowTree) {
  	shadowTree.notifyDelegatesOfUpdates();
  	});
  	}

• This will eventually cause to change the layout / view hierarchy while we are drawing, which causes the crash

• (I think in this case it even might even starts to sync execute the commit that react was scheduling async as we are using notifyDelegatesOfUpdates, which is just using the ShadowTree's latest mountingCoordinator)

Things that work around the issue:

• Reverting [Fabric LA] Add progress batching #7798 fixes the crash from the reproduction provided
• Commenting out the progress updates here fixes the issue: https://github.com/software-mansion/react-native-screens/blob/1443bd9e95618839b3b9687f81a4833598b35372/android/src/main/java/com/swmansion/rnscreens/stack/anim/ScreensAnimation.kt#L16

Now, the thing is, I am seeing this crash on REA 3.17.1 as well, so i don't think its necessarily this specific change that causes the issue.
The problem here is much rather that we dispatch the event in RNS onAnimationEnd, which gets triggered as part of the drawing cycle.
Reanimated at this point could have work to process, or not, which would also explain why i can't reproduce the crash reliably in our client's app.

To fix this I think we could:

a) make sure RNS doesn't dispatch the event directly on animation draw but use like post to put in the queue
b) make sure we don't perform a mount sync when we are drawing at the moment
c) something else i haven't thought of yet

Stack of RNS causing dispatching of event during draw:

btw, i really think we should land the change that we only sync process events in REA if there is a registered handler for it, also for performance reasons