Fix: Adaptive Brightness has no effect on physical brightness while KompaktX is running - #7
Open
chadchad4423 wants to merge 3 commits into
Conversation
added 3 commits
August 24, 2026 19:26
applyBrightness() unconditionally forced Settings.System.SCREEN_BRIGHTNESS_MODE to MANUAL every time it ran -- including from reapplyBrightness(), which fires on every ACTION_SCREEN_ON broadcast and every accessibility-service reconnect, and from loadSavedBrightness(), which fires whenever the touch-strip service (re)starts. Neither of those is the user touching a brightness control; both are KompaktX passively restoring its last-known brightness. The net effect: once KompaktX had ever set a brightness (which happens the first time its overlay brightness control is used, and persists across restarts), turning Adaptive Brightness back on in system settings never stuck -- the very next screen wake silently flipped it back to manual. Add a forceManualMode parameter to applyBrightness(), defaulting to true so every direct user gesture (slider drag, sun-icon tap, front-light toggle) keeps forcing manual mode, matching stock Android's own behavior when you drag its brightness slider. The two passive-restore call sites now pass false, so they reapply the physical brightness (still correct) without silently overriding a system setting the user didn't just touch. Scope note: buildBrightnessSection() and buildBrightnessSubPanel() still force manual mode once each, at the top of the function, whenever KompaktX's own brightness UI is displayed (not only when it's touched). That's a smaller, separate quirk left out of this patch to keep it narrowly scoped to the dominant bug -- the continuous every-wake override -- rather than touching every place brightness mode is set.
Adaptive Brightness now stays on as a setting (fix/preserve-adaptive-brightness), but the physical backlight never actually became adaptive: brightnessOverlay's WindowManager.LayoutParams.screenBrightness permanently pins the real screen to a static value the moment it's first applied, and nothing ever released it back to 'no override' in response to SCREEN_BRIGHTNESS_MODE. - Add a ContentObserver on SCREEN_BRIGHTNESS_MODE so flipping Adaptive Brightness on releases the overlay, the panel window, and the lockscreen accessibility overlay immediately. - applyBrightness(forceManualMode = false) - the passive reapply path used on screen wake and service restart - now checks current mode first and skips all Settings.System writes and overlay pinning entirely when Adaptive Brightness is already on, instead of re-clamping the screen to a stale target every time. Built on fix/preserve-adaptive-brightness: without that branch's change, reapplyBrightness()/loadSavedBrightness() would keep forcing manual mode on every wake, undoing this the moment the screen slept and woke again.
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.
Fix: Adaptive Brightness has no effect on physical brightness while KompaktX is running
KompaktX drives the physical backlight through a persistent 1x1 overlay
window (
WindowManager.LayoutParams.screenBrightness), separate fromAndroid's own brightness system. That overlay's brightness value was set
once and never released, so even after a user turned Adaptive Brightness
back on, the overlay kept pinning the screen to its last static value —
physical brightness stopped responding to ambient light entirely, even
though the Adaptive Brightness toggle itself correctly showed "on."
A second, related path made this worse:
brightnessObserver(theContentObserverwatchingSettings.System.SCREEN_BRIGHTNESS) would reactto any external brightness write — including the ones Android's own
adaptive-brightness algorithm makes continuously — by re-pinning the overlay
back to a stale target, fighting the system's live adjustments in real time.
This PR:
ContentObserveronSettings.System.SCREEN_BRIGHTNESS_MODEthatreleases the overlay/panel/lockscreen brightness overrides the moment
Adaptive Brightness is turned on, so the physical backlight goes back to
being fully system-controlled.
isAdaptiveBrightnessOn()guard at the top ofbrightnessObserver'sonChange(), so it stops reacting toSCREEN_BRIGHTNESSwrites at all while adaptive mode is active — it nolonger fights the system's own live adjustments.
applyBrightness(forceManualMode = false), used byreapplyBrightness()/loadSavedBrightness()) to skipoverlay pinning entirely while Adaptive Brightness is already on.
Testing
Built on top of #5 (Fix 2) since this change depends on the
forceManualModeparameter it introduces. Verified on a physical MuditaKompakt (MuditaOS K 1.5), standalone and combined with the other three
fixes (Fix 1 + Fix 2 + Fix 3 + Fix 4 together, cherry-picked onto one
branch):
Settings → Display checks, sleep/wake, KompaktX slider drag, System UI
slider sync — 100% pass.
swings: confirmed brightness tracked it live, not just holding a static
value that happened to pass the screen-based checks.
Note: this PR is best reviewed/merged alongside #4 (Fix 1) — both
independently touch
brightnessObserver, and combined testing confirmedthey merge and behave correctly together, but each is written to be
correct and independently mergeable on its own.