KEYCODE_HEADSETHOOK sent twice

[ckett73]

Version

Media3 1.9.2

More version details

Since Media3 version 1.9.2, button events seem to be sent twice.
We see events like KEYCODE_HEADSETHOOK received twice by onMediaButtonEvent (MediaSession).
This leads to strange playback behaviour, because we need to evaluate the events received by onMediaButtonEvent.

Reproduce with
adb shell input keyevent 79
or some wired headset with a "hook" button.

Maybe this is related to:
#2816

Devices that reproduce the issue

Reproduced with:

• Emulator Pixel 9a API 36
• Samsung SM-T220

Devices that do not reproduce the issue

None

Reproducible in the demo app?

Yes

Reproduction steps

1. Play some media (audio) with Media3
2. Send adb shell input keyevent 79 or press headset hook button

Expected result

Only one event per button click or keyevent send

Actual result

Events are duplicated. Received in onMediaButtonEvent

Media

Any audio media

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[marcbaechinger]

Thanks for your report.

I can't repro this I'm afraid. When I try to repro this I add this line for logging just after the Callback is called:

Log.d(
        "mediaButtonEvent",
        "keyCode: "
            + keyEvent.getKeyCode()
            + ", action: "
            + keyEvent.getAction()
            + " ("
            + (keyEvent.getAction() == KeyEvent.ACTION_DOWN ? "DOWN" : "UP")
            + ")");

I then deploy the session demo app and start playback. Then I do :

adb shell input keyevent 79

This gives me two things. First I see that playback pauses when I send the key event. When I send another key event I see that playback is resumed. This works as intended. I'd expect a second event would pause/start immediately resulting in a short stop or nothing the users sees at all. I can confirm though this seems to work as intended.

I then check the logs which actually seems to confirm what I was expecting. Each key event produces two calls while one of it is a of type ACTION_DOWN followed by an ACTION_UP for each click (the logs below are from sending the event twice in an about 5 seconds interval).

2026-02-20 12:39:46.129 10670-10670 mediaButtonEvent        androidx.media3.demo.session         D  keyCode: 79, action: 0 (DOWN)
2026-02-20 12:39:46.130 10670-10670 mediaButtonEvent        androidx.media3.demo.session         D  keyCode: 79, action: 1 (UP)
2026-02-20 12:39:51.296 10670-10670 mediaButtonEvent        androidx.media3.demo.session         D  keyCode: 79, action: 0 (DOWN)
2026-02-20 12:39:51.297 10670-10670 mediaButtonEvent        androidx.media3.demo.session         D  keyCode: 79, action: 1 (UP)

The DOWN/UP pairs are coming within one or two milliseconds, which I think is also the expected behavior.

If you see something else, can you please do a similar test like I did? Best would be if you add an EventLogger that wouild also tell us how these command are interpreted by the media session and then delegated to the player. We would see the player going paused and resume again quickly I think.

This leads to strange playback behaviour, because we need to evaluate the events received by onMediaButtonEvent.

Another possible action is to review the app code whether action down and up are properly looked at to make sure the are interpreted by the app as what they are: part of a single event which always has an up and down action part.

Lastly, I may have misunderstood your report, So if I need to repro differently, please let me know and advise.

[ckett73]

Thanks Marc.
Now things are clearer. We recently switched from Media3 1.8.0 to Media3 1.9.2.
We never evaluated the key event action in onMediaButtonEvent, because there was only one event.
1.8.0:
14:12:21.962  I  onMediaButtonEvent; keycode: 79 action: 0 controller Bundle[{}] packagename android
Now
1.9.2:

14:08:20.824  I  onMediaButtonEvent; keycode: 79 action: 0 controller Bundle[{}] packagename android
14:08:20.824  I  onMediaButtonEvent; keycode: 79 action: 1 controller Bundle[{}] packagename android

I think evaluating only the ACTION_UP will solve our problems.

[marcbaechinger]

Yeah you are right. I found that change that changed this behavior: e33f6d4

So I indeed changed that to not filter stuff to get the app the full truth in the callback! This definitely changed the behavior for you without you having a chance to know.

Sorry, this is my fault. This should have been documented better in the release notes somewhere! Please accept my apologies!

[ckett73]

Thanks. Closed this issue.