5

When users double click the play/pause button on their headsets quickly, I have code to detect that and skip to the next song automatically. Unfortunately it seems like when using the RemoteControlClient, it uses the same PLAY_PAUSE event. If you accidently click twice on the lockscreen pause (or more commonly, accidently double click on the Android Wear display to try to get it to respond), it then skips to the next song. I only want this to happen on Bluetooth headsets though. Is there a way to differentiate between the two?

Floss
  • 637
  • 4
  • 16
  • Could you explain a bit more? What do you mean when you say "the same PLAY_PAUSE event"? – arkon Sep 13 '14 at 16:53
  • Pressing the pause button on the lock screen triggers this event: KeyEvent.KEYCODE_MEDIA_PLAY_PAUSE – Floss Sep 14 '14 at 20:25
  • Okay, so are you actually trying to catch events from `RemoteControlClient`? Because [KeyEvent.KEYCODE_MEDIA_PLAY_PAUSE](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_PLAY_PAUSE) and [RemoteControlClient.FLAG_KEY_MEDIA_PLAY_PAUSE](http://developer.android.com/reference/android/media/RemoteControlClient.html#FLAG_KEY_MEDIA_PLAY_PAUSE) are not the same. – arkon Sep 15 '14 at 00:20
  • Check for `keyEvent.getAction()`: on a sample app on my end I am not getting `KeyEvent.ACTION_DOWN` from BT headset's play/pause button click. I don't have wired headset with play/pause button, so I could not check with one. See if this works. – ozbek Sep 15 '14 at 01:39
  • @b1nary.atr0phy I am receiving events from both RemoteControlClient and regular key events, like I say in the description. RemoteControlClient.FLAG_KEY_MEDIA_PLAY_PAUSE is flag you pass to the RCC, not a key event that you try to catch. If you look at the developer documentation it even links to KeyEvent.KEYCODE_MEDIA_PLAY_PAUSE in the description. – Floss Sep 15 '14 at 02:39
  • 1
    @Floss You're right I misread the docs. I imagine you're going to have to override the default event so you can swallow it if it originates from a source you wish to ignore (which may require using a broadcast listener.) I haven't messed with remote control related stuff in awhile, so I'll give a few links which hopefully will help you get on track. **1:** http://stackoverflow.com/questions/17819649/how-to-capture-key-events-from-bluetooth-headset-with-android **2:** http://android-developers.blogspot.in/2010/06/allowing-applications-to-play-nicer.html **3:** http://android.amberfog.com/?p=415 – arkon Sep 15 '14 at 03:06
  • @Floss, did you check with the `KeyEvent.getAction()`? – ozbek Sep 17 '14 at 01:15
  • @shoe rat, I don't have access to anything to test with, so I don't know if ACTION_DOWN is ever used with Bluetooth key events or not. Due to the huge range of different hardware and manufacturers changing core behavior in each one, I doubt such an assumption can be made and not break it on some devices. – Floss Sep 17 '14 at 20:20

1 Answers1

-1

I would prefer you to go through https://developer.android.com/sdk/api_diff/19/changes.html

Sure, this will help you a lot.

Navnish Bhardwaj
  • 1,687
  • 25
  • 39
  • Are you kidding? Why leave such a worthless answer which has absolutely nothing to do with the question? RCC was introduced in ICS, not KitKat so you aren't even in the same ballpark. – Floss Sep 17 '14 at 20:16