Why it’s time the Android developers rethink WebView

In the past couple of days, Android users found themselves in a rather frustrating situation with random applications crashing when links were opened. It turns out the issue was Android System WebView.

That particular application that has been rather problematic over the years. Even back in the early days, WebView was problematic because, with a JavaScript bridge enabled, a webpage viewed in WebView could execute code as the WebView application itself. That was a serious security issue. 

It wasn’t until Android 5 that WebView was moved from the system to exist as an app on its own. At that point, WebView incorporated Google’s Safe Browsing protections. Then, in Android 8, the WebView renderer was changed to run in an isolated process, which meant it had limited access to resources. 

The problem is that there are so many moving parts for WebView. There’s the app itself, there are the Android subsystems, there are the apps that depend on WebView, there are the developers who might make use of JavaScript, which then depends on a third-party server that may or may not use SSL properly.

SEE: Samsung Galaxy Unpacked 2020: Galaxy Z Fold2, Samsung Galaxy S20, and more (free PDF) (TechRepublic)

What is WebView?

Simply put, Android WebView allows apps to display web content, without having to open a web browser. Up to Android 6, WebView was a system service. Then, with Android 7.0, Google incorporated that functionality into the default Chrome Browser. Of course, in typical Google fashion, the developers then returned WebView duties back to System WebView for Android 10 and haven’t changed that behavior since.

For some Android releases, you could safely disable WebView and allow Chrome to handle those duties, but with all modern releases, you cannot. Google wants you to use WebView for all out-of-browser web content viewing.

That’s a problem because anytime something goes wrong with WebView, any time an app needs to open web content (which is often), it’ll either crash or the content simply won’t render. I’d like to say it’s not such a big deal; but the truth of the matter is, it is a big deal. Android apps depend on the ability to render web content. Because WebView also depends on developers release apps that deal with this in a secure manner, users are at their mercy.

Although this seamless integration of native app code and HTML/JavaScript makes it easier on developers, it exposes the users by creating a larger attack surface for the platform. With the larger attack surface WebView brings to Android, it’s not just about whether an app will crash or content won’t render, it’s also about security. With WebView taking duties that could easily be rolled back into the more secure Chrome, it’s a crapshoot on the part of Google.

It needs to be rethought.

But how? As it stands, Android puts the onus on app developers and users. Try as they might, Google can’t seem to get WebView placed in a position that offers either community a reliable solution to start with. 

This most recent episode with WebView only proves that.

Although Google did roll out a fix for the issue, how many people had to deal with the problem before the patch came in? Because the problem presented itself in multiple apps, it could have been a serious issue with on-the-go business users or those who rely on their phones as a primary communication tool.

Google cannot turn away from the WebView problem. Given its history, we know something else will happen with the system. Since so many apps depend on WebView, and so much content is displayed by the system, the importance of this issue cannot be overlooked.

To that end, Google needs to seriously rethink WebView. It may be too late for Android 12, but as soon as the developers and designers start hammering out ideas for the 13th release of the platform, they’re going to need to put serious time into rethinking and retooling WebView. As it stands, it’s only a matter of time before a critical flaw is exploited in WebView and devices fall victim to data theft and more.

I don’t have the answer to this, but one thing I will say is the answer might go back to Android 7 and the ability to disable WebView, in favor of Chrome. If that’s an option, maybe there’s a hybrid version to be considered, where a WebView-like system can pass off the duties to a stripped-down version of Chrome to display the content. 

Google has some seriously brilliant developers working on Android. If given the time and resources, I’m certain they can come up with a workable solution for the issues brought about by WebView.

Until then, users will be at the mercy of this unreliable system. To every user out there, I’d say whenever you can open links or other content in Chrome, do so. Always relying on WebView might lead to problems.

Fingers crossed Google figures this one out sooner, rather than later.

Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.

Google Weekly Newsletter

Learn how to get the most out of Google Docs, Google Cloud Platform, Google Apps, Chrome OS, and all the other Google products used in business environments.
Delivered Fridays

Sign up today

Also see