My app has problems under certain network conditions. Specifically when a release build is running on a phone. The problems don’t manifest when the bundle is delivered via expo-cli. It only manifests when running with the bundle in the assets dir.
We have a corporate firewall strange behaviour and I would like to debug the native code in a running detached build.
Unfortunately, as soon as I add “Debuggable True” to my gradle file, the app wants the local bundler to serve it a bundle.
How can I assemble a release build that is debuggable?
You can pass the
expo start to replicate the JS bundle that is served when you publish and fetch from the production URL.
Thanks for the suggestion. The problem is actually that I need to troubleshoot why a release build doesn’t function properly in our network environment. I would like to trace through the java code. Therefore I need a debug build.
The problems are not reproducible in a dev build because it is not trying to connect and download/check bundles and manifests.
Hi @timdelange - you’ll need to eject to ExpoKit in order to create a debug build where you can step through the java code.
Are you experiencing problems with downloading the JS bundle from Expo’s servers through your network environment?
Hi @esamelson - I have ejected, this is a detached build. But to get an apk that will do the ota via expo instead of looking for a running expo bundler instance is the challenge.
Yes, when the app is used on a prepaid phone, and the phone has no data and airtime balance, the telco doesnt completely disconnect you, instead they drop all https packets and redirects http calls to their “out of money” page.
This seems to confuse expo. And can cause our app to hang, and certain promises to never resolve. Especially libs that use the filesystem or networking layer.
My guess is that the thread worker pool gets filled up and somehow blocks the runloop. Its a big issue for us. The app works fine in airplane mode. I have confirmed in our lab that blocking https://d1wp6m56sqw74a.cloudfront.net solves the app issues. This is not a solution, because we cannot control the networking environment in the wild.
Hi @timdelange - interesting, you’re right, that’s a case that we probably don’t handle correctly right now. What is your app’s
updates configuration in app.json? If you don’t have
fallbackToCacheTimeout set to 0, you could try that, as that should make it load the cached JS bundle before the network call errors.
What you can try in order to get the kind of debug build you want is to modify your
MainActivity.java file and replace the string return by
developmentUrl() with the one returned by
Hi @esamelson - yes, we do have fallbackToCacheTimeout set to 0(one of the first things we did). The app still hangs unless we make the network reject(not drop) packets to d1wp6m56sqw74a.cloudfront.net.
Thanks for the developmentUrl() tip, we will try that.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.