Confusion about Media3 service lifecycle and playback resumption

[OxygenCobalt]

Currently, my app operates on a playback service lifecycle like this:

• Service will attempt to load any persisted playback state on startup
• Service only starts it's foreground state when the player starts playing
• Service remains in it's foreground state indefinitely until the user explicitly exits it through either removing the task or clicking the close button on the notification

While attempting to re-architecture it around media3, I'm running into some very deep confusion about the way it works with MediaSessionService. As far as I am aware

• Service will go foreground the moment you add a session
• Service will exit foreground on task removal or spontaneously if the activity isn't in the foreground
• Playback resumption plays some confusing role in here that interferes with my own persistence at a lot of points

I can't tell if this is the way the service is meant to behave or if it's a configuration problem on my part. Ideally I want to retain my old service lifecycle, as it's much more straightforward to manage with the other foreground service work I have to do, and it's what users are currently used to. However, if this is more ideal, I guess I can use it if there was more details on how the service is supposed to be behaving. Any help here would be appreciated.

Also related to #1246 somewhat, since it's also about having to reconcile my self-rolled lifecycle and Media3's.

[marcbaechinger]

There is some documentation about the service lifecyclce on DAC. Playback resumption is documented here.

Basically, the service is put to foreground when the player is playing and taken off the foreground when not playing. Whether an activity is in the foreground or not isn't related to any service state. Playback resumption is called when play is called when the player is in STATE_IDLE and the player is empty.

If you want to change this behaviour you can override MediaSessionService.onUpdateNotification(MediaSession session, boolean startInForegroundRequired) if you want to roll your own. We can't provide detailed support about this, but given you have such a service in use already that should be doable.

[OxygenCobalt]

Basically, the service is put to foreground when the player is playing and taken off the foreground when not playing.

I find this weird since when I populate the Player (but not play at all) when the MediaSession is added to the service, it will always enter a foreground state no matter what I do.

Whether an activity is in the foreground or not isn't related to any service state.

This is also confusing, since I noticed that the service notification will only disappear when paused when you aren't actively using the activity.

Playback resumption is called when play is called when the player is in STATE_IDLE and the player is empty.

I'm not sure what this means. If I have a player that is paused with a non-empty queue, playback resumption will still trigger.

For now I'm just going to go back to self-rolling my own service lifecycle and reverse-engineering when onUpdateNotification is called. I remember there being some detailed diagrams about the way the old MediaBrowserService would be created, bound, put to foreground, etc. It would be nice to have one of those instead of 3-4 sentence blurbs about which functions to override @marcbaechinger.

[marcbaechinger]

Basically, the service is put to foreground when the player is playing and taken off the foreground when not playing.
I find this weird

That's the Android policy for media services. We behave accordingly by default. We provide an API to violate that policy - please accept my apologies for not going further.

since when I populate the Player (but not play at all) when the MediaSession is added to the service, it
will always enter a foreground state no matter what I do.

Can you let me know what you understand under foreground state and how I can repro what you describe above. It would be a bug I think because starting the service into foreground or getting it of the foreground is based on this expression in MediaNotificationManager.

Please note that the service can be in a bound state, which may look for you as a foreground state. When in a bound state, then the system is never stopping the service (sorry, guess this is repetition for you).

I noticed that the service notification will only disappear when paused when you aren't actively using the activity.

This is about a controller being bound to the service rather than whether an activity is around. The service doesn't know about the existence of an Activity.

The system terminates the service after a while when not in foreground and when no controller is bound to it. If you see a connection with your Activity then this is because you have implemented your activity correctly and nicely, and you release the controller when the activity goes into background.

instead of 3-4 sentence blurbs about which functions to override @marcbaechinger.

I try to help everyone as good as I can. I'm happy to hear you appreciate that. I'm also fine to take the blame for disappointing our users.

There are a combinatoric number of ways how to start and stop the service. We unfortunately can't cover this with diagrams for every use case. Your use case seems to be an interesting but a specific one. I'm sorry to hear MediaSessionService doesn't fit your needs.

The diagram below shows Background playback (continue playback when task removed).

[OxygenCobalt]

That's the Android policy for media services. We behave accordingly by default. We provide an API to violate that policy - please accept my apologies for not going further.

Oh, interesting. I don't think I was ever aware of that policy and winged my own state management for awhile.

Can you let me know what you understand under foreground state and how I can repro what you describe above. It would be a bug I think because starting the service into foreground or getting it of the foreground is based on this expression in MediaNotificationManager.

Foreground state for me is when the media notification is shown, at least that's how it would work with my current state management. I'm 90% sure it's probably an issue on my end though, since I'm probably prodding the MediaSession in a lot of ways during startup that could trigger the foreground state. What I think sticks out in that logic is that it decouples showing the notification and indicating the foreground state, so I could be misinterpreting MediaNotificationManager posting a notification as it going foreground.

Please note that the service can be in a bound state, which may look for you as a foreground state. When in a bound state, then the system is never stopping the service (sorry, guess this is repetition for you).

I don't actually explicitly bind to the service. I assume this is a consequence of the decoupling of notifications and foreground states that I'm observing.

This is about a controller being bound to the service rather than whether an activity is around. The service doesn't know about the existence of an Activity.

The system terminates the service after a while when not in foreground and when no controller is bound to it. If you see a connection with your Activity then this is because you have implemented your activity correctly and nicely, and you release the controller when the activity goes into background.

See above. I'm violating the contract here pretty deeply since I never actually bind to the service. This would explain all this strange behavior. The app internally uses an in-memory communication layer since MediaItem is not expressive enough for some of the data I have to work with. The service only uses MediaItems with external binders (i.e Android Auto). I do understand I could bind to the service and marshal around IDs, but I think this would be prone to slippage since it would require referencing a volatile in-memory mapping of some sort.

I try to help everyone as good as I can. I'm happy to hear you appreciate that. I'm also fine to take the blame for disappointing our users.

There are a combinatoric number of ways how to start and stop the service. We unfortunately can't cover this with diagrams for every use case. Your use case seems to be an interesting but a specific one. I'm sorry to hear MediaSessionService doesn't fit your needs.

This is fine. Sorry for being somewhat needy there. I'm starting to realize that the problem largely lies in my app's architecture that makes it nearly impossible to cleanly integrate with Media3 in this moment. I'll re-architecture around Media3 with my own non-standard service management and without playback resumption, and then revisit this later. Closing this.