Standalone Builds Crash on Launch

I also have been having this issue and was on SDK 40. While launched via Expo Go, everything ran fine and there were no exceptions thrown. Once built, iOS was crashing (Android seemed to have worked fine).

I have Sentry running, but this crashes far too early (on launch) for Sentry to even catch an exception, so it is useless in this scenario.

A fix I tried was upgrading to SDK 41, which was a bigger pain than I expected, but I got that working. Simulator and everything was working fine and I built and pushed the two new versions to Android and iOS stores for testing - both are crashing now on launch.

I am stuck and there is not enough information or debugging tools to figure this out. What does Expo do differently on launch for standalone apps than what happens via Expo Go? If a dev can lay out the life cycle of an app launching, that can help narrow this all down - hopefully.

EDIT: Here is a snippet of the crash logs I get:

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Triggered by Thread:  0

Last Exception Backtrace:
0   CoreFoundation                	0x19cd739d8 __exceptionPreprocess + 216 (NSException.m:199)
1   libobjc.A.dylib               	0x1b10f9b54 objc_exception_throw + 56 (objc-exception.mm:565)
2   ComJustpicksomethingJustpicksomething	0x104e3cdc8 -[EXAppViewController maybeShowError:] + 1160 (EXAppViewController.m:221)
3   ComJustpicksomethingJustpicksomething	0x104e5e2d8 0x104c14000 + 2400984
4   libdispatch.dylib             	0x19c9ac280 _dispatch_client_callout + 16 (object.m:559)
5   libdispatch.dylib             	0x19c95bc5c _dispatch_async_and_wait_invoke + 92 (queue.c:1545)
6   libdispatch.dylib             	0x19c9ac280 _dispatch_client_callout + 16 (object.m:559)
7   libdispatch.dylib             	0x19c95b05c _dispatch_main_queue_callback_4CF$VARIANT$mp + 896 (inline_internal.h:2548)
8   CoreFoundation                	0x19ccf35e0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 (CFRunLoop.c:1790)
9   CoreFoundation                	0x19cceda88 __CFRunLoopRun + 2480 (CFRunLoop.c:3118)
10  CoreFoundation                	0x19ccecba0 CFRunLoopRunSpecific + 572 (CFRunLoop.c:3242)
11  GraphicsServices              	0x1b3a55598 GSEventRunModal + 160 (GSEvent.c:2259)
12  UIKitCore                     	0x19f5de2f4 -[UIApplication _run] + 1052 (UIApplication.m:3253)
13  UIKitCore                     	0x19f5e3874 UIApplicationMain + 164 (UIApplication.m:4707)
14  ComJustpicksomethingJustpicksomething	0x104c1b9f8 main + 88 (main.m:8)
15  libdyld.dylib                 	0x19c9cb568 start + 4

Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001c850a84c __pthread_kill + 8
1   libsystem_pthread.dylib       	0x00000001e48e49e8 pthread_kill + 212 (pthread.c:1392)
2   libsystem_c.dylib             	0x00000001a5a6e970 __abort + 112 (abort.c:147)
3   libsystem_c.dylib             	0x00000001a5a6e900 abort + 112 (abort.c:118)
4   libc++abi.dylib               	0x00000001b11f5cc8 abort_message + 128 (abort_message.cpp:76)
5   libc++abi.dylib               	0x00000001b11e7ca0 demangling_terminate_handler() + 296 (cxa_default_handlers.cpp:67)
6   libobjc.A.dylib               	0x00000001b10f9e04 _objc_terminate() + 124 (objc-exception.mm:701)
7   libc++abi.dylib               	0x00000001b11f5154 std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)
8   libc++abi.dylib               	0x00000001b11f50ec std::terminate() + 44 (cxa_handlers.cpp:88)
9   libdispatch.dylib             	0x000000019c9ac294 _dispatch_client_callout + 36 (object.m:562)
10  libdispatch.dylib             	0x000000019c95bc5c _dispatch_async_and_wait_invoke + 92 (queue.c:1545)
11  libdispatch.dylib             	0x000000019c9ac280 _dispatch_client_callout + 16 (object.m:559)
12  libdispatch.dylib             	0x000000019c95b05c _dispatch_main_queue_callback_4CF$VARIANT$mp + 896 (inline_internal.h:2548)
13  CoreFoundation                	0x000000019ccf35e0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 (CFRunLoop.c:1790)
14  CoreFoundation                	0x000000019cceda88 __CFRunLoopRun + 2480 (CFRunLoop.c:3118)
15  CoreFoundation                	0x000000019ccecba0 CFRunLoopRunSpecific + 572 (CFRunLoop.c:3242)
16  GraphicsServices              	0x00000001b3a55598 GSEventRunModal + 160 (GSEvent.c:2259)
17  UIKitCore                     	0x000000019f5de2f4 -[UIApplication _run] + 1052 (UIApplication.m:3253)
18  UIKitCore                     	0x000000019f5e3874 UIApplicationMain + 164 (UIApplication.m:4707)
19  ...ksomethingJustpicksomething	0x0000000104c1b9f8 main + 88 (main.m:8)
20  libdyld.dylib                 	0x000000019c9cb568 start + 4```

Hi @jdobry

You say it’s crashing on Android too now? What crash logs do you get when you run adb logcat while the phone is plugged into the computer with USB debugging enabled?

From the other thread you posted on it sounds like you have tried running the app using:

expo start --no-dev --minify

but that it did not crash. Is that correct?

If the logs don’t give you any useful info and it doesn’t crash with expo start --no-dev --minify, then what I would probably try is basically doing a binary search.

i.e. comment out half of the code (in such a way that the app still runs.) Does it crash now? If not, uncomment that code and comment out the other half. Does it crash now? Hopefully it will crash in one half and not the other. Assuming that’s the case you’ve narrowed it down. Now take the half that does crash and comment half of that out so that you have only a quarter of the code still running. Does it crash? If so you’ve narrowed it down to that quarter of the code. If not, see if it’s in the other quarter.

Continue narrowing it down by commenting out more and more code. Of course it might be tricky to comment out some code and still keep the app able to run, but I hope you get the idea and that it helps you to narrow down which part of the code the crash is coming from.

When you can’t narrow it down any further, you’ll either see the problem yourself, or you’ll have a relatively small skeleton app that still demonstrates the problem that you can post for us to try out.

@wodin thanks for helping. So, I notice the following when running --no-dev --minify and have always noticed this on both iOS and Android. The first “hard” load results in an error screen. I then have to refresh the app and it will finish loading assets.

When testing on Android just now, I noticed the “view error log” at the bottom of the “Something went wrong” screen. This said Uncaught Error: java.lang.Exception: Failed to load all assets.

Running adb logcat alongside a hard load shows this error a number of times:

06-08 08:07:34.915  1707  1890 E LoaderTask: Unexpected error encountered while loading this app
06-08 08:07:34.915  1707  1890 E LoaderTask: java.lang.Exception: Failed to load all assets
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.RemoteLoader.handleAssetDownloadCompleted(RemoteLoader.java:15)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.RemoteLoader.access$700(RemoteLoader.java:1)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.RemoteLoader$2.onFailure(RemoteLoader.java:2)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.FileDownloader$3.onFailure(FileDownloader.java:1)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.FileDownloader$1.onFailure(FileDownloader.java:1)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.FileDownloader$4.onFailure(FileDownloader.java:2)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:11)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:3)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
06-08 08:07:34.915  1707  1890 E LoaderTask: 	at java.lang.Thread.run(Thread.java:923)
06-08 08:07:34.916  1707  1890 E LoaderTask: Failed to download remote update
06-08 08:07:34.916  1707  1890 E LoaderTask: java.lang.Exception: Failed to load all assets
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.RemoteLoader.handleAssetDownloadCompleted(RemoteLoader.java:15)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.RemoteLoader.access$700(RemoteLoader.java:1)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.RemoteLoader$2.onFailure(RemoteLoader.java:2)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.FileDownloader$3.onFailure(FileDownloader.java:1)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.FileDownloader$1.onFailure(FileDownloader.java:1)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at expo.modules.updates.loader.FileDownloader$4.onFailure(FileDownloader.java:2)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:11)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:3)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
06-08 08:07:34.916  1707  1890 E LoaderTask: 	at java.lang.Thread.run(Thread.java:923)

I do also see this error thrown prior:

06-08 08:07:34.914  1707  1890 E RemoteLoader: Failed to download asset from http://IP_ADDR:PORT/node_modules/expo/AppEntry.bundle?platform=android&dev=false&hot=false&minify=true
06-08 08:07:34.914  1707  1890 E RemoteLoader: java.net.SocketTimeoutException: timeout
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.l$d.newTimeoutException(Okio.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.a.exit(AsyncTimeout.java:7)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.a$b.read(AsyncTimeout.java:4)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.p.a(RealBufferedSource.java:4)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.p.V(RealBufferedSource.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http1.Http1ExchangeCodec.readHeaderLine(Http1ExchangeCodec.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http1.Http1ExchangeCodec.readResponseHeaders(Http1ExchangeCodec.java:3)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.connection.Exchange.readResponseHeaders(Exchange.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:27)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:10)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:6)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:10)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:22)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:10)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:22)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:10)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:6)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:10)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:1)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:13)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:2)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:3)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at java.lang.Thread.run(Thread.java:923)
06-08 08:07:34.914  1707  1890 E RemoteLoader: Caused by: java.net.SocketException: Socket closed
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at java.net.SocketInputStream.read(SocketInputStream.java:209)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at java.net.SocketInputStream.read(SocketInputStream.java:144)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.l$b.read(Okio.java:4)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	at m.a$b.read(AsyncTimeout.java:2)
06-08 08:07:34.914  1707  1890 E RemoteLoader: 	... 24 more
06-08 08:07:34.914  1707  1890 E RemoteLoader: Failed to load all assets

I see that it is trying to load from local Metro - and I do see assets trying to be compiled. When the app crashes, the Javascript bundling progress is at ~81%. Again, refreshing the app, to force another bundle fixes this and it continues all of the way through.

Once it finishes bundling and builds successfully, the app works fine.

hmmm… it looks a bit like you have some networking problems.

Could you post the error you get from the standalone app? Is it also complaining about the app bundle?

Also, do you get the same sort of errors if you create a new blank app?

Let me see what the standalone crash logs are like for Android. iOS crash log is always the log attached at the top of this post - not a lot to the actual details on that crash.

The crash always happens at the initial loading when standalone (when the splash screen is shown).

EDIT: I will add that development is always done via Tunnel turned on and the IP I masked is a local IP address.

I have tried all possible “network” problems when trying to build the app locally and it always continues to throw the same error of not being able to download assets - I wonder if there is some sort of timeout happening?

I have commented out my whole app besides a “Hello World” text rendering and still it fails.

I assume you’re talking about the initial problem when downloading the bundle in development mode? OK, let’s ignore that for the moment and look at what adb logcat says when the standalone app dies.

I will say, Android logs did provide some useful stuff, but still confused by it:

06-09 08:26:31.959 30729 30814 W ReactNativeJS: Unable to start your application. Please refer to https://expo.fyi/no-registered-application for more information.
06-09 08:26:31.964 30729 30814 E ReactNativeJS: TypeError: undefined is not an object (evaluating 't.default.manifest.android.config.googleMaps')

The snippet defined in the config:

...
"android": {
      "versionCode": 43,
      "package": "X",
      "playStoreUrl": "X",
      "googleServicesFile": "./google-services.json",
      "config": {
        "googleMaps": {
          "apiKey": "X"
        }
      },
      "permissions": [
        "ACCESS_COARSE_LOCATION",
        "ACCESS_FINE_LOCATION"
      ]
    },
...

So not sure why that error is throwing? Digging through the logs more, right above this error, I do see the log of what Expo converts to its initial props. I do not see a googleMaps key but I do see the actual api key I have set come up under current_key in the props.

I also see this get logged but higher up before the crash:

06-09 08:26:31.275 30729 30729 E unknown:ReactNative: Unable to launch logbox because react was unable to create the root view
06-09 08:26:31.293 30729 30814 W System.err: java.io.FileNotFoundException: shell-app-manifest.json
06-09 08:26:31.293 30729 30814 W System.err: 	at android.content.res.AssetManager.nativeOpenAsset(Native Method)
06-09 08:26:31.293 30729 30814 W System.err: 	at android.content.res.AssetManager.open(AssetManager.java:874)
06-09 08:26:31.293 30729 30814 W System.err: 	at android.content.res.AssetManager.open(AssetManager.java:851)
06-09 08:26:31.293 30729 30814 W System.err: 	at versioned.host.exp.exponent.modules.universal.ScopedFileSystemModule.getBundledAssets(ScopedFileSystemModule.java:2)
06-09 08:26:31.293 30729 30814 W System.err: 	at versioned.host.exp.exponent.modules.universal.ScopedFileSystemModule.getConstants(ScopedFileSystemModule.java:2)
06-09 08:26:31.293 30729 30814 W System.err: 	at org.unimodules.adapters.react.NativeModulesProxy.getConstants(NativeModulesProxy.java:9)
06-09 08:26:31.293 30729 30814 W System.err: 	at com.facebook.react.bridge.JavaModuleWrapper.getConstants(JavaModuleWrapper.java:9)
06-09 08:26:31.293 30729 30814 W System.err: 	at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
06-09 08:26:31.293 30729 30814 W System.err: 	at android.os.Handler.handleCallback(Handler.java:938)
06-09 08:26:31.293 30729 30814 W System.err: 	at android.os.Handler.dispatchMessage(Handler.java:99)
06-09 08:26:31.293 30729 30814 W System.err: 	at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:1)
06-09 08:26:31.293 30729 30814 W System.err: 	at android.os.Looper.loop(Looper.java:223)
06-09 08:26:31.293 30729 30814 W System.err: 	at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:8)
06-09 08:26:31.293 30729 30814 W System.err: 	at java.lang.Thread.run(Thread.java:923)
06-09 08:26:31.311 30729 30814 D i       : WARNING: getPackageName called on ScopedContext
``

EDIT: I think this is a compile error by Expo with the new SDK 41 (hence why Android started failing after my upgrade attempt).

In my code I am referencing the `googleServicesFile` and I see that show up as part of the "initialProps" and I see "permissions" part of the app.json file but I do not see the "config" section at all.

I think this is a compile error by Expo with the new SDK 41 (hence why Android started failing after my upgrade attempt).

In my code I am referencing the googleServicesFile and I see that show up as part of the “initialProps” and I see “permissions” part of the app.json file but I do not see the “config” section at all.

EDIT: Expo says this:

"config": (object) - Note: This property key is not included in the production manifest and will evaluate to undefined. It is used internally only in the build process, because it contains API keys that some may want to keep private.

This reminded me that since I do a Google Places API call and wanted to use the same config value that was in the app.json.

So I looked and found this in my code :exploding_head:

envVars.GOOGLE_PLACES_KEY =
    Platform.OS === 'android'
      ? Constants.manifest.android.config.googleMaps.apiKey
      : Constants.manifest.ios.config.googleMapsApiKey;

Testing now what happens when ripping out this code.

EDIT: This is what was causing the crash and I have verified the standalone builds are no longer crashing! Ty for the help. I know the documentation says the config turns undefined on prod only - why not always have it convert into undefined? I can’t see a usage of being able to access the config in dev but not prod.

1 Like