Yes, it is true that your background service should respond to resume playback, however it is supposed to be tied to audio focus. As long as the background playback service has the focus, then it should receive the media playback button events. Once this focus is lost, it should release them. If the audio focus loss is transient, such as in case of ducking, then the app can go ahead and hold on to the button events, but sadly Subsonic doesn't handle ducking either (that's another feature that I dearly wish would be implemented.) The Android developer documentation talks about this stuff here:
http://developer.android.com/training/m ... focus.htmlHaving now downloaded the Subsonic source code, I think I understand how this bug happens. I searched to find where the application calls the unregisterMediaButtonEventReceiver() and the ONLY place I found the call was inside of the SettingsActivity. On the other hand, the registerMediaButtonEventReceiver() is called in the SettingsActivity, SubsonicTabActivity, BluetoothIntentReceiver, and DownloadServiceLivecycleSupport. That right there tells me that Subsonic is not calling the unregister method in all the places where it should. Since there are 4 different classes that register as receivers, they get put on the registered receiver stack, and so even if you uncheck the preference in settings to disable the media buttons, the other classes are still registered as receivers and consequently, the app always hogs the media buttons. This is exactly the behavior I'm seeing, since I have the "Media Buttons" setting unchecked, but the app still responds to the buttons. The only way to keep Subsonic from constantly taking over all media button events is to completely uninstall the application. This is clearly not how it should work.