Repository navigation
App fails to follow system theme and falls back to light theme #300
Description
Environment
App version: 0.14.2b4
OS: Android 15, Realme UI
In-app theme: System
System theme: Dark
Description
My device's system theme is set to Dark, and all other apps respect this mode correctly. In the ActivityWatch settings, I have selected "System" as the color theme.
However, when opening the app, the status bar, navigation bar, and the sidebar menu (if I manage to open it quickly) initially display in the dark theme for a couple of seconds, but then the app unexpectedly falls back to the light theme.
Additionally, I have verified that on desktop, the app correctly follows the browser theme (when opened in a browser) or the system theme (when using the aw-tauri GUI). I am opening this issue here specifically because the desktop/web versions handle theming correctly.
Steps to Reproduce
- Set the device's system theme to Dark.
- Ensure the in-app color theme is set to "System".
- Open the mobile app.
- Observe the status bar, navigation bar, and sidebar menu upon opening the app.
Expected Behavior
The app should consistently remain in the dark theme, matching the system settings without flickering or reverting.
Actual Behavior
The UI elements (status bar, navigation bar, sidebar) render in the dark theme for a few seconds upon launch, but then the app falls back to the light theme.
Activity
ErikBjare commentedon Sep 22, 2026
@akirad3d4 Thanks for the report!
@TimeToBuildBob please fix, I noticed the same thing that the "system" setting doesn't work (becomes light mode for me, despite in system dark mode at 01:46 AM). I suppose #276 fixed part of it but the "system" option remains buggy.
TimeToBuildBob commentedon Sep 22, 2026
Confirmed — same bug. Native chrome follows system night, then the WebView reports
prefers-color-scheme: lightbecause the activity theme isTheme.AppCompat.Light, so theme=auto flips the app to light after the JS hook (~1s flicker). Fixing it now so auto follows the device night mode.TimeToBuildBob commentedon Sep 22, 2026
PR #301 fixes this.
Root cause: forces the Activity into light mode, so Android WebView always reports
prefers-color-scheme: lightregardless of the OS setting. The "System" option in aw-webui therefore always resolved to light.Fix: Add an
AWApplicationclass that callsAppCompatDelegate.setDefaultNightMode(MODE_NIGHT_FOLLOW_SYSTEM)inonCreate()before any Activity starts (no recreation triggered), and change the base theme toTheme.AppCompat.DayNightso the Activity properly reflects the OS dark/light state.PR: #301
fix(android): follow system theme so WebView sees correct prefers-col…
TimeToBuildBob commentedon Sep 23, 2026
Fixed by #301, merged 2026-09-23.
Root cause: The app theme was
Theme.AppCompat.Light, which forced every Activity into light mode. Android WebView reads the Activity's configuration forprefers-color-scheme, so it always reportedlightregardless of the OS setting. The "System" option in aw-webui therefore always resolved to light (with a brief flicker from the initial native dark chrome).Fix:
AWApplicationclass that callsAppCompatDelegate.setDefaultNightMode(MODE_NIGHT_FOLLOW_SYSTEM)inonCreate()before any Activity startsTheme.AppCompat.DayNightso Activities properly inherit the OS dark/light stateThis will ship in the next release.
akirad3d4 commentedon Sep 26, 2026
Now the app actually follows the system theme. However, a new problem has arisen. On screens such as "API Authentication" and "Sync Settings", when the system's dark theme is enabled along with any app theme, the text color apparently adapts and turns white, causing it to blend into the white background. However, if you enable the white system theme and any app theme, the text on these screens displays correctly.
Screenshot
Interestingly, this issue does not occur on the "Home" screen accessed from the side menu. There, the text displays normally even with a dark system theme.
It would be good if these screens followed the dark theme. Otherwise, it’s a bit strange that, out of all the parts of the app, these are always white themed.
TimeToBuildBob commentedon Sep 26, 2026
Root cause of the new problem:
applySafeWindowInsets()pins the Activity background tochrome_light(#FFFFFF) on Auth/Sync/Onboarding screens — that's intentional, they stay light-chrome. But those Activities were inheritingAppTheme(DayNight), so in night mode the theme resolves?android:attr/textColorSecondary,?android:attr/textAppearanceListItem, and similar attributes to white → white text on white background.Fix in PR #309: adds an
AppTheme.LightOnlystyle (Theme.AppCompat.Light.NoActionBar) and applies it toAuthSettingsActivity,SyncSettingsActivity, andOnboardingActivity.MainActivityis unaffected — it dynamically switches via the WebView theme callback.fix(android): use light-only theme for Auth/Sync/Onboarding screens (#…
akirad3d4 commentedon Oct 11, 2026
I can confirm that the app now correctly follows the system theme when the "System" setting is selected.
However, I encountered a problem with the "System" setting, where the app flashes white for a second when opening the app, or when accessing "Activity," "Raw Data," or "Dashboard Settings" in the sidebar. Afterward, it switches to the dark theme. Given the dark background visible before the flash, I assume it correctly detected the dark system theme from the start.
Video
demo.mp4
TimeToBuildBob commentedon Oct 11, 2026
Thanks for confirming that System now follows the device theme. The white flash on startup and sidebar navigation is a remaining bug, so this issue should stay open.
I checked your video and the current Android loading path. Each native drawer destination creates a new WebView, whose background is not set until the page reports its theme after loading. The shared web UI also applies its dark stylesheet after loading settings. Those are plausible first-paint gaps; I haven't reproduced the exact APK or verified which one produces the flash, so I'm not calling this fixed or submitting an unverified workaround.
I've captured the follow-up as
aw-android-dark-theme-first-paint, covering startup and all three drawer destinations, with explicit Light/Dark overrides as controls. The next step is a frame-by-frame reproduction in the tested build before changing the loading path.Could you include the app version you're testing? That will let us distinguish the currently released build from subsequent WebView changes.
akirad3d4 commentedon Oct 11, 2026
I am using version 0.14.3.
TimeToBuildBob commentedon Oct 11, 2026
Filed #363 with a fix: initialize the WebView background color from the system night mode at creation time, before the page loads and the JS theme hook fires.
Root cause:
WebUIFragment.onCreateView()created the WebView with its default white background; the correct color was only applied afteronPageFinishedcalled back via the JS bridge, leaving a white surface visible for the entire page-load window.The fix sets the background immediately. The existing JS hook still corrects it post-load for users with explicit Light/Dark overrides.
Pending device verification to confirm it resolves the startup and drawer-navigation flash you reported.
fix(ui): initialize WebView background from system night mode to prev…
TimeToBuildBob commentedon Oct 19, 2026
I tested a local Android build containing #363 today. This is not verified fixed yet, so I am leaving this issue open.
On an Android 14 emulator, source
ea06baa(debug APK 0.14.4b1/49, with CI native libraries matching its Rust pin), a System-dark cold-start recording still shows about one second of full-white content before the dark dashboard appears. The same run logs a connection-refused error while the local server starts, so I have not isolated whether that interval is the Chromium error page, the dashboard loading paint, or both.Settled Light, Dark and System behavior passes on both device modes; the existing theme and WebView/reload suites pass (34 tests). The three native drawer transitions and stylesheet-failure behavior are not yet certified. These emulator results are not confirmation on your Realme/Android 15 device or a published release.
Next step is to distinguish server-startup/error-page paint from normal document paint and add a behavioral regression before another repair. The native background initialization alone is not enough evidence to close this.
TimeToBuildBob commentedon Oct 19, 2026
Isolated one additional startup path and opened #371 as a partial repair. A refused main-document request commits Chromium's own error page, which can paint white independently of the WebView background. The change keeps that failed document hidden while preserving startup retries, and reveals the successful replacement only when drawable.\n\nA real Android WebView regression fails before the change (error document visible), then passes after it, including retry recovery. The existing 34 theme/reload unit tests also pass. This does not yet certify normal-document dark CSS loading or the three drawer transitions, so #300 remains open; no published-release or Realme-device success is claimed.
TimeToBuildBob commentedon Oct 19, 2026
Controlled follow-up on the local debug APK containing #371: the residual System-dark cold-start flash is still reproducible, so this issue remains open.
Three of five accepted cold-start recordings contain full-white central-content frames. In one of those runs, WebView inspection also samples the successful localhost dashboard with
theme=auto, dark media preference, a light body and no dark stylesheet link yet while the native WebView is visible. It later turns dark. This rules out an error-document-only explanation; the native error-page fix is partial.All six settled System/Light/Dark × device-dark/light controls pass when selected through the actual Appearance controls. Simulated dark-stylesheet failure leaves a usable light page; removing interception and reloading restores dark. These are API 34 emulator results on an identified local APK, not a published-release or Realme-device certification. No new product patch in this follow-up. The tracked next step is a successful-document first-paint regression and a bounded theme/reveal-order repair, without arbitrary sleeps.
TimeToBuildBob commentedon Oct 19, 2026
Follow-up: #374 targets the remaining successful-document flash.
The dashboard paints its light base styles while it loads settings and before
dark.cssarrives, and the WebView was visible during that whole time. #374 now keeps each document hidden until it has finished and reported its theme as applied:#wrapperis rendered anddark.csshas loaded or failed. A bounded failsafe reveals any page that never reports this.Local debug build (API 34 emulator, not a release or a physical device):
Native drawer transitions and stylesheet failure on this build are not re-checked yet. I'm keeping this issue open until a release containing the fix has been verified.
fix(webview): reveal dashboard only after its theme stylesheet settles (
akirad3d4 commentedon Oct 31, 2026
Tested with the latest build artifacts. Everything now works much more smoothly (no more flashing).
The "Sync Settings" and "API Authentication" screens render correctly in dark mode, but they currently only follow the system theme, not the in-app theme setting.
TimeToBuildBob commentedon Oct 31, 2026
Thanks for confirming the flash is gone on the 2026-10-26 master artifact (run 40369988341, which includes the #374 reveal-after-theme-settled fix).
The remaining gap is real: Sync Settings and API Authentication are native screens on
AppTheme.FollowNight, so they follow the device night mode. The in-app Light/Dark/System choice lives in the dashboard's localStorage and currently only drives the WebView. I'll persist that setting and apply it to those two screens so they follow the in-app choice (System still follows the device). Leaving this issue open until that lands.TimeToBuildBob commentedon Oct 31, 2026
Follow-up: #382 persists the dashboard Appearance setting and applies it to Sync Settings and API Authentication via
setLocalNightMode(Dark/Light override the device; System still follows it). Onboarding stays light-only.This is a unit-tested source fix, not a device check of those two screens. #300 stays open until Light/Dark can be verified against the opposite device mode on a build that includes this change.