Skip to content

feat(android): add theme mode selection#90752

Merged
joshavant merged 3 commits into
openclaw:mainfrom
Tosko4:feat/android-theme-mode-selection
Jun 7, 2026
Merged

feat(android): add theme mode selection#90752
joshavant merged 3 commits into
openclaw:mainfrom
Tosko4:feat/android-theme-mode-selection

Conversation

@Tosko4

@Tosko4 Tosko4 commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Summary

What problem does this PR solve?

  • Adds a persisted Android appearance setting so users can choose System, Dark, or Light instead of being locked to the app default.
  • Applies the selected mode through the Android root theme and nested design theme surfaces, including onboarding, shell, Settings, Sessions, and Markdown/code token styling.
  • Polishes the light palette so the app uses a calmer off-white canvas, consistent raised surfaces, and readable code chips/blocks instead of dark code backgrounds in light mode.

Why does this matter now?

  • The Android shell now has enough user-facing surface area that theme consistency is visible across Home, Sessions, Chat, and Settings.
  • Light mode without consistent tokens makes list rows and formatted text look like mixed theme states.

What is the intended outcome?

  • Existing installs keep the current dark default.
  • Users who opt into System or Light get a coherent light UI, including navigation/system bars and Markdown/code rendering.

What is intentionally out of scope?

  • No gateway, auth, pairing, notification, permission, or Play-policy behavior changes.
  • No redesign of the broader Android shell beyond the theme picker and light-token polish.

What does success look like?

  • The selected theme persists, resolves correctly against system dark mode, and renders the key Android shell surfaces consistently.

What should reviewers focus on?

  • Preference/default behavior for existing installs.
  • Whether theme tokens are applied at the right Android UI boundaries without leaking into unrelated gateway/runtime behavior.

AI-assisted: implemented and validated with Codex, then manually inspected and tested in a local Android/OpenClaw setup.

Linked context

Which issue does this close?

Closes #

Which issues, PRs, or discussions are related?

Related #

Was this requested by a maintainer or owner?

  • No public issue. This is a narrow Android UI follow-up from local light-mode testing of the rebuilt Android shell.

Real behavior proof (required for external PRs)

  • Behavior or issue addressed: Android Appearance now exposes System/Dark/Light, and light mode no longer uses mismatched gray list backgrounds or dark code-themed surfaces.
  • Real environment tested: local Android emulator with the thirdPartyDebug app installed from this branch and connected to a local OpenClaw Android test profile.
  • Exact steps or command run after this patch:
    • Install the thirdPartyDebug build on the local Android emulator.
    • Open Settings -> Appearance.
    • Select Light.
    • Navigate back to Home and open Sessions.
    • Capture screenshots from the running app with adb exec-out screencap -p.
  • Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

Appearance theme picker in Light mode:

Appearance theme picker in Light mode

Home in Light mode:

Home in Light mode

Sessions in Light mode:

Sessions in Light mode

  • Observed result after fix: the Appearance screen persists and reflects the Light selection, Home uses the same light canvas/surface family, and Sessions renders on the light canvas without a separate gray list background.
  • What was not tested: Play release bundle signing, physical device rendering, and a real private chat transcript with non-empty session rows/code blocks.
  • Proof limitations or environment constraints: the local emulator was not connected to private user chat data, so screenshot proof uses empty/generic shell states; Markdown/code color coverage is validated by the theme-token path and unit tests rather than a private transcript screenshot.
  • Before evidence (optional but encouraged): not included; this PR is based on local UI testing where the issue was visible in light-mode screenshots.

Tests and validation

Which commands did you run?

  • git diff upstream/main --check
  • ANDROID_HOME=<Android SDK> ANDROID_SDK_ROOT=<Android SDK> ./gradlew :app:testThirdPartyDebugUnitTest --tests ai.openclaw.app.ui.ShellScreenLogicTest :app:assembleThirdPartyDebug --no-daemon --stacktrace
  • ANDROID_HOME=<Android SDK> ANDROID_SDK_ROOT=<Android SDK> ./gradlew :app:installThirdPartyDebug --no-daemon --stacktrace
  • ANDROID_HOME=<Android SDK> ANDROID_SDK_ROOT=<Android SDK> ./gradlew :app:ktlintCheck --no-daemon --stacktrace
  • CODEX_HOME=<Codex auth home> skills/autoreview/scripts/autoreview --mode branch --base upstream/main

