Doze Mode/App Standby During Audio Playback

Question

I have noticed an issue with my audio streaming app on Android 6.0 devices. Audio streaming is done via HLS over a network connection. Audio playback occurs in a foreground service with an active notification. What I've noticed is that when the app enters doze mode/app standby, the wifi connection is lost and playback pauses. My service is in the foreground and has an active notification which, according to the docs, should qualify my app to not be interrupted. I also acquire and maintain a Wifi Lock. I've read about whitelisting my app, however apps like Spotify don't request any special permissions to avoid this issue. Any thoughts or suggestions?

Kianakiang

Could you figure out any solution to this? I am also facing the same issue with my audio streaming app on Android 6.0 I acquire a Wakelock and an Wifilock too, but when Doze happens, the audio streaming stops. Any ideas? – Gwin

No solutions so far, will update if I do find one. Please do the same @Gwin – Kianakiang

Ok, sure will confirm if I find a solution? Can you also confirm after how long does the Audio stop(means after how long the phone goes into Doze?). My users have been complaining after a few minutes. But shouldn't doze happen after a significant period of time...may be an hour or so? – Gwin

If I use the debugger tools doze mode takes a few minutes, otherwise I see it happen at around the hour mark give or take a few minutes. – Kianakiang

Ok. One new issue I observed in Android 6.0 devices is related to the Power Saving mode. The users who were complaining of Audio stop within few minutes were on Power Saving mode. This is the issue I could also reproduce. In Lollipop devices, Power Saving mode didn't seem to stop the data, but in Marshmallow, it is a major problem. Just wanted to put to your notice, just in case you might not be aware – Gwin

Ah that's good to know, appreciate it @Gwin – Kianakiang

Answer 1

The recommended solution is to have separate processes, one for audio playback and for the UI. See this long thread for lots of details

Here's the relevant section from Ms Hackborn:

... have your foreground service run in a different process than the activity. From what I can see, this will work fine. I would be interesting in seeing if you get the desired behavior there.

Also this is actually our recommended practice for this situation -- if you have a long-running foreground service, it should be in a separate process from the activity, so it doesn't force all of the memory associated with the activity to be kept around. (This is also why this bug got through, all of our [Google] apps use this pattern.)

Toliver

Hi @Toliver thanks for the response. I've tried this but my app still loses wifi connection on 6.0 devices, but runs fine on pre-6.0 devices. – Kianakiang

Check out this thread on google fix for this. Maybe this is your situation? code.google.com/p/android/issues/detail?id=193802 – Toliver

Hi @Toliver i could see some suggested solution at the end of the thread "the best workaround I found is simply opening another foreground service with a wake lock in a separate process, this process has no activities, no receivers etc..This ensures the wake lock to be held" Has anyone tried this solution, and does it work? – Gwin

@Gwin Yes, I have tried this and in my limited testing it works well. When you bind to the service, make sure you use the BIND_AUTO_CREATE | BIND_IMPORTANT flags. This is really the same thing as my original post, the two-process solution, but it's a hack until the bug fix propagates in M MR1 and N. – Toliver