## Description Home Assistant's frontend never completes bootstrap on an Android 11 Echo Show 5 Gen 1 running LineageOS 18.1 with its stock 32-bit Android System WebView. The same failure reproduces in a plain browser (Jelly), the Home Assistant Companion App, and View Assist Companion, so this is not limited to Companion's `external_auth` flow. A normal browser page for the direct internal Home Assistant URL remains indefinitely on the Home Assistant loading splash; it never renders the login form or dashboard. ## Environment - Device: Amazon Echo Show 5 Gen 1 (`checkers`) - OS: LineageOS 18.1 / Android 11 (SDK 30), 32-bit ARM (`armeabi-v7a`) - Stock WebView: `com.android.webview 139.0.7258.143` - Home Assistant Core tested: `2026.8.1` and `2026.8.3` - Home Assistant Companion: `2026.6.5-minimal` - Network: direct private-LAN HTTP URL; no Cloudflare Tunnel, public reverse proxy, or external DNS is involved in this reproduction ## Steps to reproduce 1. On the device, stop View Assist Companion and Home Assistant Companion to eliminate RAM contention. 2. Launch the stock Jelly browser with the direct internal Home Assistant root URL. 3. Wait at least 30 seconds. ## Expected behavior The Home Assistant login form or dashboard renders. ## Actual behavior The Home Assistant logo/loading splash remains indefinitely. No login form or dashboard renders. The Companion App also cannot render the OAuth login page. Its `?external_auth=1` route logged: ```text Uncaught TypeError: Cannot read properties of null (reading '0') ``` However, the same failure in Jelly without `external_auth` shows this is broader than the Companion handoff. ## Diagnostics - Direct HTTP connectivity from the Show to Home Assistant returns `HTTP 200`. - Home Assistant discovery resolves the internal server correctly. - Rebooting the device, stopping VACA/Companion, and having approximately 339 MB available RAM did not change the result. - Reset Frontend Cache did not resolve the issue. - Reproduces against both tested Core versions. - Using Chrome DevTools Protocol against Jelly's WebView after the page had been allowed to load showed: ```text document.readyState: "interactive" document.title: "Home Assistant" document.querySelector("home-assistant") != null customElements.get("home-assistant") == false ``` So the document never reaches a completed frontend bootstrap and the `<home-assistant>` custom element is never registered. This seems related to current frontend compatibility with this Android 11 / WebView 139 environment. I found Android Companion issue #7324, but its failure is Cloudflare-Tunnel/external-URL-specific and recovers after retry/cache reset; this direct-local browser reproduction appears distinct. ## Not yet tested Home Assistant safe mode / a configuration without custom frontend resources has not yet been tested. I can provide further logs or run requested targeted tests.