fix: route short-press volume to active stream during calls#375
Open
howdoiusekeyboard wants to merge 1 commit intosameerasw:developfrom
Open
fix: route short-press volume to active stream during calls#375howdoiusekeyboard wants to merge 1 commit intosameerasw:developfrom
howdoiusekeyboard wants to merge 1 commit intosameerasw:developfrom
Conversation
When Button Remap consumes the volume DOWN event via FLAG_REQUEST_FILTER_KEY_EVENTS and re-simulates short-press behaviour on UP, three call sites passed STREAM_MUSIC explicitly, which overrode Android's default stream routing during calls, ringing, and other active-stream contexts. Switch each site to adjustSuggestedStreamVolume with USE_DEFAULT_STREAM_TYPE — the documented API for "do what hardware volume keys would normally do". The system then routes to STREAM_VOICE_CALL during calls, STREAM_RING while ringing, STREAM_MUSIC while music plays, and falls back to the suggested type when nothing is active. Sites changed: - ButtonRemapHandler.kt:153 accessibility-service path - InputEventListenerService.kt:171 Shizuku /dev/input, torch on - InputEventListenerService.kt:199 Shizuku /dev/input, torch off The toggleMediaVolume() helper at ButtonRemapHandler.kt:244,251 stays on STREAM_MUSIC by design — it backs the user-selected "Toggle media volume" mapping action. The ~500ms perceived latency that comes from the consume-then-replay design is structural to short-press handling and is not addressed here.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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
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.
Problem
With Button Remap enabled and a mapping on Vol+ / Vol-, a single short press always changed media volume — even during a phone call. This overrode Android's default stream routing (STREAM_VOICE_CALL during calls, STREAM_RING while ringing, etc.).
Cause
The accessibility service path consumes the volume DOWN event via
FLAG_REQUEST_FILTER_KEY_EVENTSand re-simulates default volume behaviour on UP if no long-press fired. Three call sites in that re-simulation hardcodedSTREAM_MUSIC, so every short press always adjusted media volume regardless of what stream Android would have picked.Fix
Replace the hardcoded
adjustStreamVolume(STREAM_MUSIC, …)withadjustSuggestedStreamVolume(direction, USE_DEFAULT_STREAM_TYPE, FLAG_SHOW_UI)at the three sites. This is the documented Android API for "do exactly what hardware volume keys would normally do" — the system itself picksSTREAM_VOICE_CALLduring calls,STREAM_RINGwhile ringing,STREAM_MUSICwhile music plays, and falls back to the suggestion when nothing is active. Ref:AudioManager.adjustSuggestedStreamVolume.Sites changed
app/src/main/java/com/sameerasw/essentials/services/handlers/ButtonRemapHandler.kt:153— accessibility-service path, screen-onapp/src/main/java/com/sameerasw/essentials/services/InputEventListenerService.kt:171— Shizuku/dev/inputpath, torch-on branchapp/src/main/java/com/sameerasw/essentials/services/InputEventListenerService.kt:199— Shizuku/dev/inputpath, torch-off branchIntentionally untouched
toggleMediaVolume()atButtonRemapHandler.kt:244,251keepsSTREAM_MUSIC. That helper backs the user-selected Toggle media volume mapping action, which by design must act on media volume regardless of active stream.Out of scope
The ~500 ms perceived latency on short-press is structural to the consume-then-replay design (DOWN is consumed, only UP-before-timeout re-simulates) and is not what this PR addresses. Worth a separate UX pass.
Verification
./gradlew assembleDebug— green; no new warnings on the edited lines.adjustStreamVolumecalls remain in the re-simulation paths; threeadjustSuggestedStreamVolumecalls at the edited lines.Diff: 6 changed lines across two files.