Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KEYCODE_HEADSETHOOK and double click behaviour #1493

Closed
1 task
DavidEdwardsBL opened this issue Jun 24, 2024 · 2 comments
Closed
1 task

KEYCODE_HEADSETHOOK and double click behaviour #1493

DavidEdwardsBL opened this issue Jun 24, 2024 · 2 comments
Assignees
Labels

Comments

@DavidEdwardsBL
Copy link

Version

Media3 main branch

More version details

No response

Devices that reproduce the issue

Devices that have a headset attached to them and send KEYCODE_HEADSETHOOK when clicking on the headsets primary button.

Concrete error device: OPPO CPH1951.

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

  1. Play media
  2. Double click on headset primary button (usually on single button headsets it is play / pause)

On all devices, the issue can be reproduced by sending the keycode for KEYCODE_HEADSETHOOK twice (replicating a double tap) over ADB.

We took a look at the code, and can see why there is an issue. At this stage, we are testing for PLAY_PAUSE and HEADSETHOOK. It then sets a handler to fire to detect a double tap. Once the next tap comes through, the double tap flag is set.

After the flag is set, it will be checked either here or here. Unfortunately, neither cases take KEYCODE_HEADSETHOOK into account. This leads to next media not being set.

Expected result

The system converts to a seek to next.

Actual result

The system makes a play / pause.

Media

Any

Bug Report

@icbaker
Copy link
Collaborator

icbaker commented Jun 25, 2024

Thanks for reporting - it looks like HEADSETHOOK is handled for double tap by media1: https://cs.android.com/android/platform/superproject/+/androidx-main:frameworks/support/media/media/src/main/java/android/support/v4/media/session/MediaSessionCompat.java;l=1147-1150;drc=1991cf1992f8ec2331848b8f0b6c26a433da5f54

I also noticed our code seems to consider KEYCODE_MEDIA_PLAY for the second of a double tap (in one of the branches), but not the first:

if ((keyCode == KEYCODE_MEDIA_PLAY_PAUSE || keyCode == KEYCODE_MEDIA_PLAY)
&& doubleTapCompleted) {

I've sent a change to make all 3 places handle all 3 of:

  • HEADSETHOOK
  • PLAY_PAUSE
  • PLAY

copybara-service bot pushed a commit that referenced this issue Jul 10, 2024
As reported in Issue: #1493 we already use `HEADSETHOOK` to start
waiting for a double-tap, but we don't consider it for the second tap.

Similarly, we previously considered `PLAY` for the second tap, but not the first.
Only `HEADSETHOOK` and `PLAY_PAUSE` are
[documented](https://developer.android.com/reference/androidx/media3/session/MediaSession#media-key-events-mapping)
to transform double-tap to `seekToNext`. So this change removes the
`PLAY` detection from the second tap.

#cherrypick

PiperOrigin-RevId: 651017522
@icbaker
Copy link
Collaborator

icbaker commented Jul 10, 2024

After a bit of back and forth in review, I dropped the handling of PLAY for consistency with what we already document. The change is linked above.

@icbaker icbaker closed this as completed Jul 10, 2024
tianyif pushed a commit that referenced this issue Aug 22, 2024
As reported in Issue: #1493 we already use `HEADSETHOOK` to start
waiting for a double-tap, but we don't consider it for the second tap.

Similarly, we previously considered `PLAY` for the second tap, but not the first.
Only `HEADSETHOOK` and `PLAY_PAUSE` are
[documented](https://developer.android.com/reference/androidx/media3/session/MediaSession#media-key-events-mapping)
to transform double-tap to `seekToNext`. So this change removes the
`PLAY` detection from the second tap.

PiperOrigin-RevId: 651017522
(cherry picked from commit c64dacf)
@androidx androidx locked and limited conversation to collaborators Sep 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants