Android Auto - Communication between background service and Activity

Question

I'm attempting to add a MediaBrowserService for Android Auto to an existing media-player app. The app has a single activity which manages the MediaSession , Callbacks and related state. It has been set up so that it emits events, which the background MediaBrowserService consumes and uses to build its content tree.

This all works fine when the flow is like:

Start my app -> Start Android Auto -> Browse media

However, it falls flat on its face when the flow is:

Start Android Auto -> Browse media

...as in, when the app is not started and running in the background prior to when Android Auto is launched.

The problem appears to be that although my MediaBrowserService will be automatically launched by Android Auto, it does not create a corresponding instance of my app's Activity when it does so (which means no events to inform the MediaBrowserService , and consequently no content available in Android Auto).

Ideally it seems like the MediaBrowserService needs to be able to check and see if the app's "main" Activity is running, and spawn a new instance if/when it is not. But not sure if that's possible, and it tends to feel like it's the wrong approach to take here.

What's the correct way to work around this issue? I don't want to replicate all of the app's MediaSession handling and playback-related code in the MediaBrowserService implementation. That should be kept as lightweight as possible. Is there a way to ensure that the app's Activity is always running whenever the MediaBrowserService is active?

Answer 1

The answer to this was refactoring. Lots and lots of refactoring.

In a nutshell, Android expects Activities to be used to fill a particular architectural niche . Specifically, the niche where you're displaying an interface to the user via the device's screen. Other use-cases, such as having a 'headless' Activity running in the background, appear to be neither expected nor supported.

Thus the answer was to take all of the app's playback-related code out of the Activity , move it into a background Service , and provide an API for passing on the relevant commands (and receiving data, state updates and so on) either from/to the foreground Activity (if/when the user is interacting with the app's UI) or from/to the MediaBrowserService (if/when the user is interacting through Android Auto's UI). Starting the service is something that can be easily done from either context, if/when needed.

That appears to be the solution. It certainly can be tedious if you've got a nontrivial existing codebase you're working with. Far better to anticipate this sort of issue, and architect your app accordingly from the start; keep things that aren't directly pertinent to your app's UI outside of your Activity implementation(s).