Thanks for your report!

The intended behavior in the case of STATE_ENDED is to keep the notification and have the play button active. The user can either press the play button to resume playback at the start of the last item in the playlist, or (starting with API 29) use the timebar to seek back to a position in the last item to resume playback.

I think this would be the desired behavior when the user removes the app from recents as well, but as you report this is not the case. We will look into this and update this issue if we have some news.

player.playbackState == Player.STATE_ENDED || to the condition has helped fix this in my app.

Agreed this is a workaround that fixed the behavior. I'd keep this as a last resort in the case the above scenario isn't working.

Thanks again for your report.

Adding player.playbackState == Player.STATE_ENDED || to the condition has helped fix this in my app.

After investigating a bit more, I think this is indeed the correct fix.

When doing the repro steps above, I end up dismissing the app from the recents when the player is paused and with this, the player is not in the foreground. This means that the service needs to be stopped. Playback can then be resumed for instance with the playback resumption notification.

I think that behaves as it should. When in STATE_ENDED the service is taken off the foreground. If the user dismissed the app in this state, the service needs to be stopped or then the system restarts the service assuming it has crashed because it wasn't properly stopped after being in STARTED state. This results in this log statement that I can repro:

2024-03-26 21:58:46.133   649-1272  ActivityManager         system_process                       W  Scheduling restart of crashed service androidx.media3.demo.session/.PlaybackService in 1000ms for start-requested

So the proper fix is indeed to check for STATE_ENDED also as you suggest. I will change the documentation accordinlgy:

  override fun onTaskRemoved(rootIntent: Intent?) {
    val player = mediaLibrarySession.player
    if (!player.playWhenReady || player.mediaItemCount == 0 || player.playbackState == STATE_ENDED) {
      stopSelf()
    }
  }

However, this check becomes a bit cumbersome and I think we should create an API that an app can use.

I agree, this is basically inversing the check here:

We fixed the documentation here, so that it works with the current version.

For the next version we have included API support to make this a bit easier for app.

There are two options an app is having:

1. Keep the service running in the background as a foreground service when playback is ongoing

For this we have added a default implementation of onTaskRemoved() in MediaSessionService that looks like this:

@Override
public void onTaskRemoved(@Nullable Intent rootIntent) {
  if (!isPlaybackOngoing()) {
    // The service needs to be stopped when playback is not ongoing and the service is not in the
    // foreground.
    stopSelf();
  }
}

The default implementation makes sure that we don't see crashes of the service in case an app doesn't implement onTaskRemoved().

2. Always stop the service when the task is removed

The default from above can be overriden as follows by using the new convenience method:

override fun onTaskRemoved(rootIntent: Intent?) {
  // Stop the service event when playback is ongoing.
  pauseAllPlayersAndStopSelf()
}

the method pauseAllPlayersAndStopSelf() pauses the player of every session that is managed by the service and then calls stopSelf.

The whole change in MediaSessionService is based on these methods. We also added JavaDoc to explain the default behaviour and the options an app has based on the foreground service restrictions imposed by the system.

I'm closing this issue. Please file a new issue if required.

Thank you!