Jack Wallen offers up his take on the recent issue surrounding Android's 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.
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.
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.
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.
Wi-Fi 6: A cheat sheet (TechRepublic)
Microsoft Surface Book 3: A cheat sheet (free PDF) (TechRepublic)
Hiring Kit: Application engineer (TechRepublic Premium)
Smartphones and mobile tech: More must-read coverage (TechRepublic on Flipboard)