(Android) Problems resuming playback after being paused in the background.

[khatharr]

I let zxt play in the background on my car's bluetooth while I'm driving and using Google Maps. When I make a stop and turn off the car, zxt (correctly) pauses playback. The problem is that when I get back in the car and reconnect, zxt does not resume playback unless I was only away for a few moments. I have to bring the app to the foreground and wait several seconds while it appears to be reloading the track or something.

This appears to be related to the playback notification. When the app is paused and in the background, the notification persists for a short time, but then closes. This seems to indicate that the app has released its resources and won't be able to restart playback smoothly.

This issue also appears to be affecting the widget. Hitting play on the widget doesn't do anything unless the app is loaded and ready to play.

[vitamin-caig]

First of all, this issue tracker is robot-only (it's noticed in the repository description), not a big problem, but issues may be lost in bunch of automatic ones.

Yes, you are right, when you stop playback, zxtune releases all the resources, so system is able to kill the app (looks like it really happens). It's by design to not to waste device resources and shouldn't be changed.
As for widget notification - I'll take a look. I suppose, proper app resuming will solve your problem.

[khatharr]

My other media players (Rocket Player,
PodKicker, Smart AudioBook Player) retain their resources and state until their notification is dismissed. Any chance of seeing that type of behavior implemented?

[vitamin-caig]

Resources (and app lifetime) are not controlled by notification, vice versa - when system kills the app, all the notifications are removed. When you clean notification by yourself, it doesn't mean anything but notification absence:)
Decision is up to system - app has no ability to influence to systems' behaviour (imagine malicious software that can). You can try to enable developer options in setup menu and tune amount of stored activities, but it's not guaranteed to success.

[khatharr]

I would imagine that those apps are employing services for playback and the app proper is just a front-end. It's been a while since I looked at Android dev, but I believe that such a service would actually require a persistent notification until it closes. I believe they're just taking advantage of this in order to provide a button to close/release: 

[vitamin-caig]

Yes, app usually consists from two parts - background service and frontend.

When playback is started, service creates notification in order to work in background - it cannot be cleared. When playback is stopped, service just stops background job and may clear notification (or may not- it's not necessary). In that state system is free to kill service and/or frontend application. If it's done, all the notifications are cleared too.
When you swipe out app from the list of recent activities, system kills both service and frontend not paying attention whether they active or not.

[khatharr]

There must be some method of retaining the service until the user hits a "close" button? This appears to be the convention used by the other media players.

[vitamin-caig]

The only way is to keep playback service in background mode in spite of its playback status. It's unacceptable.

As for your situation: try to initiate playback from widget several times, it may help.