Fix: Adaptive Brightness turns off during screen sleep/wake - #5
Open
chadchad4423 wants to merge 1 commit into
Open
Fix: Adaptive Brightness turns off during screen sleep/wake#5chadchad4423 wants to merge 1 commit into
chadchad4423 wants to merge 1 commit into
Conversation
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.
chadchad4423
changed the title
This was referenced Aug 25, 2026
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 turns off during screen sleep/wake
KompaktX's brightness-apply path (
applyBrightness()) unconditionally forcedSettings.System.SCREEN_BRIGHTNESS_MODE_MANUALon every call, including passive reapply calls that happen on wake/resume (reapplyBrightness(),loadSavedBrightness()). This meant that if a user had Adaptive Brightness enabled, it would silently get switched off any time the screen went to sleep and woke back up, or whenever KompaktX reapplied its saved brightness.This PR adds a
forceManualModeparameter (defaulttrue, preserving existing behavior for the paths that should force manual mode) and sets it tofalsefor the two passive-reapply call sites, so they no longer force the mode switch.Testing
Verified on a physical Mudita Kompakt (MuditaOS K 1.5) — enabled Adaptive Brightness, put the display to sleep, woke it, confirmed Adaptive Brightness was still on.