Open GoogleCodeExporter opened 9 years ago
Volume keys are currently filtered by TalkBack on 4.3+ for better handling of
volume stream switching. Will consider an alternative approach or a user
preference in a future release.
Original comment by caseybur...@google.com
on 5 Dec 2013 at 7:53
I just ran into the same issue. My app for the blind uses
KeyEvent.KEYCODE_VOLUME_DOWN and KeyEvent.KEYCODE_VOLUME_UP events to control
the sound volume of generated audio in pre-specified increments. This works
fine unless TalkBack is running (I'm testing with an HTC One M8 running Android
4.4.2). How can I now catch these basic volume key events? Can I override some
function?
I could a few times per second poll AudioManager.getStreamVolume() to detect
up/down changes in the current audio volume, and then apply
AudioManager.setStreamVolume() to apply the intended pre-specified volume
increments of my app, but this is an excruciatingly ugly stopgap for a bad
accessibility design choice. Please let me know of a better way to deal with
this unwanted TalkBack side-effect?
Thanks!
Original comment by seeingwi...@gmail.com
on 3 May 2014 at 7:24
To add to the mess, my app also uses the KeyEvent.KEYCODE_VOLUME_DOWN and
KeyEvent.KEYCODE_VOLUME_UP events in keyboard navigation while not in its main
screen, and that too now fails due to TalkBack consuming these events. Please
advise.
Original comment by seeingwi...@gmail.com
on 3 May 2014 at 7:29
Volume button events still not being delivered to apps on latest Android 5.0.1
Lollipop on Nexus 4 (tested just now) if TalkBack is on.
Original comment by stereoma...@yahoo.com
on 20 Jan 2015 at 4:21
Issue is still observed in Android version 5.1 with Talkback version 4.2.0.
Device: Nexus 6
Original comment by smcs...@gmail.com
on 17 Aug 2015 at 12:03
Original issue reported on code.google.com by
b...@2ndsight.si
on 12 Aug 2013 at 10:25