Fix keep-awake releasing the wakelock shortly after connect#224
Merged
Conversation
The old name conflated 'needs ongoing service work' with the predicate's actual role, and excluding keepAwake was a real bug: keep-awake-only devices were getting the post-PR1 15s idle grace instead of staying alive, releasing the partial CPU wakelock prematurely. Behavior changes: - Toggling keepAwake on an already-connected device now auto-starts the foreground service (matches existing behavior for volume-lock and volume-observing toggles). - The orchestrator now stays alive indefinitely while any keepAwake device is connected, holding the CPU wakelock as intended.
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.
The keep-awake setting wasn't actually keeping the device awake. On Bluetooth connect, the partial CPU wakelock was acquired correctly, but ~15 seconds later the monitor service would stop (when the post-connect dispatcher fell idle) and release the wakelock again — leaving the user with the original problem the toggle was meant to solve.
Root cause: the
requiresMonitorpredicate onManagedDeviceexcludedkeepAwakeand only flipped true for the three volume-monitoring features. So a profile with only KeepAwake enabled fell through to the "stop after idle + 15s grace" path instead of the "stay alive" path. The same predicate was used byMonitorControlfor reactive auto-start, so toggling KeepAwake on an already-connected device also did nothing.Renamed the property to
requiresPersistentSessionand addedkeepAwaketo the predicate.Behavior changes:
Companion to the recent Bluetooth-connect timing PRs.
Test plan
./gradlew assembleFossDebug./gradlew testFossDebugUnitTest(566 pass)./gradlew testGplayDebugUnitTest(566 pass)