How to communicate intermediate loading state for resolving items to session, to start FGS

When app is started by Google Assistant, media session is created through media browser service, and it calls TransportControls.playFromSearch which is routed to our app. At this point, framework gives us 10 seconds to start a foreground service: https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/media/MediaSessionDeviceConfig.java;l=51?q=getMediaSessionCallbackFgsWhileInUseTempAllowDurationMs&ss=android%2Fplatform%2Fsuperproject

if we take longer than 10 seconds, we cannot play audio reliably because we can't start foreground service (or since Android 17, it won't work at all if I understand https://developer.android.com/about/versions/17/changes/bg-audio correctly).

A similar scenario is media button playback resumption, where Bluetooth device generates media button intent, reciever calls startForegroundService() and we have a few seconds to respond to that with startForeground().

So it is essential to be quick in that process.

However in current media3 design, we are not quick. Foreground service is started once player has items set and is preparing, when a notification is posted. However the process of even just finding out which items to play may take some time due to IO, or even network access. For example, onPlaybackResumption() might need to load recommendations, or onAddMediaItems() might need to call backend to search for items. For most cases this works fine, but for edge cases where these methods take too long the app will just crash (ForegroundServiceDidNotStartInTimeException) or audio playback won't be able to start (because we can't start foreground service and hence can't get audio focus).

Am I missing some obvious way to handle this that's already built into media3 to do this?

I can think of putting a forwarding player into the session that will generate fake loading state until items are set and prepare is called at which point it will switch to real player, but I honestly think it's not very clean due to seperation of concerns, as in essence both getting service to foreground and updating session/notification state are responsibility of session module and not player.

I was thinking, if we already have these nice APIs in session module that handle incoming request and starting playback after items are determined automatically, shouldn't session module also automatically bring the service into foreground before starting to wait for the result of these futures? There could just be a media notification in loading state and with "Loading..." text or similar, service put in foreground. And music playback would be more reliable even in these edge cases.