09-26-2013 06:05 AM
I am trying to use the headset button to perform some actions in my app.
I successfully managed to detect the events using audio_manager_event (MediaKeyWatcher works fine but only for the device button, not for the headset). The problem now is that this button also triggers the default mediaplayer. As a result, while my app can perform an action (custom sound), the media player plays/pauses the music at the same time, which might be quite annoying for the user...
Is there a possibility to inhibit the default action triggered by the headset button?
A possibility is to completly disable the global mediaplayer from the app (using mediaplayer_aquire()) but it has some drawbacks:
- it still triggers the action (mediaplayer is started), eventhough the player cannot start anymore
- the user does not necessarily like to have the mediaplayer disabled
Any help is welcome!
09-26-2013 10:14 AM
have you tried setting an action for the play/pause media key? that is the action you're describing the headset button to do, so if you over ride that I think that might solve your issue.
Another way you could test to see if it works is to create a key watcher for each action and have it console.log("") something different for each different action that would make it easier to see what keys fire what action
09-26-2013 12:54 PM
Thanks for the answer!
As described, MediaKeyWatcher works fine but only for device buttons (not for the headset). Detecting button events works anyway, even if I have to use a "core" library (Audio Manager Library). The problem is that I cannot prevent the default media player from being triggered (play/pause), which means that using the headset button in my app does not only trigger my own action but also the media player. It would be very useful to be able to inhibt the default action.
09-26-2013 01:02 PM - edited 09-26-2013 01:03 PM
I get it now
There is also another bug that affects anything below 10.2 that allows another app to take ownership of the media keys meaning app #1 loses all media key functionality until app #2 is closed. This has been fixed with 10.2 though....
This is a behaviour that could likely only be changed through a ticket
If you have not tested this on 10.2, test it on 10.2 to make sure it hasn't already been fixed & if it still persists create a ticket and they will look into it
09-26-2013 01:09 PM - edited 09-26-2013 01:10 PM
I am using 10.2 and probably wish I had the behavior *before* the fix, which means that I need my app to take ownership of the media keys (especially the headset ones...).
I will check it again and create a new ticket. Is the bug you described already in jira?
09-26-2013 01:13 PM - edited 09-26-2013 01:17 PM
The bug i described is a closed ticket in jira becasue it has been fixed. the issue you're having is separate and I don't belive there's anything similar. if you title it
Headset MediaKey Issue
and then describe how the default action is still running even though you've changed it
also include that you've tested in 10.2
Just a heads up for while you're testing your apps for deployment. I have noticed alot of differences between versions 10.2 and 10.1, just because something works in 10.1 doesnt mean it works in 10.2 this is also the same for if something works in 10.2 it doesn't mean it works in 10.1.... It's a pain but i think it will get better once 10.2 is completed.