react-native-screens: Android crashes nondeterministically when restoring from background

As a workaround for this issue I suggest adding the following code to the main activity class (the one that extends ReactFragmentActivity:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(null);
}

I was having this issue with RN 0.60.5 and react-native-screens 1.0.0-alpha22. Easily reproducible when developer option Don't keep activities is on.

Fixed the issue as @kmagiera suggested, by applying the following diff:

diff --git a/android/app/src/main/java/com/dcnetapp/MainActivity.java b/android/app/src/main/java/com/dcnetapp/MainActivity.java
index 5604708..043ae89 100644
--- a/android/app/src/main/java/com/dcnetapp/MainActivity.java
+++ b/android/app/src/main/java/com/dcnetapp/MainActivity.java
@@ -4,6 +4,7 @@ import com.facebook.react.ReactActivity;
 import com.facebook.react.ReactActivityDelegate;
 import com.facebook.react.ReactRootView;
 import com.swmansion.gesturehandler.react.RNGestureHandlerEnabledRootView;
+import android.os.Bundle;
 
 public class MainActivity extends ReactActivity {
     /**
@@ -24,4 +25,9 @@ public class MainActivity extends ReactActivity {
             }
         };
     }
+
+    @Override
+    protected void onCreate(Bundle savedInstanceState) {
+        super.onCreate(null);
+    }
 }

The fix should be OK for now, but apparently it’s not a good long term solution. Is there any more proper way to solve for this?

@WoLewicki Has there been a fix or support added for restoring screen fragments? What are the repro steps? I’m on react-native 0.63.3 and react-native-screens 3.4.0, and we are starting to see this crash in our app in production. We haven’t added the first recommended fix of passing null into onCreate since we want to preserve state if the app is relaunched from the background - but I also haven’t been able to repro this locally. Any help here would be appreciated to better understand what’s going on and what’s the current state of things.

Question: Instead of forcibly passing null to the constructor, what is the downside of selectively removing the fragment info from savedInstanceState ?

Not really sure about the correct keys to use (for portability) though. I found those android:support:fragments and android:fragments when logging the bundle content.

    protected void onCreate(Bundle savedInstanceState) {
		if (savedInstanceState != null) {
			savedInstanceState.remove("android:support:fragments");
			savedInstanceState.remove("android:fragments");
		}
               super.onCreate(savedInstanceState);
    }

This does not result in a crash with both Keep Activities on or off.

same issue on react-natvie-screens 2.15.1 everything works correctly but on 3.7.0 - app started to crash

Why is this not mentioned in the readme?

@kmagiera here you say https://github.com/software-mansion/react-native-screens/issues/17#issuecomment-424704067 to change the way we call super.onCreate. I can confirm that calling onCreate with null fixes the problem. I see that the example app also calls onCreate with null. So is this the fix for that?

If we switch super.onCreate(null) to super.onCreate(savedInstanceState); and then put the app in background and go to the android settings -> display -> font size -> change the font size and navigate to back to the app -> you will be able to reproduce the issue.

Note: App needs to be build in release mode for it to crash.

+1

The workaround doesn’t solve it for me - anyone found something else which could cause this?

We should perhaps make it a default behavior for the main activity class in RN core as restoring instance state won’t work in RN this way anyways

😱

as comment suggested pass null to onCreate, however, on foldable phone the whole application will restart whenever we split into multi-window. Any other ways could prevent such issue? Thanks.

I think the consensus was that it is an intractable design problem because the javascript view state is not well known on Activity restore when there’s a configuration change or similar, so there is nothing better / more correct to do other than assume things might be out of sync and rebuild your view from the application state you have? Thus the otherwise distasteful solution of killing the passed in state (by refusing to pass the Bundle given, and instead sending super null) is the only consistently correct thing to do

A good question @DomiR 😅 if there’s some place you just discovered it should go, I/we here may all be missing perspective at this point and so not have thought of it, but github can walk you through a super-quick PR if you hit the edit button at the top of whatever doc page it is

I think this issue can be closed since https://github.com/software-mansion/react-native-screens/issues/17#issuecomment-424704067 is obligatory for the library to work correctly. Comment here if you have any question regarding it.

Just received this crash report

Fatal Exception: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.[APPNAME]/com.[APPNAME].MainActivity}: b.h.a.d$e: Unable to instantiate fragment com.swmansion.rnscreens.b$a: could not find Fragment constructor
       at android.app.ActivityThread.performLaunchActivity + 3114(ActivityThread.java:3114)
       at android.app.ActivityThread.handleLaunchActivity + 3257(ActivityThread.java:3257)
       at android.app.servertransaction.LaunchActivityItem.execute + 78(LaunchActivityItem.java:78)
       at android.app.servertransaction.TransactionExecutor.executeCallbacks + 108(TransactionExecutor.java:108)
       at android.app.servertransaction.TransactionExecutor.execute + 68(TransactionExecutor.java:68)
       at android.app.ActivityThread$H.handleMessage + 1948(ActivityThread.java:1948)
       at android.os.Handler.dispatchMessage + 106(Handler.java:106)
       at android.os.Looper.loop + 214(Looper.java:214)
       at android.app.ActivityThread.main + 7050(ActivityThread.java:7050)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 493(RuntimeInit.java:493)
       at com.android.internal.os.ZygoteInit.main + 965(ZygoteInit.java:965)

Caused by b.h.a.d$e: Unable to instantiate fragment com.swmansion.rnscreens.b$a: could not find Fragment constructor
       at androidx.fragment.app.Fragment.a + 111(Fragment.java:111)
       at androidx.fragment.app.FragmentContainer.instantiate(FragmentContainer.java)
       at androidx.fragment.app.FragmentState.a + 25(FragmentState.java:25)
       at androidx.fragment.app.FragmentManagerImpl.a + 230(FragmentManagerImpl.java:230)
       at androidx.fragment.app.FragmentController.a + 4(FragmentController.java:4)
       at androidx.fragment.app.FragmentActivity.onCreate + 42(FragmentActivity.java:42)
       at androidx.appcompat.app.AppCompatActivity.onCreate + 40(AppCompatActivity.java:40)
       at com.facebook.react.ReactActivity.onCreate(ReactActivity.java)
       at com.[APPNAME].MainActivity.onCreate(MainActivity.java)
       at android.app.Activity.performCreate + 7327(Activity.java:7327)
       at android.app.Activity.performCreate + 7318(Activity.java:7318)
       at android.app.Instrumentation.callActivityOnCreate + 1271(Instrumentation.java:1271)
       at android.app.ActivityThread.performLaunchActivity + 3094(ActivityThread.java:3094)
       at android.app.ActivityThread.handleLaunchActivity + 3257(ActivityThread.java:3257)
       at android.app.servertransaction.LaunchActivityItem.execute + 78(LaunchActivityItem.java:78)
       at android.app.servertransaction.TransactionExecutor.executeCallbacks + 108(TransactionExecutor.java:108)
       at android.app.servertransaction.TransactionExecutor.execute + 68(TransactionExecutor.java:68)
       at android.app.ActivityThread$H.handleMessage + 1948(ActivityThread.java:1948)
       at android.os.Handler.dispatchMessage + 106(Handler.java:106)
       at android.os.Looper.loop + 214(Looper.java:214)
       at android.app.ActivityThread.main + 7050(ActivityThread.java:7050)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 493(RuntimeInit.java:493)
       at com.android.internal.os.ZygoteInit.main + 965(ZygoteInit.java:965)

Caused by java.lang.NoSuchMethodException: com.swmansion.rnscreens.b$a.<init> []
       at java.lang.Class.getConstructor0 + 2328(Class.java:2328)
       at java.lang.Class.getConstructor + 1725(Class.java:1725)
       at androidx.fragment.app.Fragment.a + 32(Fragment.java:32)
       at androidx.fragment.app.FragmentContainer.instantiate(FragmentContainer.java)
       at androidx.fragment.app.FragmentState.a + 25(FragmentState.java:25)
       at androidx.fragment.app.FragmentManagerImpl.a + 230(FragmentManagerImpl.java:230)
       at androidx.fragment.app.FragmentController.a + 4(FragmentController.java:4)
       at androidx.fragment.app.FragmentActivity.onCreate + 42(FragmentActivity.java:42)
       at androidx.appcompat.app.AppCompatActivity.onCreate + 40(AppCompatActivity.java:40)
       at com.facebook.react.ReactActivity.onCreate(ReactActivity.java)
       at com.[APPNAME].MainActivity.onCreate(MainActivity.java)
       at android.app.Activity.performCreate + 7327(Activity.java:7327)
       at android.app.Activity.performCreate + 7318(Activity.java:7318)
       at android.app.Instrumentation.callActivityOnCreate + 1271(Instrumentation.java:1271)
       at android.app.ActivityThread.performLaunchActivity + 3094(ActivityThread.java:3094)
       at android.app.ActivityThread.handleLaunchActivity + 3257(ActivityThread.java:3257)
       at android.app.servertransaction.LaunchActivityItem.execute + 78(LaunchActivityItem.java:78)
       at android.app.servertransaction.TransactionExecutor.executeCallbacks + 108(TransactionExecutor.java:108)
       at android.app.servertransaction.TransactionExecutor.execute + 68(TransactionExecutor.java:68)
       at android.app.ActivityThread$H.handleMessage + 1948(ActivityThread.java:1948)
       at android.os.Handler.dispatchMessage + 106(Handler.java:106)
       at android.os.Looper.loop + 214(Looper.java:214)
       at android.app.ActivityThread.main + 7050(ActivityThread.java:7050)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 493(RuntimeInit.java:493)
       at com.android.internal.os.ZygoteInit.main + 965(ZygoteInit.java:965)

"react-native": "0.60.5",
"react-native-screens": "1.0.0-alpha.23"

Galaxy S8+
Android 9

facing same crash here

So hit that edit button and make a PR 😃

@hannigand I think you may have found the one scenario where I still see this problem! Thanks for the location scenario as I do that and I still see crashes sometimes. It seems like we need to abort the entire process of handling the save instance state Bundle. There are few options:

https://stackoverflow.com/questions/6198319/android-how-to-ignore-or-disable-savedinstancestate

It seems like any of these would work:

• android:saveState=false for the Activity in AndroidManifest.xml
• override onSaveInstanceState to call Bundle::clear() in MainActivity
• override onRestoreInstanceState in the Activity and don’t call super.onRestoreInstanceState

@hannigand you seem like you’re set up for testing right at this moment, I think we already have a code change as a workaround in MainActivity so focusing on those kind of solutions seems best, want to try either of the two Java changes to see if they work?

Thanks @K-Leon @jgcmarins @joaodematejr for leaving your notes. I’d appreciate it very much if you could find a minute to include a stacktrace from the crash you are experiencing and also version of the library + RN version your app uses.

Agreed. Generally speaking if you cannot save your JS memory (Redux stores, in-component state etc.), then saving only your view state could likely cause inconsistencies.

But then again in a single-activity-app, not saving the activity state means that your app is essentially restarting whenever OS kills your activity for any reason.

Does react-native-navigation attempt to deal with process death challenge, I don’t know. Maybe it’d be better to let to the hosting navigation libraries deal with this. In practice they could keep saving each new screen props on into a bundle in the main activity, put this bundle into the one given in onSaveInstanceState and send the data back to as props on activity recreation through ReactRootView.startReactApplication(reactInstanceManager, moduleName, initialProps) method.

Btw my app doesn’t have this problem as we have an architecture (not using this library, but I’d like to in the future) where each screen is an instance of an activity, and the props are sent through converting a ReadableMap into a Bundle and storing the Intent extras. This way we never lose the props at process death, and the props are usually sufficient to recreate the flow the user had left the app in. Not necessarily advocating for multiple activities but just explaining how we solved it.

@lkw1830 you can fix that issue by setting up screenLayout & smallestScreenSize flags in android:configChanges option in your AndroidManifest.xml file.

So eg. here in our example app https://github.com/software-mansion/react-native-screens/blob/master/Example/android/app/src/main/AndroidManifest.xml#L19

set it as

android:configChanges="keyboard|keyboardHidden|orientation|screenSize|uiMode|screenLayout|smallestScreenSize"

When I was testing this setting up screenLayout flag was sufficient but documentation recommends both of these flags.

Source: https://developer.android.com/guide/topics/manifest/activity-element#config

if (outState != null) { outState.clear(); } - bundle is null onCreate but onResume of activity it has values and that’s your crash

@marqroldan I believe it is this one: https://github.com/software-mansion/react-native-screens/issues/463, and there is a solution provided, but it needs to be tested thoroughly: https://github.com/software-mansion/react-native-screens/issues/463#issuecomment-883197624

Question: Instead of forcibly passing null to the constructor, what is the downside of selectively removing the fragment info from savedInstanceState ?

Not really sure about the correct keys to use (for portability) though. I found those android:support:fragments and android:fragments when logging the bundle content.

    protected void onCreate(Bundle savedInstanceState) {
		if (savedInstanceState != null) {
			savedInstanceState.remove("android:support:fragments");
			savedInstanceState.remove("android:fragments");
		}
               super.onCreate(savedInstanceState);
    }

This does not result in a crash with both Keep Activities on or off.

Tested it with multiple devices as well, seems like a better approach and setup for the readme as suggested.

is it better for the readme?

@iagormoraes the solution works in ReactActivity too. You need to still apply this: https://github.com/software-mansion/react-native-screens/issues/17#issuecomment-424704067

@sibelius to clarify, if you set the “Don’t keep activites” flag in Developer Options and background & restore your app, does it survive?

Here’s another occurrence with the latest version of screens (alpha 22), with the full stacktrace in a release build.

Caused by: android.support.v4.app.Fragment$InstantiationException Unable to instantiate fragment com.swmansion.rnscreens.b$a: calling Fragment constructor caused an exception 
    Fragment.java:386 android.support.v4.app.Fragment.instantiate
    FragmentContainer.java:33 android.support.v4.app.FragmentContainer.instantiate
    FragmentState:79 android.support.v4.app.FragmentState.instantiate
    FragmentManager.java:3080 android.support.v4.app.FragmentManagerImpl.restoreAllState
    FragmentController:152 android.support.v4.app.FragmentController.restoreAllState
    FragmentActivity.java:330 android.support.v4.app.FragmentActivity.onCreate
    ReactFragmentActivity.java:54 com.facebook.react.ReactFragmentActivity.onCreate
    MainActivity.java:15 com.[APPNAME].android.MainActivity.onCreate
    Activity.java:6910 android.app.Activity.performCreate
    Instrumentation.java:1123 android.app.Instrumentation.callActivityOnCreate
    ActivityThread.java:2746 android.app.ActivityThread.performLaunchActivity
    ActivityThread.java:2864 android.app.ActivityThread.handleLaunchActivity
    ActivityThread.java:-1 android.app.ActivityThread.-wrap12
    ActivityThread.java:1567 android.app.ActivityThread$H.handleMessage
    Handler.java:102 android.os.Handler.dispatchMessage
    Looper.java:156 android.os.Looper.loop
    ActivityThread.java:6524 android.app.ActivityThread.main
    Method.java:-2 java.lang.reflect.Method.invoke
    ZygoteInit.java:941 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
    ZygoteInit.java:831 com.android.internal.os.ZygoteInit.main


Caused by: java.lang.reflect.InvocationTargetException
    Constructor.java:-2 java.lang.reflect.Constructor.newInstance0
    Constructor.java:430 java.lang.reflect.Constructor.newInstance
    Fragment.java:364 android.support.v4.app.Fragment.instantiate
    FragmentContainer.java:33 android.support.v4.app.FragmentContainer.instantiate
    FragmentState:79 android.support.v4.app.FragmentState.instantiate
    FragmentManager.java:3080 android.support.v4.app.FragmentManagerImpl.restoreAllState
    FragmentController:152 android.support.v4.app.FragmentController.restoreAllState
    FragmentActivity.java:330 android.support.v4.app.FragmentActivity.onCreate
    ReactFragmentActivity.java:54 com.facebook.react.ReactFragmentActivity.onCreate
    MainActivity.java:15 com.[APPNAME].android.MainActivity.onCreate
    Activity.java:6910 android.app.Activity.performCreate
    Instrumentation.java:1123 android.app.Instrumentation.callActivityOnCreate
    ActivityThread.java:2746 android.app.ActivityThread.performLaunchActivity
    ActivityThread.java:2864 android.app.ActivityThread.handleLaunchActivity
    ActivityThread.java:-1 android.app.ActivityThread.-wrap12
    ActivityThread.java:1567 android.app.ActivityThread$H.handleMessage
    Handler.java:102 android.os.Handler.dispatchMessage
    Looper.java:156 android.os.Looper.loop
    ActivityThread.java:6524 android.app.ActivityThread.main
    Method.java:-2 java.lang.reflect.Method.invoke
    ZygoteInit.java:941 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
    ZygoteInit.java:831 com.android.internal.os.ZygoteInit.main


Caused by: java.lang.IllegalStateException Screen fragments should never be restored 
    Screen.java:23 com.swmansion.rnscreens.Screen$ScreenFragment.<init>
    Constructor.java:-2 java.lang.reflect.Constructor.newInstance0
    Constructor.java:430 java.lang.reflect.Constructor.newInstance
    Fragment.java:364 android.support.v4.app.Fragment.instantiate
    FragmentContainer.java:33 android.support.v4.app.FragmentContainer.instantiate
    FragmentState:79 android.support.v4.app.FragmentState.instantiate
    FragmentManager.java:3080 android.support.v4.app.FragmentManagerImpl.restoreAllState
    FragmentController:152 android.support.v4.app.FragmentController.restoreAllState
    FragmentActivity.java:330 android.support.v4.app.FragmentActivity.onCreate
    ReactFragmentActivity.java:54 com.facebook.react.ReactFragmentActivity.onCreate
    MainActivity.java:15 com.[APPNAME].android.MainActivity.onCreate
    Activity.java:6910 android.app.Activity.performCreate
    Instrumentation.java:1123 android.app.Instrumentation.callActivityOnCreate
    ActivityThread.java:2746 android.app.ActivityThread.performLaunchActivity
    ActivityThread.java:2864 android.app.ActivityThread.handleLaunchActivity
    ActivityThread.java:-1 android.app.ActivityThread.-wrap12
    ActivityThread.java:1567 android.app.ActivityThread$H.handleMessage
    Handler.java:102 android.os.Handler.dispatchMessage
    Looper.java:156 android.os.Looper.loop
    ActivityThread.java:6524 android.app.ActivityThread.main
    Method.java:-2 java.lang.reflect.Method.invoke
    ZygoteInit.java:941 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
    ZygoteInit.java:831 com.android.internal.os.ZygoteInit.main

The exception root is in this line.

@jgcmarins can you please try it with screens@1.0.0-alpha.22 then?

@K-Leon thanks for sending the stacktrace but it is missing the top of the trace (where the exception is specified) which is the most important part. Also if exception has a cause (“caused by” section) that would be an important information too