WebView-Grundlagen

Für die meisten Anzeigeszenarien in Android-Apps gilt die Faustregel: Nutze native UI-Komponenten oder starte einen Browser-Intent. Manchmal lässt sich das jedoch nicht umsetzen – etwa wenn eine bestehende Webanwendung tief in den App-Kontext eingebettet werden muss oder wenn eine hybride Architektur das direkte Rendern von HTML innerhalb der App erfordert. Für genau diesen schmalen Anwendungsfall stellt Android den WebView bereit.

Was ist das?

WebView ist eine Android-Systemkomponente, die eine vollständige Browser-Engine direkt in dein Layout einbettet. Seit Android 5.0 basiert diese Engine auf Chromium und wird als eigenständiges System-WebView-Paket über den Play Store aktualisiert. Damit unterscheidet sich WebView grundlegend von einem Browser-Intent: Statt einen externen Browser zu öffnen, rendert er HTML, CSS und JavaScript innerhalb des App-Prozesses – unter deiner vollständigen Kontrolle.

Diese Kontrolle hat ihren Preis. Ein WebView bringt erhebliche Komplexität in Sicherheit, Performance und Lebenszyklus-Management mit. Die offizielle Android-Empfehlung ist deshalb eindeutig: Setze WebView nur ein, wenn keine native Implementierung und kein Browser-Intent ausreicht. Typische legitime Fälle sind eingebettete Dokumentation, OAuth-Flows mit benutzerdefinierten Weiterleitungs-URIs oder hybride Apps, bei denen ein Web-Team und ein Android-Team denselben UI-Teil pflegen.

Wie funktioniert es?

Die grundlegende Einrichtung besteht aus drei Schritten: WebView ins Layout einbinden, per WebSettings konfigurieren und einen WebViewClient setzen.

val webView: WebView = findViewById(R.id.webView)

webView.settings.apply {
    javaScriptEnabled = true               // nur aktivieren, wenn wirklich nötig
    domStorageEnabled = true
    allowFileAccess = false                // Dateizugriff explizit deaktivieren
    mixedContentMode = WebSettings.MIXED_CONTENT_NEVER_ALLOW
}

webView.webViewClient = WebViewClient()
webView.loadUrl("https://example.com")

Ohne WebViewClient fängt Android Navigationsevents ab und öffnet URLs im Standard-Browser. Das ist fast nie das gewünschte Verhalten innerhalb einer eingebetteten Ansicht. Durch das Setzen eines WebViewClient bleiben alle Seitenaufrufe im WebView. Willst du zusätzlich auf Navigation reagieren – zum Beispiel bestimmte URLs blockieren oder Ladefehler anzeigen –, überschreibst du shouldOverrideUrlLoading und onReceivedError.

Lebenszyklus korrekt verdrahten

WebView verwaltet intern einen eigenen Rendering-Thread. Du musst dessen Pause- und Resume-Zustand mit dem Activity- oder Fragment-Lebenszyklus synchronisieren:

override fun onResume() {
    super.onResume()
    webView.onResume()
}

override fun onPause() {
    webView.onPause()
    super.onPause()
}

override fun onDestroy() {
    webView.destroy()
    super.onDestroy()
}

Vergisst du destroy(), hält der WebView Speicher und Threads unnötig fest. Vergisst du onPause(), läuft JavaScript im Hintergrund weiter und verbraucht Akku.

Navigation im WebView steuern

Für den Back-Stack prüfst du im onBackPressedDispatcher, ob der WebView noch zurücknavigieren kann:

onBackPressedDispatcher.addCallback(this) {
    if (webView.canGoBack()) {
        webView.goBack()
    } else {
        isEnabled = false
        onBackPressedDispatcher.onBackPressed()
    }
}

In der Praxis

Die gefährlichste und gleichzeitig häufig missbräuchlich eingesetzte API ist addJavascriptInterface. Sie erlaubt es, Kotlin-Objekte unter einem frei wählbaren Namen in den JavaScript-Kontext der geladenen Seite zu injizieren. Jede mit @JavascriptInterface annotierte Methode ist dann aus dem Web-Code aufrufbar:

class NativeBridge(private val onMessage: (String) -> Unit) {
    @JavascriptInterface
    fun postMessage(payload: String) {
        onMessage(payload)
    }
}

webView.addJavascriptInterface(NativeBridge { msg ->
    viewModel.handleWebMessage(msg)
}, "Android")

Der JavaScript-Code ruft dann Android.postMessage("hello") auf. Das klingt praktisch – und ist es auch. Aber: Jede Seite, die der WebView lädt, hat Zugriff auf dieses Interface. Lädst du eine kompromittierte URL oder erlaubst Mixed Content, öffnest du damit eine direkte Verbindung zum nativen App-Code. Die Regel lautet deshalb: addJavascriptInterface nur in Kombination mit ausschließlich vertrauenswürdigen, HTTPS-gesicherten URLs verwenden.

Typische Stolperfalle: Mixed Content

Wenn deine HTTPS-Seite HTTP-Unterressourcen lädt (Bilder, Skripte, Fonts), blockiert MIXED_CONTENT_NEVER_ALLOW diese stillen. Das Ergebnis sind leere Bereiche oder kaputte Layouts ohne offensichtliche Fehlermeldung in Logcat. Verbinde dein Gerät mit dem Entwickler-PC, öffne chrome://inspect in Chrome und wähle deine App-Session aus. In der Netzwerk-Konsole siehst du sofort, welche Requests blockiert werden und warum.

Entscheidungsregel

Bevor du WebView integrierst, stelle dir eine Frage: Reicht Intent.ACTION_VIEW mit einer URL aus? Falls ja, spare dir den gesamten Konfigurations- und Sicherheitsaufwand und öffne einfach den Browser. WebView lohnt sich nur dann, wenn du aktiv mit dem Inhalt interagieren musst – durch URL-Interception, JavaScript-Interfaces oder eine eingebettete Navigation ohne sichtbare Browser-Chrome.

Fazit

WebView ist kein generischer Web-Container, sondern ein spezialisiertes Werkzeug für einen klar abgegrenzten Anwendungsfall. Konfiguriere WebSettings immer defensiv: JavaScript nur aktivieren, wenn nötig; Dateizugriff deaktivieren; Mixed Content verbieten. Setze stets einen WebViewClient und verdrahte den Lebenszyklus vollständig. Öffne nach dem Lesen dieses Artikels eine App, die WebView nutzt, verbinde sie mit Chrome DevTools und prüfe aktiv: Welche Requests werden blockiert? Ist allowFileAccess deaktiviert? Gibt es unnötige JavaScript-Interfaces? Diese direkte Inspektion im laufenden Betrieb verankert das Gelernte besser als jedes weitere Lesen.