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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1398427 Title: Can't use earphone to answer or disconnect a call To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1398427/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
