Also affects Android N Developer Preview 5 (tested on Nexus 9), with Chrome Stable listed as the WebView implementation.

This has been an issue since Android 5.0 (see  issue #425820 , reported by me nearly two years ago).

Attached, please find a sample project that can reproduce the error.

Deleted: Browser1.zip 25.9 KB

Browser1.zip 25.9 KB Download

why p1? is this affecting you?

dgn@ can you please verify if it is one of your changes that introduced this? thanks

aberent@ started looking into this. We need to read the preferences on startup, and because they already preloaded by some other things in Chrome, we don't have the strict mode violation issue. But for WebView they are not so we trigger the I/O path which causes the violation.

aberent@: What was your conclusion about how we should fix this?

The only two solutions are:
1. Somehow warm up the preferences in WebView early in startup (I don't know enough about WebView startup to know if this is possible).
2. Disable strict mode checking in this component when reading the preferences.

Note that the policy caching in this component was originally introduced to avoid a strict mode issue with fetching the app restrictions. If we were to disable strict mode checking in this module then maybe we should reconsider the need for a policy cache, since, in practice both reading app restrictions and reading preferences end up as reading files.

It's unlikely that there's anywhere in webview start we can warm up prefs early enough to avoid this all the time; the webview start process is too "compressed" and most of it happens in one big chunk. I think we'll just have to mask strict mode here, and look at the effect on startup performance :/

This is still happening and surprising apps (see internal b/31319364 for the most recent example) - we need to at least put on the band-aid of temporarily disabling strict mode while we do this to avoid breaking webview apps, but we should still look at whether this can be avoided as well.

Seeing this too in my app's debug builds (where I've enabled strict mode).

Current WebView version is 54.0.2840.25

Detailed stack trace:

09-15 12:10:12.219 E/StrictMode(24516): java.lang.Throwable: Explicit termination method 'close' not called
09-15 12:10:12.219 E/StrictMode(24516): 	at dalvik.system.CloseGuard.open(CloseGuard.java:180)
09-15 12:10:12.219 E/StrictMode(24516): 	at java.io.RandomAccessFile.<init>(RandomAccessFile.java:127)
09-15 12:10:12.219 E/StrictMode(24516): 	at com.android.webview.chromium.WebViewChromiumFactoryProvider.startChromiumLocked(WebViewChromiumFactoryProvider.java:16107)
09-15 12:10:12.219 E/StrictMode(24516): 	at com.android.webview.chromium.WebViewChromiumFactoryProvider.ensureChromiumStartedLocked(WebViewChromiumFactoryProvider.java:334)
09-15 12:10:12.219 E/StrictMode(24516): 	at com.android.webview.chromium.WebViewChromiumFactoryProvider.startYourEngines(WebViewChromiumFactoryProvider.java:417)
09-15 12:10:12.219 E/StrictMode(24516): 	at com.android.webview.chromium.WebViewChromium.init(WebViewChromium.java:162)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.webkit.WebView.<init>(WebView.java:618)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.webkit.WebView.<init>(WebView.java:554)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.webkit.WebView.<init>(WebView.java:537)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.webkit.WebView.<init>(WebView.java:524)
09-15 12:10:12.219 E/StrictMode(24516): 	at org.kman.AquaMail.view.MessageWebView.<init>(MessageWebView.java:34)
09-15 12:10:12.219 E/StrictMode(24516): 	at org.kman.AquaMail.view.MessageDisplayWebView.<init>(MessageDisplayWebView.java:34)
09-15 12:10:12.219 E/StrictMode(24516): 	at java.lang.reflect.Constructor.newInstance(Native Method)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.createView(LayoutInflater.java:631)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:776)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:716)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.rInflate(LayoutInflater.java:847)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.rInflateChildren(LayoutInflater.java:810)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.rInflate(LayoutInflater.java:855)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.rInflateChildren(LayoutInflater.java:810)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.inflate(LayoutInflater.java:527)
09-15 12:10:12.219 E/StrictMode(24516): 	at android.view.LayoutInflater.inflate(LayoutInflater.java:429)


Please do not fudge by disabling strict mode -- developers will want strict mode to remain enabled, as configured by their apps, so it does what it's supposed to do.

Why not just properly close the file?

Re #10: to me this looks as if it coming from a different place. The original problem is caused by AbstractAppRestrictionsProvider reading the preferences synchronously early in startup, and doesn't relate to closing the file. The new stack trace doesn't involve AbstractAppRestrictionsProvider, so must have a different cause.

The CL I am about to land, to fix the original problem, only disables strict mode checking very briefly (for the duration of one file read), and then restores its original state, so should not affect developers' ability to check app is behaving correctly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e4795a72b9d0c53c0e32911f1562a432e0ad4ee7

commit e4795a72b9d0c53c0e32911f1562a432e0ad4ee7
Author: aberent <aberent@chromium.org>
Date: Thu Sep 15 10:02:25 2016

Remove the Android policy cache

The Android policy cache was originally created to avoid Strict Mode
violations, but doesn't do so in Webview. Actually, although reading
the app restrictions on the UI thread is a strict mode violation it
is unlikely to cause UI visible delays, As such the solution is to
simply to allow file reads in this component.

BUG= 628627 

Review-Url: https://codereview.chromium.org/2322963002
Cr-Commit-Position: refs/heads/master@{#418818}

[modify] https://crrev.com/e4795a72b9d0c53c0e32911f1562a432e0ad4ee7/components/policy/android/java/src/org/chromium/policy/AbstractAppRestrictionsProvider.java
[modify] https://crrev.com/e4795a72b9d0c53c0e32911f1562a432e0ad4ee7/components/policy/android/junit/src/org/chromium/policy/AbstractAppRestrictionsProviderTest.java

Closing this bug, since the original issue is now fixed. kmansoft@, please create a new bug with details of how to reproduce (which app etc.).

@13:

1 - New bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=647291

2 - Re: "reading prefs on the UI thread is no big deal" -- it's not a small deal either.

First line in the first message:

StrictMode policy violation; ~duration=92 ms

92 ms is enough to cause substantial animation jitter. Android docs highly recommend trying to hit 60 fps, which is only 16 ms per frame.

It happens at most once, during startup. So yes, this may cause frameskip of a loading animation or similar, but will not affect applications while they're actually running.