🚨 Android app freezes on start


#21

Say here. No http module in use for Android.


#22

I suspect a check, or something done by chrome only one time for a given package since last release.

Example :slight_smile:

Samsung S8 with the 75.0.3770.89

  1. 2 days ago : i install my production application for the first time on this device. Kill it. FREEZE.
  2. I Uninstall the application
  3. Right now today, still with 75.0.3770.89, i reinstall the application, and impossible to reproduce the bug… no freeze, anyway.

I have 3 devices where i could reproduce this. In the SONY, uninstall / reinstall the application didn’t solve the problem.

If i can help…


#23

My observations are like this:

  1. It happens only if the app is “closed” (killed) by the user. It doesn’t if just by switching between apps (Resume).
  2. “Clear Storage” repairs the app. At least, until it’s killed the next time.

-> Mby Chrome doesn’t leave the storage in a clean state, when the app is killed. There is a lock file (webview_data.lock)…
-> Mby Chrome waits endlessly to obtain the lock…

apps/
`-- <packageName>
    |-- _manifest
    |-- r
    |   |-- app_database
    |   |-- app_reload-live
    |   |-- app_reload-update
    |   |-- app_textures
    |   `-- app_webview
    |       |-- blob_storage
    |       |   `-- 5fcc8879-ae45-4d31-bff0-436ab78bfebf
    |       |-- GPUCache
    |       |   |-- index
    |       |   `-- index-dir
    |       |       `-- the-real-index
    |       |-- pref_store
    |       |-- variations_seed
    |       |-- variations_stamp
    |       |-- Web\ Data
    |       |-- Web\ Data-journal
    |       `-- webview_data.lock
    `-- sp
        |-- embryo.xml
        |-- reload.xml
        `-- WebViewChromiumPrefs.xml

#24

Cool, tx for all the feedback!

At the moment I’m only seeing the issue if I’m trying to use Forge with content:// urls (i.e. without a httpd module)

With the httpd module loaded everything works fine.

Can you please try it on your side with the httpd module?

You’ll have to configure it as https:// - check this topic for a working config:


#25

That was a good theory but it looks like that lock file exists irrespective. Deleting it during app startup doesn’t seem to change change anything either.

Unfortunately I also seem to have finally lost the ability to recreate the issue on my side at some point so I’m not currently able to systematically try deleting other files.

If you want to give it a shot, override onApplicationCreate in a module’s EventListener.java and try something along these lines:

    @Override
    public void onApplicationCreate() {
        String dataDir = ForgeApp.getActivity().getApplicationContext().getApplicationInfo().dataDir;
        File root = new File(dataDir + "/" + "app_webview");
        if (root.exists()) {
            File[] files = root.listFiles();
            if (files != null) {
                for (File file : files) {
                    ForgeLog.d(" -> " + file);
                    if (file.equals("webview_data.lock")) {
                        ForgeLog.d("Deleting: " + file);
                        file.delete();
                    }
                }
            }
        }
    }

(Also: Try onCreate if you’re having issues with File access - I can’t remember if the context is created yet at that point or not!)

Current status:

  1. My absolute best guess at this point is that the underlying issue is a new bug (feature?) with Android custom content providers.
  2. As a result content obtained from content:// urls are no longer being loaded by the Android WebView. (Can read the data fine from the Forge runtime though)
  3. The Android WebView is still working fine. It’s just displaying an empty document.
  4. The Android WebView throws no errors during this.
  5. The problem does not occur when running the Forge runtime through a (native not JS) debugger.
  6. So we have zero visibility on what’s going on inside Chrome.
  7. As near as I can tell https:// URL’s are unaffected by this issue. Loading either remote sites or content from the local httpd module both work fine for me.

Bonus: Change logs for the Android WebView are here, nothing’s jumped out at me but maybe another pair of eyes sees something obvious:

https://chromium.googlesource.com/chromium/src/+log/74.0.3729.182..75.0.3770.89?n=10000

Which, finally, brings us to the current options for remediation:

  1. Ask customers to uninstall all Chrome & System WebView updates and then reinstall them.
  2. Move apps to the httpd module.
  3. Wait for Google to release an update of the WebView without this issue. (if ever)