What regression coverage was added or updated?

  • ShellScreenLogicTest now covers theme-mode defaulting, label round trips, and System/Dark/Light resolution against system dark mode.

What failed before this fix, if known?

  • The Android UI had no persisted theme-mode selection, and light-mode surfaces could render with inconsistent canvas/list/code colors.

If no test was added, why not?

  • Focused unit coverage was added for the new mode contract. Full visual regression testing is covered by the real emulator screenshots above.

Validation notes:

  • :app:testThirdPartyDebugUnitTest --tests ai.openclaw.app.ui.ShellScreenLogicTest, :app:assembleThirdPartyDebug, and :app:installThirdPartyDebug passed.
  • :app:ktlintCheck still fails on existing upstream Android ktlint issues outside this PR, including ChatController.kt, GatewayDiscovery.kt, DeviceHandler.kt, PermissionRequester.kt, SessionFilters.kt, MicCaptureManager.kt, and TalkModeManager.kt. None of the reported ktlint files are touched by this branch.
  • Local autoreview completed cleanly with no accepted/actionable findings.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes.

Did config, environment, or migration behavior change? (Yes/No)

Yes. A new local Android appearance preference is persisted in plain app prefs.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No.

What is the highest-risk area?

  • Upgrade/default behavior: existing installs should not unexpectedly flip theme.

How is that risk mitigated?

  • Missing or unknown stored values default to Dark, preserving the current behavior for existing installs.
  • System and Light are only used when the user explicitly selects them.
  • The selected mode is resolved once and passed through the existing Compose theme boundaries instead of touching gateway/auth/runtime state.

Current review state

What is the next action?

  • Draft PR is ready for maintainer review after CI and ClawSweeper proof review.

What is still waiting on author, maintainer, CI, or external proof?

  • Waiting on GitHub CI and ClawSweeper.
  • Physical-device proof can be added if maintainers want it, but the Android emulator proof covers the changed UI paths.

Which bot or reviewer comments were addressed?

  • No GitHub bot or reviewer comments yet.

@openclaw-barnacle openclaw-barnacle Bot added app: android App: android size: M proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 5, 2026
@clawsweeper

clawsweeper Bot commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed June 7, 2026, 6:23 PM ET / 22:23 UTC.

Summary
The PR adds a persisted Android System/Dark/Light appearance setting, wires it through the Android Compose theme roots, polishes light-mode tokens, and adds focused unit coverage.

PR surface: Other +185. Total +185 across 13 files.

Reproducibility: not applicable. as a bug reproduction; this is a feature PR, and current-main inspection confirms Android still shows a fixed Dark Appearance screen with no persisted mode selector.

Review metrics: 1 noteworthy metric.

  • Persisted Android settings: 1 added. The new appearance.themeMode preference defines upgrade/default behavior that maintainers should notice before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • none.

Risk before merge

  • [P1] The branch adds a persisted Android appearance preference and treats missing or unknown stored values as Dark; that preserves the stated current dark shell behavior, but maintainers should explicitly accept Dark rather than System as the upgrade default.
  • [P1] Screenshot proof covers the Light picker, Home, and empty Sessions screens; the Markdown/code token-styling claim remains covered by token wiring and tests rather than direct non-empty chat visual proof.

Maintainer options:

  1. Accept Dark as upgrade default (recommended)
    A maintainer can explicitly accept the tested Dark default for missing or unknown stored values, then let normal CI and review gates decide merge readiness.
  2. Switch the default to System
    If Android convention should win over preserving the current dark shell, change the enum fallback and SecurePrefs tests so fresh and upgraded installs follow system mode by default.
  3. Request fuller visual coverage
    If the Markdown/code styling claim matters for merge confidence, ask for a non-empty chat or Markdown/code screenshot before landing.

Next step before merge

  • [P2] The remaining action is maintainer acceptance of the Android appearance default and upgrade policy, not a narrow automated repair.

Security
Cleared: The diff is limited to Android UI/theme preference code and tests; it does not change secrets, auth, network, dependencies, workflows, or executable supply-chain surfaces.

