Introduction

When an Android device rotates, the activity is usually destroyed and recreated. That default behavior is fine for many screens, but it can be painful for a WebView because page state, scroll position, and in-progress loading can all be affected.

The right fix is usually not to suppress rotation blindly. Instead, decide whether you want to restore WebView state across recreation or deliberately handle configuration changes yourself. In most cases, saving and restoring the WebView state is the cleaner option.

Save and Restore WebView State

WebView already supports built-in state persistence through saveState and restoreState:

1class BrowserActivity : AppCompatActivity() {
2
3    private lateinit var webView: WebView
4
5    override fun onCreate(savedInstanceState: Bundle?) {
6        super.onCreate(savedInstanceState)
7        setContentView(R.layout.activity_browser)
8
9        webView = findViewById(R.id.webView)
10        webView.settings.javaScriptEnabled = true
11        webView.webViewClient = WebViewClient()
12
13        if (savedInstanceState != null) {
14            webView.restoreState(savedInstanceState)
15        } else {
16            webView.loadUrl("https://example.com")
17        }
18    }
19
20    override fun onSaveInstanceState(outState: Bundle) {
21        super.onSaveInstanceState(outState)
22        webView.saveState(outState)
23    }
24}

This is usually the best first solution because it works with the normal Android lifecycle instead of fighting it.

Saving Only the URL Is Less Complete

A common shortcut is saving just the URL:

outState.putString("url", webView.url)

That is better than nothing, but it does not preserve browsing history, form content, or as much internal WebView state as saveState. If the goal is a smooth user experience, the built-in state bundle is usually more complete.

Use configChanges Only Deliberately

Some developers prevent activity recreation with manifest flags:

<activity
    android:name=".BrowserActivity"
    android:configChanges="orientation|screenSize" />

Then handle the change manually:

override fun onConfigurationChanged(newConfig: Configuration) {
    super.onConfigurationChanged(newConfig)
}

This can reduce reloads, but it also shifts more responsibility to your activity. It is usually worth doing only when you genuinely want to own configuration handling yourself.

Keep the WebView Setup Correct

Orientation bugs are often blamed on rotation when the real issue is incomplete WebView configuration. At minimum, make sure the WebView is set up consistently before any restore or reload happens:

webView.settings.javaScriptEnabled = true
webView.webViewClient = WebViewClient()

Without a WebViewClient, links may open in an external browser. Without required settings, the restored page may behave differently from the original page.

Heavy WebViews and Lifecycle Tradeoffs

Because WebView is relatively expensive, some apps try to retain it across recreation using more elaborate patterns. That can work, but it also increases lifecycle complexity and the risk of leaking an activity context.

For many apps, saveState and restoreState are enough. Start there before building a more complicated retention strategy.

Test with Real Navigation Behavior

State restoration is easier to trust when you verify actual user behavior after rotation: page history, form input, scroll position, and in-page navigation. A simple URL reload can hide bugs that only appear when users interact with the page before rotating.

Common Pitfalls

• Saving only the URL and assuming that restores the full browsing state.
• Using configChanges to suppress recreation without understanding the tradeoffs.
• Recreating a heavy WebView repeatedly when state restoration would have been enough.
• Forgetting basic setup such as WebViewClient and required settings.
• Treating all lost state as an orientation problem when some of it actually lives in page-side JavaScript or server-side session logic.

Summary

• Android normally recreates activities on orientation changes, which affects WebView.
• The clean default fix is saveState plus restoreState.
• Saving only the URL is usually less complete than saving full WebView state.
• Handle configChanges manually only when you truly want to own rotation behavior.
• Start with correct WebView configuration before blaming orientation handling alone.