Pitfalls in Android WebView Implementation

Niharika Arora
Jun 10, 2020 · 4 min read

In the current era of hybrid mobile architecture, WebView is extensively used hand in hand to deliver dynamic web content.

In this blog, I will be explaining the WebView pitfalls among different Android versions. This thought of writing on WebView came when one of my colleagues reported some design issues for Android Kitkat and lower versions. So I tried to understand why WebView is behaving differently in different OS versions. Then while reading about them, I found some other inconsistencies. So thought of sharing that through a blog.

Before going into much detail, lets first understand the term WebView.

What is Android WebView?

WebView is an Android provided View like TextView, EditText, Button etc. By using WebView, we can load the web(Html) pages as a part of our activity layout. It uses Webkit rendering engine to display web pages and includes methods to navigate forward and backwards through a history, zoom in and out, perform text searches and more.

To learn more about WebView, read this document: https://developer.android.com/reference/android/webkit/WebView

Now, let’s talk about the pitfalls:

1) No WebView update in Kitkat and lower versions

  • In older versions of Android (4.3 and below), WebView uses code based on Apple’s Webkit — the same tech behind the Safari browser.

A vulnerability was discovered in the WebView tool that affects anyone using Android 4.3 or earlier. This vulnerability allows WebView to be exploited. When the vulnerability was reported, Google decided it would leave the patching of the 4.3 and earlier releases up to someone else(OEMs).

Google fixed the Jelly Bean WebView issue with Android 4.4 KitKat patch.

  • The WebView shipped with Android 4.4 (KitKat) is based on the same code as Chrome(which uses Google’s Blink engine) for Android version 30. This WebView does not have full feature parity with Chrome for Android and is given the version number 30.0.0.0.

The updated WebView shipped with Android 4.4.3 has the version number 33.0.0.0.

Then came a design issue in Android KitKat that left the OS exposed to newly-disclosed bugs in the Chromium project. Android 5.0 was released with WebView updates to fix it.

In all versions of Android(KitKat and below), WebView has been bundled with Android firmware. From a security standpoint, that wasn’t good, because if a new flaw was found in WebView, the only way a fix would reach end-users was through the unwieldy process of delivering it from Google to OEMs and carriers and finally, if ever, to the end-user.

  • Then In Android 5.0, WebView was broken out as a separate app, presumably to allow timely updates through Google Play without requiring firmware updates to be issued. So, Now one can update WebView from Google Play.

2) WebView on Android 7 and above doesn’t render the page

This code perfectly works on <7.0 android version devices.

When you try to debug it, you will see it loads something(google URL appears in shouldOverrideUrlLoading method) but it shows nothing. No error logs will appear.

The reason is right here -

For Pre Android N,

and this is since Android N,

  • @return True if the host application wants to leave the current WebView and handle the URL itself, otherwise return false.

Solution -

Returning false from your code will solve your problem 😃.

3) Failed to load WebView provider: No WebView installed (Android Internal crash).

This problem seems to be happening in Lenovo, Oneplus, Samsung, Motorola, Xiaomi etc.(Non-rooted Android 5 and above devices).

It’s very hard to believe that such devices don’t have WebView installed.

Here’s what I discovered while digging the reason for this issue:

As we know that WebView has been shipping as a separate app from android 5.0, at the time view is being inflated, the WebView package is being updated by the OS and therefore it can’t find the WebView package for those few moments. People on the GitHub bug tracker said chrome and android were not going to fix this because it’s normal behaviour and up to the developer to handle it.

So here’s a hacky solution that prevents crashes (You can catch the specific exception too):

So next time when the user opens the app, probably they won’t see the crash again as WebView must be updated by then.

That’s all from my side on Webview inconsistencies for this article.

Originally published here.

Please feel free to share your views and feedback in the comments section below. Also, please do let me know what should I write next. Here are some options :

a) More on WebView -Use of Chrome Custom tabs and Web deep links vulnerability.

b) Implementing a custom bar code scanner using Zxing.

c) Understanding Android BLE and GATT.

d) Android Keystore implementation for Lollipop and above.

e) Revamping listing screens at 1mg.

Please feel free to reach out to me on LinkedIn and Twitter.

If you liked this blog, hit the 👏 and do check other blogs too. Stay tuned for the next one!

Tata 1mg Engineering

Bringing Care to Health