7

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?

two1stnamz
  • 608
  • 1
  • 6
  • 18
  • 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? – user669231 Apr 22 '16 at 07:42
  • No solutions so far, will update if I do find one. Please do the same @user669231 – two1stnamz Apr 22 '16 at 19:16
  • 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? – user669231 Apr 25 '16 at 09:41
  • 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. – two1stnamz Apr 26 '16 at 12:25
  • 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 – user669231 Apr 27 '16 at 07:25
  • Ah that's good to know, appreciate it @user669231 – two1stnamz Apr 30 '16 at 01:04

1 Answers1

2

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.)

Community
  • 1
  • 1
dhaag23
  • 6,106
  • 37
  • 35
  • Hi @dhaag23 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. – two1stnamz May 05 '16 at 17:15
  • Check out this thread on google fix for this. Maybe this is your situation? https://code.google.com/p/android/issues/detail?id=193802 – dhaag23 May 05 '16 at 19:18
  • 1
    Hi @dhaag23 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? – user669231 May 22 '16 at 05:59
  • @user669231 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. – dhaag23 May 24 '16 at 18:34