Issues getting values from stored variables without an assigned value

Does anyone know how to fix these crashes? I was looking at my app stats and my Android crash rate has climbed to 20.17% over the past 30 days. This is what I get from the crash reports:

java.lang.RuntimeException: 
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:4035)
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:4201)
  at android.app.servertransaction.LaunchActivityItem.execute (LaunchActivityItem.java:103)
  at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:135)
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:95)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2438)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:226)
  at android.os.Looper.loop (Looper.java:313)
  at android.app.ActivityThread.main (ActivityThread.java:8663)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:567)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Caused by: androidx.fragment.app.Fragment$InstantiationException: 
  at androidx.fragment.app.Fragment.instantiate (Fragment.java:566)
  at androidx.fragment.app.FragmentContainer.instantiate (FragmentContainer.java:57)
  at androidx.fragment.app.FragmentManager$3.instantiate (FragmentManager.java:390)
  at androidx.fragment.app.FragmentStateManager.<init> (FragmentStateManager.java:74)
  at androidx.fragment.app.FragmentManager.restoreSaveState (FragmentManager.java:2454)
  at androidx.fragment.app.FragmentController.restoreSaveState (FragmentController.java:196)
  at androidx.fragment.app.FragmentActivity.onCreate (FragmentActivity.java:287)
  at androidx.appcompat.app.AppCompatActivity.onCreate (AppCompatActivity.java:115)
  at com.facebook.react.ReactActivity.onCreate (ReactActivity.java:44)
  at com.thunkable.live.MainActivity.onCreate (MainActivity.java:17)
  at android.app.Activity.performCreate (Activity.java:8290)
  at android.app.Activity.performCreate (Activity.java:8270)
  at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1329)
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:4009)
Caused by: java.lang.reflect.InvocationTargetException: 
  at java.lang.reflect.Constructor.newInstance0 (Native Method)
  at java.lang.reflect.Constructor.newInstance (Constructor.java:343)
  at androidx.fragment.app.Fragment.instantiate (Fragment.java:548)
Caused by: java.lang.IllegalStateException: 
  at com.swmansion.rnscreens.ScreenFragment.<init> (ScreenFragment.java:42)

There is something going awry in the app, but I have no idea what and I can’t tell from this exactly what is going on. Any thoughts/ideas? I know a couple of my Android users, so I asked them if they get crashes. They said the app sometimes crashes as soon as they launch it, but then it opens up with no issues. I don’t know that helps or not, but I would like to figure out how to keep this from crashing…

I saw another thread on here where only 1 user/device was impacted. This feels pretty widespread for my app. Here is a screenshot:

Hey @ronniejh, i’ve not heard much about this from other users. Are the crashes only happening during app opening? Do you have any other thunkable built apps demonstrating this same kind of behavior?

@jared, that’s the only feedback I have. I did notice it on my Android tablet a few times. I haven’t had any complaints, really, but I have a couple of friends with Android so I asked them about crashes. They said they only noticed it would crash when it started, but would run fine after that. This is the only app I have right now, so I’m afraid I don’t have any others to check. I’m just concerned that Google has now identified this as a “bad behavior” on my app and I really don’t know why it would be crashing.

This is just a guess but if it’s crashing on first launch and then working fine, there may be a stored variable that you’re setting a value for that crashes the app when it’s null. I would check to see the order/timing of stored variables in your app. Because after the first launch, all stored variables that you’ve set values for will retain those values on next launch.

3 Likes

Ah! I do have a lot of variables and that makes complete sense! Thanks for the hint! I’m working on my next version, so I’ll see what I need to adjust.

Thanks! :raised_hands:

I think I may have found it. I had some variables from my subscription portion which I was calling on my Home screen, but those aren’t even initialized until the user goes to the Settings screen. I’m not sure if that would cause the issue with it crashing and then running ok after restarting since those variables would never have loaded. I’ll make some changes to that stuff and test it out to see what happens. At least you got me looking at things that were out of whack, if nothing else!

3 Likes

I guess I’m facing the same issue.

java.lang.RuntimeException: 
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:3477)
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:3620)
  at android.app.servertransaction.LaunchActivityItem.execute (LaunchActivityItem.java:83)
  at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:135)
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:95)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2183)
  at android.os.Handler.dispatchMessage (Handler.java:107)
  at android.os.Looper.loop (Looper.java:241)
  at android.app.ActivityThread.main (ActivityThread.java:7604)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:941)
Caused by: androidx.fragment.app.Fragment$InstantiationException: 
  at androidx.fragment.app.Fragment.instantiate (Fragment.java:566)
  at androidx.fragment.app.FragmentContainer.instantiate (FragmentContainer.java:57)
  at androidx.fragment.app.FragmentManager$3.instantiate (FragmentManager.java:390)
  at androidx.fragment.app.FragmentStateManager.<init> (FragmentStateManager.java:74)
  at androidx.fragment.app.FragmentManager.restoreSaveState (FragmentManager.java:2454)
  at androidx.fragment.app.FragmentController.restoreSaveState (FragmentController.java:196)
  at androidx.fragment.app.FragmentActivity.onCreate (FragmentActivity.java:287)
  at androidx.appcompat.app.AppCompatActivity.onCreate (AppCompatActivity.java:115)
  at com.facebook.react.ReactActivity.onCreate (ReactActivity.java:45)
  at com.thunkable.live.MainActivity.onCreate (MainActivity.java:20)
  at android.app.Activity.performCreate (Activity.java:7822)
  at android.app.Activity.performCreate (Activity.java:7811)
  at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1328)
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:3452)
Caused by: java.lang.reflect.InvocationTargetException: 
  at java.lang.reflect.Constructor.newInstance0 (Native Method)
  at java.lang.reflect.Constructor.newInstance (Constructor.java:343)
  at androidx.fragment.app.Fragment.instantiate (Fragment.java:548)
Caused by: java.lang.IllegalStateException: 
  at com.swmansion.rnscreens.ScreenFragment.<init> (ScreenFragment.kt:41)

I believe I have a good sample that maybe helps:
2.94K occurrences on last 30 days
4.08K occurences all time
1.77K impacted users all time
the most problematic android version is 11

These numbers are from one of my apps, there is other apps that are clones of this one and having the same error.

I also found other posts here in community with this same java error.

A common source of this issue is using a stored variable that hasn’t a value yet or using a variable that hasn’t been initialized can cause this too.

@ronnie things looking better for you?

2 Likes

I think so, @jared! I haven’t noticed any issues since I started cleaning things up and made sure any variables used later in the app weren’t called on the initial load. Thunkable Live testing has been favorable anyway. :+1::raised_hands:

1 Like

All my app variables are initialized at first screen.
But stored variables, cannot be initialized by definition, neither by my code flow.

For example: this is in my first screen, on load.

  • hideStart is a variable that controls viewing of one start screen with instructions of the app… the user may hide this to the next runs;
  • The same happens with savePwd, that remembers the password to not ask it again to the user;
    image
    Can it be the problem? How to make it work properly?

When working with stored variable, you need to check if that variable is .null. (never had a value) or not.
When you initialize a stored variable, by default, it gets .null. value (like it is blank, without any value).
So you need to check it. If <>.null., then you can assign to it a value, if not, it already has a value “stored” that can be used, replaced, or whatever you want.

3 Likes

Thanks for your reply… I’ll give it a try.

Well, I initiate the variables properly and published an update to my app on Play Store… but it’s still showing the same crash on Play Console Crashes and ANRs details page.
I’ll follow this report on next days, because I just pushed the update today.
Any ideas and thoughts will be very appreciated!

I know it’s small data yet, but if it helps to understand:

@jared Is it possible to alleviate this issue behind the scenes? I’m not sure why we need to check for a null value every time we use a new stored variable when we don’t need to do that for app or cloud variables.

I can say that at this time, there’s no way around it. I’ll bring this up during our staff meeting on Tuesday and can com back with any updates.

2 Likes

Thanks, @jared. It’s not a huge need… just something that feels extra to have do for every stored variable and also something that throws off new users. So unless it’s necessary, it’s probably better if we don’t need to check for null values at startup.

4 Likes