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?
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 @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 publishedUrl().
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.