5

I'm trying to be able to start music playback from my app when the headset buttons are clicked while my app is stopped.

I can use MediaSession.Callback onMediaButtonEvent() or the now deprecated registerMediaButtonEventReceiver() to listen for media button click WHILE my app is playing music, but if I pause the music for a minute, with my Activity and playback Service still running, and then I press the headset button, I see that I have lost the ability to receive the media button broadcast. Instead, Google Now opens.

What I'm trying to do is something like Google Play Music. It is able to start music playback even if the app is completely stopped...no services in the background.

I feel that setMediaButtonReceiver() is the one to use for this, but I've not been able to get it to work.

setMediaButtonReceiver(PendingIntent mbr)

Set a pending intent for your media button receiver to allow restarting playback after the session has been stopped. If your app is started in this way an ACTION_MEDIA_BUTTON intent will be sent via the pending intent.

I have the following snippet in my Service.

PendingIntent pi = PendingIntent.getBroadcast(HeadsetService.this, 0, new Intent(HeadsetService.this, RemoteControlReceiver.class), 0);
mMediaSession.setMediaButtonReceiver(pi);

My RemoteControlReceiver BroadcastReceiver is registered in the Manifest but I receive no broadcast when I press the button.

I've also seen that other music player apps lose the ability to receive media button broadcasts once they've stopped playback for about minute.

Any ideas how I can have a more robust media button controls?

Thanks in advance!

Community
  • 1
  • 1
David Heisnam
  • 2,463
  • 1
  • 21
  • 32

1 Answers1

4

First, it is important to distinct MediaSessionCompat from any service such as MediaBrowserServiceCompat.

MediaSessionCompat is communicating with the external MediaSessionStack that dictates which app will get media key commands from external MediaSessionService. On API 26+ the key will be sent to the last playing app. Devices with API < 26 will first look for active playing/buffering session, then for active session and then for last playing session. The latter allows apps to 'steal' the focus by keeping the mMediaSesssion.isActive tag on when they shouldn't. More details about priority can be found in the official guide.

So as long as your app set mMediaSesssion.isActive = true at some point and was last playing, it will get media keys unless mMediaSession.release() was called. The latter removes your session from MediaSessionStack and thus will your session no longer receives media keys. That's why it is important to call release() once you no longer expect user to continue playing video or music. There is one more caveat: If system thinks your app was killed as opposed to ended gracefully, then the app is removed from MediaSessionStack as well, which makes sense, because in service onDestroy() is not necessarily called in such scenario and thus the system releases your session for you. This might happen when you swipe away the app. A workaround I use is to keep the service in foreground while the main app is in use and then end the service after a short delay upon receiving a call to onTaskRemoved() in service.

The call to mMediaSession.release() will happen at some point if you put it in onDestroy() of your service. The service is expected to end when it is not being used, as otherwise it is taking system resources. Thus, it is recommended to end it in onStop() command or when swiping away app or notification. In your case it may happen that power manager killed your service after being inactive for some time. Depending on implementation the some parts of the player might still be working even if the service is destroyed. Also the notification might still be there, as the service is no longer in foreground. That might've fool you into thinking that the service was running. Though without more details, I cannot really say what exactly went wrong in your case.

One additional cause that might prevent your app from getting media keys is if your manifest is not properly configured. Make sure that your BroadcaseReceiver entry includes android.intent.action.MEDIA_BUTTON intent filter.

Another possible mistake is initializing your media key callback MediaSessionCompat.Callback() in the service or any other lifecycle component. Thus, if that component gets destroyed, it can quickly lead to unexpected behavior.

TLDR:

Filter your Logcat for MediaSessionStack|MediaSessionService to ensure that your app gets the media keys. If it doesn't, then:

  • ensure that mMusicService.isActive = true is set (in e.g. in onPlay())
  • ensure that mMusicService.release() is not called
  • ensure that your manifest is properly set
  • ensure that the system doesn't think your service was killed (e.g. by swiping away the app) as opposed to being ended gracefully

Then make sure your app is handling media keys properly.

  • In case of custom receiver, they should be there.
  • In case of androidx.media.session.MediaButtonReceiver they should be in MediaControllerCompat.Callback() whose state should not depend on any service or lifecycle component

I wrote the answer a little bit more general, since it is an old question and others might benefit from it more than the OP.

Jure Sencar
  • 554
  • 4
  • 13