Android Webview crashes on Samsung & Android 11

Question

This is the stacktrace we are seeing on Firebase:

Fatal Exception: java.lang.RuntimeException
Using WebView from more than one process at once with the same data directory is not supported. https://crbug.com/558377 : Current process [Our package] (pid 28562), lock owner [Our package] (pid 13324)
org.chromium.android_webview.AwDataDirLock.b (AwDataDirLock.java:27)
as0.i (as0.java:30)
as0.b (as0.java:17)
as0.k (as0.java:2)
com.android.webview.chromium.WebViewChromiumFactoryProvider.g (WebViewChromiumFactoryProvider.java:2)
com.android.webview.chromium.WebViewChromium.init (WebViewChromium.java:14)
android.webkit.WebView.<init> (WebView.java:435)
android.webkit.WebView.<init> (WebView.java:355)
android.webkit.WebView.<init> (WebView.java:337)
android.webkit.WebView.<init> (WebView.java:324)
android.webkit.WebView.<init> (WebView.java:314)
[Our code initializing the webview]
android.os.Handler.handleCallback (Handler.java:938)
android.os.Handler.dispatchMessage (Handler.java:99)
android.os.Looper.loop (Looper.java:246)
android.app.ActivityThread.main (ActivityThread.java:8506)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:602)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1130)

We have not been able to reproduce this, but we get hundreds/thousands of these crashes on Firebase. What is weird is that 99% of the crashes are happening on Samsung devices running Android 11. Our app is also a single process app, so it should not be running multiple processes. I've posted in the chromium issue tracker, but it seems the bug is more with the Samsung OS than with the webview itself, so I thought I'd post here as well.

It seems that some users have a process of our app running for hours, holding onto this Webview lock. However when they try to open our app, it is starting a new process instead of the existing process, and causing a crash.

I'm trying to gain more information: Does anyone have any insight into why this would be happening specifically on Samsung Android 11? Is there something our app, or our users, can do to mitigate this issue? Has anyone else faced this problem and found a workaround?

Fiend

Have you tried switching a Samsung to and from DeX mode? That is one scenario where I could see Samsung doing something odd with respect to processes. Also, are you seeing other crashes for these same users? I'm wondering if your old process was terminated in a way that did not clean up the lock file(?) that they are using. – Bureau

@Bureau We do track user IDs on firebase, and at least for the handful of users I've looked up now & in the past, this is the only crash that's been reported for them on Firebase in the last 90 days. I don't know if it's possible that something like a memory leak could be the cause, but still strange it would be so Samsung specific. I'd never heard of DeX mode though, we'll look into that and see if we can reproduce anything with that, thanks! – Fiend

I may be wrong but are you using this Localization library (or something like that) this bug in it created more than a dozen crashes on our app and one of them had the same stack trace that you've provided – Baud

I'm not using that localization library, and in any case it looks like they've fixed that particular problem. But thanks for the comment, Amin... I might try some of the changes they made to fix that library. (It's still not clear why these crashes are concentrated on Samsung devices running Android 11, though.) – Macrobiotics

@RapunzelVanWinkle were you able to find the source of the issue or a workaround? – Amabel

No, it's still a mystery. However, it seems to be happening a lot less often lately (according to my Crashlytics data). I would still like to know an answer to this question. Anyone? – Macrobiotics

@RapunzelVanWinkle It's decreased significantly for us as well. I'm guessing the latest Samsung OS update fixed the bug that was causing this. Haven't confirmed it though. But we did see it start to decrease soon after the June update came out. – Fiend

Answer 1

Try adding this to the onCreate of your application class before initializing any WebView related stuff such as AdMob,

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
            String processName = getProcessName();
            if (!getPackageName().equals(processName)) {
                WebView.setDataDirectorySuffix(processName);
            }
        }

//AdMob creates a new process.

Postimpressionism

Answer 2

Do not remember exact stacktrace, but I had similar problem with WebView crashing app when returning to app on some devices. After no solution worked I tried to remove WebView definition from XML and moved WebView inicialization into Activity (Kotlin) and destroying manually in onStop() method. Did not find information, about what was the problem, but solved my problem.

   override fun onResume() {
        webView = WebView(activity)
        //... init webview
        webViewLayout.addView(webView)
   }
   override fun onStop() {
        webViewLayout.removeView(webView)
        webView?.destroy()
        webView = null
    }

EDIT: Thank you kingston for pointing my mistake. Misread creation of webview in code, which does not make sence to do in onCreate() with destroying onStop.

You can move creating to onCreate() and destroying to onDestroy(), if you don't need to refresh layout when returning to screen to save resources. In our case it is required to content be always updated when returning to screen.

Palmar

shouldn't you either create the WebView in the onStart or destroy it in the onDestroy? Like you did it you will end with a destroyed WebView in case you stop the activity and then you restart it before it gets destroyed – Ki

Thank you for pointing that (EDIT). In our case it was needed to screen be always actual so that's why it was in onResume(). I took creating from one file and destroying from another without noticing. – Palmar

mmm if you have the creation in onResume then you need to delete in onPause or you will end with multiple instances of WebView in case you show and then dismiss a dialog: the onPause will be called and the onResume again without calling the onStop – Ki

Screen I am reffering to is not using any in app dialogs or other partial overlays to trigger onPause() without leaving Activity causing onStop(). Just to be sure I tried some actions with screen (drawer...) and not problem detected, but yes if you cover screen with dialog, onPause would be called. In regular screens we use onCreate and onDestroy approach. – Palmar

Can you provide any documentation that supports your suggestion to add/remove the WebView? It's not clear to me why this would be necessary. – Macrobiotics

Documentation not, but real use case. This fix was made in desperation as no solution was found. Crash was/is happening on some devices when Activity is being destroyed WebView would crash with Renderer process (sometimes leading to app crashed dialog after app was exited). I have found on some forum (can't provide link or stacktrace, it is some time) that WebView implementation is buggy in some versions of Android and certain devices. Successfully tested on Redmi Android 9. – Palmar

Answer 3

Do not remember exact stacktrace, but I had similar problem with WebView crashing app when returning to app on some devices.

override fun onResume() {
        webView = WebView(activity)
        //... init webview
        webViewLayout.addView(webView)
   }
   override fun onStop() {
        webViewLayout.removeView(webView)
        webView?.destroy()
        webView = null
    }

You can move creating to onCreate() and destroying to onDestroy(), if you don't need to refresh layout when returning to screen to save resources. In our case it is required to content be always updated when returning to screen.

Demoss

This looks like a comment or rehash of David Vareka's answer. – Memoried