:confused:


#26

I looked into the changes from 75.0.3770.89 to 76.0.3809.21, which we think works again.

There are a bunch of storage related commits, which also sound like resolving some race conditions.

Examples:


#27

@antoinevg We are about to contact people from the Chrome engineering team. Could sum up briefly what happens in ForgeCore on Android when the App launches (with content:// scheme)?


#28

From our side everything is functioning normally with no failures, error or log messages, it just doesn’t load pages with content:// scheme backed with a custom ContentProvider.

Basically this:

// an example url would be: content://io.trigger.testing/src/index.html

public class ForgeContentProvider extends ContentProvider {
    @Override
    public AssetFileDescriptor openAssetFile(Uri uri, String mode) {
        Context context = ForgeApp.getActivity().getContext();
        Uri fileUri = Uri.parse("file:///android_asset" + uri.getPath());
        AssetFileDescriptor fd = context.getAssets().openFd(fileUri.toString());
        return fd;
    }
}

No problem reading data from the AssetFileDescriptor before handing it off.

Edit: Usual disclaimers apply. This might have nothing to do with anything. I can’t reproduce the issue at all anymore from my side so this could have purely been something within my own environment.


#29

We are playing around with the httpd module active. Things are looking promising so far.
Is there an easy (built-in) way to migrate the storage from content:// over to https://?


#30

No easy way.

iOS splits web storage into per-site files. Android stores it in some kind of central database.


#31

I found a solution, which works for us. Unfortunately, I’m unable to come up with a more generic one, because my attempt to include https://github.com/litl/android-leveldb as library failed (see: Android: How to add a gradle repository).


#32

Suddenly, the problem is gone. :man_shrugging:t2: It vanished like it appeared, device after device started to work again.
Fun fact: Without a Chrome version bump, it stayed on 75.0.3770.101.

@iolivier Can you confirm this?


#33

We are seeing what sounds like the same issue on a number of our apps. Android-only, the app freezes while rendering the splash screen and won’t proceed further than that.

We haven’t been able to get repro in-house, but are receiving the same report, starting mid-last week, from a number of our clients, across different apps we have produced with the latest Trigger platform, v2.7.8.


#34

Any advice on this? We are hearing a growing roar from our existing apps, ones that used to work fine, now seeing it freeze on startup. So far, it appears to be newer / latest devices. We’re still trying to get exact OS build and hardware information from some of the reports.


#35

Using the httpd module fixed it for us.
You can find a example configuration here: Android 9 wont build [FORGE WebView error] net::ERR_CONNECTION_REFUSED


#36

Thank you, scthi! Looks like that works for us, as well.


#37

Since 2 days I receive a lot of complaints that app freeze. It’s dramatic. Could you give a clear modifications with http module to do ? I never used this module. I don’t load any file or image at loading or after, it’s a simple app.

Could you help me understand ?

On my sony where it worked again it don’t work anymore

It’s hard to debug this

As a paying customer, i would like a clear solution to solve this bug that I observe only on trigger.io apps.
Other applications with “Cordova” works great with those Chrome updates.

As I am pushing to stay with trigger.io on my company, it’s hard work for me now…


#38

Hi,

What kind of element must migrate to use this module.I don’t understand…

We just have a classic single page application with html, javascript, images at load. Nothing else.


#39

Here’s an example src/config.json that shows how to set up the httpd module for your app:

{
    "config_version": "4",
    "name": "yourappname",
    "author": "author@you.com",
    "version": "0.1",
    "platform_version": "v2.7.8",
    "description": "An empty app created by default",
    "core": {
        "general": {
            "logging": {
                "level": "DEBUG"
            },
            "reload": true,
            "trusted_urls": [
                "https://localhost/*"
            ]
        },
        "ios": {
            "webview": "WKWebView"
        }

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

You can grab the certificate I used here: localhost.txt (2.3 KB)

Just rename it to localhost.p12 and drop it in your app’s src/ directory.


#40

ok, thanks.

But major point : i don’t have to modify my code at all ? Just add this module may fix the freeze ?