Follow-up remediation for physical Android WebView startup failures after the application updated from working wrapper 1.0.2185 to 1.0.2223, 1.0.2225, and 1.0.2227.
1.0.2185 after the server bootstrap was introduced.1.0.2225 differed by forcing WebSettings.LOAD_NO_CACHE and retaining the native startup overlay while waiting for the real WASM shell.1.0.2227 diagnostics proved the WebView spent about 21 seconds in the read phase. The 20-second frontend timeout fired, but the application initialized one second later, loaded all session APIs, and successfully processed a regeneration request. The WASM operation was slow rather than failed.Merge a0fc3d53a240:
WebSettings.LOAD_DEFAULT; unique root URLs and production Cache-Control: no-cache continue to guarantee revalidation;Starting EventHorizon bootstrap while WASM initializes;1.0.2227.Merge 439c2e7dae8d:
1.0.2229.:app:assembleDebug and :app:lintDebug succeeded.read timeout at 20 seconds followed by the first successful API request about one second later and a later successful regeneration request.build_frontend #2230 and build_and_deploy #2229 succeeded.gitea.app.lan/eventhorizon/eventhorizon:sha-439c2e7dae8d; /healthz returned healthy.1.0.2229 SHA-256: 247957cb8dd21f07b0ed7aca673d71915ccb6ac8bac2938c0581010367dbc34b.Force-stop and reopen 1.0.2227 to receive the corrected 60-second server deadline. Install 1.0.2229 when prompted to also receive the 90-second native recovery deadline.