Managing WebViews

The Android O Developer Preview provides several APIs to help you manage the WebView objects that display web content in your app.

This page describes how to use these APIs to work with WebView objects more effectively, improving your app's stability and security.

Version API

Starting in Android 7.0 (API level 24), users can choose among several different packages for displaying web content in a WebView object. Android O includes an API for fetching information related to the package that is displaying web content in your app. This API is especially useful when analyzing errors that occur only when your app tries to display web content using a particular package's implementation of WebView.

To use this API, add the logic shown in the following code snippet:

PackageInfo webViewPackageInfo = WebView.getCurrentWebViewPackage();
Log.d("MY_APP_TAG", "WebView version: " + webViewPackageInfo.versionName);

Note: The WebView.getCurrentWebViewPackage() method can return null if the device hasn't been set up correctly. It also returns null if you're running your app on a device that doesn't support WebView, such as an Android Wear device.

Google Safe Browsing API

To provide your users with a safer browsing experience, you can configure your app's WebView objects to verify URLs using Google Safe Browsing. When this security measure is enabled, your app shows users a warning when they attempt to navigate to a potentially unsafe website.

To opt-in your WebView objects to check URLs against Google Safe Browsing's list of unsafe websites, add the following <meta-data> element to your app’s manifest file:

<manifest>
    <meta-data android:name="android.webkit.WebView.EnableSafeBrowsing"
               android:value="true" />
    ...
    <application> ... </application>
</manifest>

Termination Handle API

This API handles cases where the renderer process for a WebView object goes away, either because the system killed the renderer to reclaim much-needed memory or because the renderer process itself crashed. By using this API, you allow your app to continue executing, even though the renderer process has gone away.

Caution: If your app continues executing after the renderer process goes away, the associated instance of WebView cannot be reused, no matter whether the renderer process is killed or crashes. Your app must remove the instance from the view hierarchy and destroy the instance to continue executing. Your app must then create an entirely new instance of WebView to continue rendering web pages.

Be aware that, if a renderer crashes while loading a particular web page, attempting to load that same page again could cause a new WebView object to exhibit the same rendering crash behavior.

The following code snippet illustrates how to use this API:

public class MyRendererTrackingWebViewClient extends WebViewClient {
    private WebView mWebView;

    @Override
    public boolean onRenderProcessGone(WebView view,
            RenderProcessGoneDetail detail) {
        if (!detail.didCrash()) {
            // Renderer was killed because the system ran out of memory.
            // The app can recover gracefully by creating a new WebView instance
            // in the foreground.
            Log.e("MY_APP_TAG", "System killed the WebView rendering process " +
                    "to reclaim memory. Recreating...");

            if (mWebView != null) {
                ViewGroup webViewContainer =
                        (ViewGroup) findViewById(R.id.my_web_view_container);
                webViewContainer.removeView(mWebView);
                mWebView.destroy();
                mWebView = null;
            }

            // By this point, the instance variable "mWebView" is guaranteed
            // to be null, so it's safe to reinitialize it.

            return true; // The app continues executing.
        }

        // Renderer crashed because of an internal error, such as a memory
        // access violation.
        Log.e("MY_APP_TAG", "The WebView rendering process crashed!");

        // In this example, the app itself crashes after detecting that the
        // renderer crashed. If you choose to handle the crash more gracefully
        // and allow your app to continue executing, you should 1) destroy the
        // current WebView instance, 2) specify logic for how the app can
        // continue executing, and 3) return "true" instead.
        return false;
    }
}

Renderer Importance API

Now that WebView objects operate in multiprocess mode, you have some flexibility in how your app handles out-of-memory situations. You can use the Renderer Importance API, introduced in Android O, to set a priority policy for the renderer assigned to a particular WebView object. In particular, you might want the main part of your app to continue executing when a renderer that displays your app's WebView objects is killed. You might do this, for example, if you expect to not show the WebView object for a long period of time so that the system can reclaim memory that the renderer was using.

The following code snippet shows how to assign a priority to the renderer process associated with your app's WebView objects:

WebView myWebView;
myWebView.setRendererPriorityPolicy(RENDERER_PRIORITY_BOUND, true);

In this particular snippet, the renderer's priority is the same as (or "is bound to") the default priority for the app. The true argument decreases the renderer's priority to RENDERER_PRIORITY_WAIVED when the associated WebView object is no longer visible. In other words, a true argument indicates that your app doesn't care whether the system keeps the renderer process alive. In fact, this lower priority level makes it likely that the renderer process is killed in out-of-memory situations.

Warning: To maintain app stability, you shouldn't change the renderer priority policy for a WebView object unless you also use the Termination Handle API to specify how the WebView reacts when its associated renderer goes away.

To learn more about how the system handles low-memory situations, see Processes and Application Life Cycle.