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

Expose current focus state from AudioFocusManager #1436

Closed
spun opened this issue Jun 9, 2024 · 1 comment
Closed

Expose current focus state from AudioFocusManager #1436

spun opened this issue Jun 9, 2024 · 1 comment
Assignees
Labels

Comments

@spun
Copy link

spun commented Jun 9, 2024

I would like to have a way to receive focus loss events from the default AudioFocusManager. As far as I know, if another app starts playing and requests focus, we will receive an onPlayWhenReadyChanged event with the correct reason (PLAY_WHEN_READY_CHANGE_REASON_AUDIO_FOCUS_LOSS). However, if we pause our app and then the other app starts playing, the focus loss is not notified.

Use case description

I want to have access to the focus state value to improve my "Resume on headset insertion" feature.

Currently, I have an AudioManager.ACTION_HEADSET_PLUG receiver to resume the playback if it was previously paused with a PLAY_WHEN_READY_CHANGE_REASON_AUDIO_BECOMING_NOISY reason. Unfortunately, if a user listening to my app does the following:

  1. Disconnects the headset
  2. Starts playing something in another app
  3. Reconnects the headset to listen to that other app

My feature will resume the playback when it shouldn't. I would like to use the focus state value to skip the resume action in those cases.

Possible solutions

I wonder how feasible it would be to add a way to query the current focus state and/or listen to some EVENT_AUDIO_FOCUS_LOSS Player Event that is emitted even when playWhenReady is already false.

I know I can use setAudioAttributes to handle audio focus myself, but I would need to recreate the entire AudioFocusManager class and even override important methods from Player just to start handling the focus. After seeing how tightly coupled the default AudioFocusManager is with ExoPlayerImpl, I'm concerned about missing some edge cases and leaving my app in a bad state just to receive a focus loss event.


Apologies if this is something we can already do. If not, I also understand that it is not that important to have, but since this is information that AudioFocusManager already has, I wonder if there is a way to expose this to clients. Thank you.

@tonihei
Copy link
Collaborator

tonihei commented Jun 17, 2024

Thanks for reporting! I think the original intention was to re-report Player.Listener.onPlayWhenReadyChanged with a new reason if the reason for being paused changed to PLAY_WHEN_READY_CHANGE_REASON_AUDIO_FOCUS_LOSS. We'll see that we can fix that and then you should be able to see this callback while your app is paused.

copybara-service bot pushed a commit that referenced this issue Jun 20, 2024
Some cases are not handled correctly at the moment:
 - Pausing during suppressed playback should not clear the
   suppression state.
 - Transient focus loss while paused should be reported as
   a playback suppression.

Issue: #1436
#cherrypick
PiperOrigin-RevId: 644971218
@tonihei tonihei closed this as completed Jun 24, 2024
tianyif pushed a commit that referenced this issue Jul 2, 2024
Some cases are not handled correctly at the moment:
 - Pausing during suppressed playback should not clear the
   suppression state.
 - Transient focus loss while paused should be reported as
   a playback suppression.

Issue: #1436
#cherrypick
PiperOrigin-RevId: 644971218
(cherry picked from commit e84bb0d)
@androidx androidx locked and limited conversation to collaborators Aug 24, 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