🚨 Android app freezes on start


#41

I deployed the release of my app with the http module enabled, and some customers that was frozen told me it was ok right after the update. (I can’t reproduce the bug on my phones right now).

So i think it’s ok

But, don’t you think this module should be enabled by default now in trigger.io ? (maybe it’s in progress from your side)

Thanks


#42

We’ll indeed be integrating the httpd module into ForgeCore as of v2.8.x of the platform :slight_smile:

You can track the issue here:


#43

I’m not sure if it’s the same issue, but we’re starting to see the same symptoms EVEN WITH THE HTTPD FIX IN PLACE, on Android 9.1. Does not repro on 9.0. Has anyone seen this / ideas?


#44

Same here, is there perhaps a different version of httpd module that’s needed for 9.1 ?


#45

Can you please give it a try on:

"platform_version": "v2.8.1alpha-4"

It’s an alpha so some other things will probably break and you’ll have to disable the httpd module as it’s now compiled in by default on v2.8.x.

Change logs here:

https://trigger.io/docs/current/api/beta_release_notes.html


#46

I tried this but now am getting this error:

Error in callback for auth.check: Cannot read property 'get' of undefined
You can try reloading this page — if the error persists please contact us with the details below so we can look into it.
TypeError: Cannot read property 'get' of undefined
    at child.sidebarContents (https://toolkit-local.com:38394/static/js/apps/apps.js:938:96)
    at child.initialize (https://toolkit-local.com:38394/static/js/apps/apps.js:869:47)
    at child.Backbone.View (https://toolkit-local.com:38394/static/js/lib/backbone.js:1260:21)
    at child [as constructor] (https://toolkit-local.com:38394/static/js/lib/backbone_cached_model.js:430:39)
    at child [as constructor] (https://toolkit-local.com:38394/static/js/lib/backbone_cached_model.js:430:39)
    at child [as constructor] (https://toolkit-local.com:38394/static/js/lib/backbone_cached_model.js:430:39)
    at child [as constructor] (https://toolkit-local.com:38394/static/js/lib/backbone_cached_model.js:430:39)
    at new child (https://toolkit-local.com:38394/static/js/lib/backbone_cached_model.js:430:39)
    at child.appForge (https://toolkit-local.com:38394/static/js/router.js:308:19)
    at child.<anonymous> (https://toolkit-local.com:38394/static/js/router.js:16:27)

#47

I’m trying to spin up a 9.1 instance to test locally ( SDK manager is slow as always) but that a side. Have you tried changing the default httpd port to something other then 80 or 8000?

I have seen the issue happen with port 80 or 8000, if I set it to something like 8346 or what ever it appears to work.

Also, as it is based off chrome I’m not sure if its 9.1 or chrome? What version of chrome do you have installed on 9.1 ? I’m on 9 with latest at the moment.


#48

Thank you for the suggestion! We had previously set it to a high number (config below) when originally reporting the error, so that option doesn’t seem to work.

"httpd": {
            "config": {
                "port": 31337,
                "url": "https://localhost:31337/src/index.html",
                "certificate_path": "localhost.p12",
                "certificate_password": "insecure"
            },
            "version": "1.4"

#49

Ah, my bad - I’d forgotten to push the release to production! :man_facepalming:

Can you please try again?


#50

Some adb logcat output and maybe even a https://trigger.io/catalyst/ would be helpful too so I can check if it’s dying in the same way as previously.


#51

Out of curiosity, what API level are you using for android, 29?


#53

It seems after released to production the latest alpha is working well! Thank you!!


#54

@antoinevg In the past 12h the issue also hit us again. The number of reports increases and we are able to reproduce the problem. The symptoms are the same.

We tried out the v2.8 platform preview, which seems to fix the issue, but has other issues (ex.: insets).

We don’t want to use the preview to make a release for our customers. It would interesting to know what the changes between v2.7 and v.2.8 are in detail. In other words: Do you think it’s feasible to come up with another minimal release to just fix the Android freeze problem and without further changes…?

If not, what do you think is missing to get v2.8 stable for Android.

(I think I don’t need to stress how urgent this problematic is for us)


#55

The major differences between Forge v2.7 and v2.8 that could be related to this issue are:

  1. v2.8 has been updated to compile against the Android 29 SDK.
  2. v2.8 has migrated from the old Android support libraries to AndroidX/JetPack

Trying to do a minimal v2.7 that implements only these two items will have a pretty long timeframe and probably leave us in the exact same position re: the layout bugs you’re seeing on Samsung Galaxy S4/S5 hardware

You can track the S4/S5 issue with v2.8.1beta-x here:

Known issues with v2.8.1beta-x are here:


#56

Some (good?) news.

On a HUAWEI P30 lite running latest updates Forge apps now blank screen ALL the time. Even on first run.

If there’s anything causing this from our side it should now be a LOT easier to figure out what it is.

Android: 9.1.0.241
Chrome: 76.0.3809.132
Android System WebView: 74.0.3729.136

Will keep everyone posted.


#57

I’m glad you can reproduce it, too. Good news!

We have it on

Sony Xperia
Android 9
Chrome 76.0.3809.132

Android 8.1.0
Staffbase 4.0.101
Chrome 77.0.3865.73

Galaxy S7 with Samsung Stock Android 8
Chrome: 77.0.3865.73
Browser: “Samsung Internet” 9.4.00.45


#58

This is out of curiosity mainly but is this seeming to be device specific?

I was testing out apps on my galaxy s10 with all updated (android 9, chrome 76.0.3809.132 [same system webview]) and everything works as expected.


#59

We suspect that this is just because Google enables/disables some Flags during rollout.


#60

Things stay strange. We noticed that a reinstall via Google Play Store helps. At least we observed this on the Sony Xperia mentioned above.

This ofc is just a workaround. But mby also give @antoinevg a hint…


#61

Tx, more info helps!

I should have mentioned that I can currently only reproduce this on non-httpd builds.

Am I right in assuming that you’re seeing a return of the behaviour on httpd builds?

That said, given that I’m now able to attach a native debugger I may have found one explanation of the ORIGINAL blank screen before we started working around with the httpd module.

To cut a long story short it looks like Google are fiddling with their security model and content type detection for content loaded via a custom ContentProvider.

In the past we could leave it up to the WebView to detect content but the latest version on my phone now definitely requires that I explicitly specify a mime type before it’s prepared to load it.

I don’t know if this will fix the issue but I’ll be pushing a new build of v2.7 with this change shortly and maybe we get a few more data points?