Repository navigation
Conversation
application.Mobile.SetStatusBar(json) has always accepted only "style"
(icon light/dark) and "hidden" in its JSON payload on Android — the
"color" key that callers might reasonably expect a status-bar API to
support (matching how the equivalent theme attribute
android:statusBarColor already colors it statically) was never read by
WailsBridge.setStatusBar(), so the status-bar background could only ever
reflect whatever was baked into the app's static theme at Activity
creation, never anything set at runtime.
This is easy to hit for any app that switches between light/dark themes
at runtime from JS rather than following the OS-level day/night setting:
the icon style updates correctly (that part was already wired), but the
background color stays stuck at whatever the static theme resolved to
when the Activity was created, silently mismatching the new icon color —
e.g. light icons on a still-light background, unreadable status-bar text.
Add color handling: parse an optional "color" key ("#RRGGBB" /
"#AARRGGBB") and apply it via Window.setStatusBarColor(), alongside the
existing style/hidden handling. No API surface changes — "color" is a
new optional key in an existing JSON payload, so this is fully backward
compatible with callers that don't send it.
Not applicable to iOS: UIStatusBarStyle has no background-color concept
there (the iOS status bar is always a transparent overlay tinted by
whatever view sits behind it), so this is an Android-only addition and
mobile_features_ios.go is untouched.
Touches:
- v3/internal/commands/build_assets/android/app/src/main/java/com/wails/app/WailsBridge.java
- v3/pkg/application/mobile_features_android.go (doc comment)
- v3/examples/mobile/build/android/app/src/main/java/com/wails/app/WailsBridge.java
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
application.Mobile.SetStatusBar(json)on Android only ever applied the"style"(icon light/dark) and"hidden"keys from its JSON payload.WailsBridge.setStatusBar()never read a"color"key, so there was noway to set the status-bar background color at runtime — it always
reflected whatever
android:statusBarColorresolved to statically inthe app's theme at Activity creation.
This becomes a real, user-visible bug for any app that implements its
own in-app light/dark toggle (as opposed to following the OS-level
day/night setting): switching themes updates the status-bar icon color
correctly, but the background stays at whatever the static theme
resolved to when the Activity launched — e.g. light icons rendered over
a background that's still light, making the status bar unreadable.
Reproduced on a real Android 9 device; on some other devices/emulators
this silently self-corrects only because the OS-level dark mode happens
to already match, which is what made it easy to miss.
This PR adds optional color support:
WailsBridge.setStatusBar()now also reads"color"("#RRGGBB"or"#AARRGGBB") and applies it viaWindow.setStatusBarColor(),alongside the existing style/hidden handling.
"color"is a no-op, so this isfully backward compatible — no method signature changed, no existing
behaviour changed for callers that don't send it.
UIStatusBarStylehas nobackground-color concept (the status bar there is always a
transparent overlay), so a
"color"key isn't meaningful on thatplatform and
mobile_features_ios.godoesn't need a matching field.Is a WEP required?
This adds a new optional key to an existing JSON payload rather than a
new method or interface change —
MobileManager.SetStatusBar'ssignature is unchanged, and no other file needs updating to keep the
interface satisfied. My read is this is small enough to not need one,
but flagging it since it's technically a new capability rather than a
strict regression fix, and I'd rather ask than assume.
Type of change
How Has This Been Tested?
Reproduced and verified on a real Android 9 device (美图 V3): before this
change, toggling the app's in-app dark theme changed the status-bar icon
color but left the background white, making the icon text unreadable;
after applying this fix, the background now follows the app's chosen
color and the icon/background stay in sync. Also verified no regression
on an Android (Pixel 10 Pro, emulator) build where the OS-level dark
mode already masked the bug.
Test Configuration
<paste your
wails3 doctoroutput here>Checklist:
v3/UNRELEASED_CHANGELOG.mdsource only —
mobile-api.mdand theSetStatusBardoc comment inmobile_features_android.go; translated doc copies arecommunity-maintained and left untouched)
feature works — this is a thin Android UI call with no branching
logic to unit test; verified manually on-device as above