Comment 7 for bug 1398427

On Fri, Dec 5, 2014 at 1:24 PM, Michał Sawicz
<email address hidden> wrote:
> Is there value/desire to providing the play/pause event to the
> foreground app if it's not playing audio?
>
> In my mind the events (all those that originate from the headset, be it wired or bluetooth) should just follow the audio stream (if any) to its source (media playback - media-hub; ringtone - telephony-service; during a call - telephony-service as well; playing a game - the foreground app; etc.). I know you can post feedback events on audio streams and that feels to me like the most natural way to deliver those.
> We should only have a fallback policy in place for when there's no audio playback - deliver to media hub to resume the most recently played stream? To voice recognition on long press?
>
> Headphone (dis)connection (again, wired or otherwise) falls into the
> same group of events, if possible.

Yes, and in every case you described media-hub is involved (the only
one atm that is not yet covered is video playback using the browser).

I think a question for design is that if we should only care to send
events for multimedia specific applications, such as music-app and
mediaplayer-app. This is just because a game running in foreground
shouldn't necessarily need to care when we get such event from the
bt/wired headset.