In `MediaButtonReceiver`, don't always bail out for `KeyEvent != play`

[ByteHamster]

Use case description

I recently switched an app from a custom playback service to the more "standardized" media3 MediaLibraryService. A problem I ran into is that a simulated media pause button event (sent as a broadcast) does not work anymore. This seems to be a deliberate decision; the MediaButtonReceiver bails out for key events that are not "play":

media/libraries/session/src/main/java/androidx/media3/session/MediaButtonReceiver.java

Lines 162 to 165 in aceb0bc

	Log.w(
	TAG,
	"Ignore key event that is not a `play` command on API 26 or above to avoid an"
	+ " 'ForegroundServiceDidNotStartInTimeException'");

Proposed solution

Is there a way for MediaButtonReceiver to detect whether the service it wants to start is already running? If it is already running, we do not risk a ForegroundServiceDidNotStartInTimeException by sending the key event to it. So it should be safe to relay all the other key events (pause, fast forward, etc) as well.

Alternatives considered

• Writing our own MediaButtonReceiver to do exactly that would of course be possible. However, I feel like adding this to the main media3 library as some kind of backwards compatibility layer could benefit additional users of the library and avoid them spending as much time on this as I have. Also, it avoids adding a bunch of custom code around media3 that needs to stay in sync with the original media3 implementation.
• Contact all third party app developers who control media playback and ask them to implement control via media sessions. I'm not convinced that I can convince several third party developers to do that. This is also not something we can tell to our users: "your macro button no longer works because we made a change forcing the developer of your macro button app to update their app". (even though our app update is in beta, we already got reports about two different 3rd party media control apps no longer working)

[marcbaechinger]

Thanks for your request.

You are correct that the recommended way to send playback commands is to connect a controller with your service. This is specifically the case for playback commands that are not starting playback. Using a controller works if your service is already running as well as when the service is not started yet. It ensures that apps don't run into issues with service restrictions of the Android system, because the user of the controller is in the foreground and binds to the service. This is robust and solid.

Media button events are sent through the MediaButtonReceiver only for cases where the service needs to be started [1]. It is the mechanism to route anonymous play events (typically from a BT device) to a broadcast receiver to start the service for playback resumption. No further logic is expected to go through this receiver. The system directly routes such event to the service in case the service is already running.

I feel like adding this to the main media3 library as some kind of backwards compatibility layer

Background start restrictions have been introduced with Android 12 (2021). Since then, apps did have time to change their behavior and get off Intent based playback commands. System UI stopped using Intent based playback controls in 2020 [2] even when these Intents are only sent directly to the service and not to the receiver. Similar, the SystemUI resumption notification starts the service by using a MediaBrowser when the user taps the play button on the notification.

Given the issues we have withIntent based service starts that crash apps and cause critical problems for them on the play store, I don't think I can generate lots of enthusiasm to back such an Intent approach into the standard implementation of the MediaButtonReceiver I'm afraid.

could benefit additional users of the library and avoid them spending as much time on this as I have

I see your point and I guess in case I wasn't the person who has to triage and work through issues here on GH regarding FGS crashes to protect our users, I probably would think similarly. For now I think I value avoiding such crashes over a convenience implementation for a marginal use case we do not recommend.

I think we cover all use cases with an approach that is safe. If advanced users want to go beyond what's the recommended approach, they can.

[1] https://developer.android.com/media/legacy/media-buttons#finding-a-media-session
[2] https://android-developers.googleblog.com/2020/08/playing-nicely-with-media-controls.html

[ByteHamster]

Thanks a lot for your fast and detailed reply!

Given the issues we have with Intent based service starts that crash apps

Of course, starting the service for a pause event would cause a crash. However, do you also see a risk in sending those events even when the service is already running? In that case, it shouldn't run into FGS crashes, shouldn't it?