How to gate playback on Bluetooth Headset connection #15

Activity

1. yschimke

   added

   needs triage

   question

   on Dec 3, 2021
2. ojw28 commented on Dec 3, 2021

   

   ojw28

   on Dec 3, 2021

   Last edited by ojw28

   Contributor

   More actions

   I think this should be done outside of the player. In other words, you should query whether there's a bluetooth headset connected before you prepare your ExoPlayer instance. ExoPlayer's audio-becoming-noisy handling might be sufficient for stopping the audio, but it's probably cleaner and more symmetric if you also handle this outside of the player. In other words, listen for the headset disconnecting, and stop the player when this occurs.

   How to query bluetooth connected devices is outside the scope of this issue tracker, but you should be able to find what you need online. For example https://stackoverflow.com/questions/4715865/how-can-i-programmatically-tell-if-a-bluetooth-device-is-connected has some sample isBluetoothHeadsetConnected methods that might be useful to you.
3. ojw28

   closed this as completedon Dec 3, 2021
4. ojw28

   self-assigned this

   on Dec 3, 2021
5. ojw28

   removed

   needs triage

   on Dec 3, 2021
6. yschimke commented on Dec 3, 2021

   

   yschimke

   on Dec 3, 2021

   ContributorAuthor

   More actions

   @ojw28 Thanks. That makes sense, and I've got docs on how to check and connect to the bluetooth headset.

   It's not perfect, If the app laucnhes and then bluetooth disconnects before playback is started, I'll be in the same place. I can guard any play button presses, but it doesn't help for commands via the MediaSession, so I was hoping there was a nice approach to do this in ExoPlayer/Media3. Maybe show up via affecting availableCommands? Maybe interject during the LoadControl before it continues? I understand if not, and if there is some clean way to add, I'll suggest putting up a PR.

   Would there be a downside to using LoadControl?
7. ojw28 commented on Dec 6, 2021

   

   ojw28

   on Dec 6, 2021

   Last edited by ojw28

   Contributor

   More actions

   I don't think LoadControl is the right place to be doing this. It feels like it's too deep in the player.

   If you'd like to push your logic for starting playback just inside of the player, so that it works for commands via the MediaSession (and any other UI component), then you could use ForwardingPlayer. This is completely untested, but I'd imagine it would look something like:

   class BtPlayer extends ForwardingPlayer {
   
       public BtPlayer(ExoPlayer player) {
         super(player);
         player.setHandleAudioBecomingNoisy(true);
       }
   
       @Override
       public void prepare() {
         if (blockPlayback()) {
           return;
         }
         super.prepare();
       }
   
       @Override
       public void play() {
         if (blockPlayback()) {
           return;
         }
         super.play();
       }
   
       @Override
       public void setPlayWhenReady(boolean playWhenReady) {
         if (playWhenReady && blockPlayback()) {
           return;
         }
         super.setPlayWhenReady(playWhenReady);
       }
   
       private boolean blockPlayback() {
         // Return whether playback should be blocked from starting
       }
   }
   

   You can then wrap your ExoPlayer inside an instance of this class, and pass the BtPlayer to the media session and any other UI components.

   👍React with 👍1Reacted by Yuri Schimke
8. yschimke commented on Dec 7, 2021

   

   yschimke

   on Dec 7, 2021

   ContributorAuthor

   More actions

   Thanks I'll try that or fallback to external logic at all points before playing.

   Thanks.
9. yschimke commented on Oct 3, 2022

   

   yschimke

   on Oct 3, 2022

   ContributorAuthor

   More actions

   The above solution has worked reasonably well, but it looks like to avoid errors like #167.

   We will need to implement google/horologist#562 and use playback suppression for this.
10. marcbaechinger

    added 2 commits that reference this issue on Oct 17, 2022

    Add suppression reason for unsuitable audio route.

    ...

    278853a

    Add suppression reason for unsuitable audio route.

    ...

    0208b1b
11. androidx

    locked and limited conversation to collaborators on Mar 4, 2023