Review details

Best possible solution:

Land the Android-local theme picker after maintainer sign-off on the Dark upgrade default, or switch the missing/unknown preference default to System if maintainers want Android convention over preserving the current dark shell.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a bug reproduction; this is a feature PR, and current-main inspection confirms Android still shows a fixed Dark Appearance screen with no persisted mode selector.

Is this the best way to solve the issue?

Yes, conditionally: Android app prefs and Compose theme boundaries are the right layer for this feature, but the Dark fallback is a product/upgrade choice maintainers should accept explicitly before merge.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 57e0bdaabe0a.

Label changes

Label changes:

  • add proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies emulator screenshots showing the after-fix Light picker, Home, and Sessions UI; contributors should keep private data redacted in any additional proof.

Label justifications:

  • P3: This is a useful Android UI preference and polish change with limited blast radius outside the app shell.
  • merge-risk: 🚨 compatibility: Merging the PR creates a new persisted Android setting and chooses Dark as the fallback for existing installs and unknown stored values.
  • rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The PR body supplies emulator screenshots showing the after-fix Light picker, Home, and Sessions UI; contributors should keep private data redacted in any additional proof.
  • proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies emulator screenshots showing the after-fix Light picker, Home, and Sessions UI; contributors should keep private data redacted in any additional proof.
  • proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body supplies emulator screenshots showing the after-fix Light picker, Home, and Sessions UI; contributors should keep private data redacted in any additional proof.
Evidence reviewed

PR surface:

Other +185. Total +185 across 13 files.

View PR surface stats
Area Files Added Removed Net
Source 0 0 0 0
Tests 0 0 0 0
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 13 244 59 +185
Total 13 244 59 +185

What I checked:

Likely related people:

  • vincentkoc: Current-main blame/log for the central Android theme, shell, settings, and prefs files points to commit e5a9c60, though the checkout history appears squash-heavy so ownership confidence is limited. (role: current Android shell/history owner signal; confidence: medium; commits: e5a9c608511c; files: apps/android/app/src/main/java/ai/openclaw/app/ui/OpenClawTheme.kt, apps/android/app/src/main/java/ai/openclaw/app/ui/ShellScreen.kt, apps/android/app/src/main/java/ai/openclaw/app/ui/SettingsScreens.kt)
  • joshavant: The PR branch includes cbea63f refining the Android theme-mode implementation and adding SecurePrefs regression coverage. (role: recent PR branch refiner; confidence: medium; commits: cbea63f20895; files: apps/android/app/src/main/java/ai/openclaw/app/AppearanceThemeMode.kt, apps/android/app/src/main/java/ai/openclaw/app/ui/OpenClawTheme.kt, apps/android/app/src/main/java/ai/openclaw/app/ui/SettingsScreens.kt)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. proof: 📸 screenshot Contributor real behavior proof includes screenshot evidence. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels Jun 5, 2026
@Tosko4 Tosko4 force-pushed the feat/android-theme-mode-selection branch from ce4afb6 to be172f0 Compare June 6, 2026 23:12
@openclaw-barnacle openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 6, 2026
@Tosko4 Tosko4 marked this pull request as ready for review June 6, 2026 23:16
@clawsweeper clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 6, 2026
@openclaw-barnacle openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 7, 2026
@clawsweeper clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 7, 2026
@joshavant joshavant merged commit 3c73ff7 into openclaw:main Jun 7, 2026
45 of 46 checks passed
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request Jun 8, 2026
* feat(android): add theme mode selection

* refine Android theme mode handling

---------

Co-authored-by: joshavant <830519+joshavant@users.noreply.github.com>
wangmiao0668000666 pushed a commit to wangmiao0668000666/openclaw that referenced this pull request Jun 9, 2026
* feat(android): add theme mode selection

* refine Android theme mode handling

---------

Co-authored-by: joshavant <830519+joshavant@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

app: android App: android merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. proof: 📸 screenshot Contributor real behavior proof includes screenshot evidence. proof: sufficient ClawSweeper judged the real behavior proof convincing. proof: supplied External PR includes structured after-fix real behavior proof. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. size: M status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants