Since Nov 18th suddenly started getting huge crash spikes on standalone app with the following error: java.lang.RuntimeException: at host.exp.exponent.experience.BaseExperienceActivity$2.run (BaseExperienceActivity.java:197) at android.os.Handler.handleCallback (Handler.java:907) at android.os.Handler.dispatchMessage (Handler.java:105) at android.os.Looper.loop (Looper.java:216) at android.app.ActivityThread.main (ActivityThread.java:7625) at java.lang.reflect.Method.invoke (Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:524) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:987)
I’m unable to reproduce the issue on my One Plus 5 device and I’m not receiving any JS error reports in Sentry. I did an experiment with my colleagues Android devices and here are the results:
One Plus 5 - works
Samsung A70 - works
Google Pixel 3 - works
Samsung A8 - works
Huawei Honor 8a - crashes on app load (works fine when running in expo client though!)
After installing a system update on the Huawei phone it was no longer crashing and worked perfectly, however according to the logs its not just huawei crashing its multiple different phone models.
Is this an issue with Expo or with my JS? (I’m not receiving any JS errors in Sentry!) I tried updating to the latest expo-cli, rebuilding the binaries and deployed to the play store but it’s still crashing on certain devices.
A few unhappy customers and 1 star ratings later, the crash rate is starting to settle. Maybe Expo fixed something on their end? Can someone from the Expo team confirm this?
I’m not sure if this helped, but these are the steps I took since the crash started:
upgraded expo-cli to 3.8.0
rebuilt android app bundle and deployed to google play store
ran expo start -c and published over the air updates
@smontlouis - i suggest using sentry to report js errors, what you are seeing is likely a result of js errors leading to your app crashing. as @adamjnav pointed out in High crash rate on Android SDK35 - #2 by adamjnav “Prior to SDK35, we used to handle fatal crashes by displaying the blue Expo error screen but users made it known that they would prefer a hard crash rather than an Expo interface so we made the change recently.”
I got this earlier today. I got the logs using logcat and the relevant bit is this:
11-30 09:26:45.505 18414 18414 D AndroidRuntime: Shutting down VM
11-30 09:26:45.507 18414 18506 E CrashlyticsCore: Crashlytics must be initialized by calling Fabric.with(Context) prior to logging exceptions.
11-30 09:26:45.507 18414 18414 E AndroidRuntime: FATAL EXCEPTION: main
11-30 09:26:45.507 18414 18414 E AndroidRuntime: Process: blah.my_app, PID: 18414
11-30 09:26:45.507 18414 18414 E AndroidRuntime: java.lang.RuntimeException: Expo encountered a fatal error: Unexpected end of script
11-30 09:26:45.507 18414 18414 E AndroidRuntime:
11-30 09:26:45.507 18414 18414 E AndroidRuntime: no stack
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at host.exp.exponent.experience.a$2.run(BaseExperienceActivity.java:197)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:873)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:99)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7050)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
11-30 09:26:45.507 18414 18414 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:965)
It’s weird because:
the app works fine in the Expo app, served from expo start
prettier is happy with the source code
if I extract the shell-app.bundle from the APK and run prettier on that, prettier is happy with that too
if I run expo start -c --no-dev --minify it still works
So I’m not sure which “script” Expo thought came unexpectedly to an end. @notbrent is there a way to tell which script/bundle/whatever is the problem?
Anyway, I thought I’d try using git bisect to figure out where the problem happened. Unfortunately (or fortunately depending on how you look at it) at the end of another 5 builds it works!
So I’m not sure what broke it in the first place or what fixed it.
But I did upgrade to expo-cli 3.9.1 from 3.8.0 at some point. I thought it was before the problematic build this morning, but I’m not 100% sure.
I also stopped the server and ran expo start -c a bunch of times (once before each build).
EDIT: Of course I also reinstalled the app several times during this process, although if the app were corrupted somehow I doubt it would have installed.
If this happens again I’ll just try stopping the server, starting with -c and rebuilding to see if that gets it working. If not, I’ll try something more drastic like a git bisect.