Hi. I am developing an alarm app. My app plays white noise to help users get into sleep properly. To keep white noise playing in the background, my app uses audio background mode. The problem is that my app sometimes gets suspended few hours after getting into background. I cannot find the exact reason for it.
Doesn't audio background guarantee that app is not suspended by system? Then how can I handle this issue so that my app can keep white noise playing feature?
Doesn't audio background guarantee that app is not suspended by system?
Strictly speaking, no. The "audio" background category allows your app to remain awake while your audio session is active, which isn't quite the same as guaranteeing it will not be suspended.
Next a quick note here:
The problem is that my app sometimes gets suspended few hours after getting into background. I cannot find the exact reason for it.
How are you finding out about this problem? Is it:
You're able to directly reproduce it.
Users are complaining about it.
You have log data showing that it's occurring.
The last kind of data (#3) is the case you need to be very careful about. I've seen many cases where a developer identified a "problem" based on log data then spent a great deal of time and worry investigating it, only to eventually discover that... nothing was actually going wrong. Logging only shows your apps "side" of an issue, which means you can't really tell the difference between cases like "the system stopped playing me" and "the user decided to listen to something else" or "the battery died". This may not apply to your case, but it's something you should keep in mind.
Then how can I handle this issue so that my app can keep white noise playing feature?
The basic question here is why did your app suspend, but that's a question you'd need to answer through testing and experimentation. However, off the top of my head, here are the most likely causes:
An interruption occurred and your app didn't correctly resume playback when the interruption ended.
At some point, your app stopped playing audio (went silent) for "to long", so the system triggered an interruption and never resumed.
The system terminated your app for some form of "maintenance". Notably, apps need to be terminated to clear out their tmp/Caches directories. Also, make sure you've minimized your overall memory usage. Processing tasks running overnight can cause memory usage to spike up, which can be a problem if your app is using "large" amounts of memory.
The device rebooted for some reason (for example, a system update).
Across all of these issues, one big decision you need to make is whether or not your app should become the "Now Playing" app or use a mixable audio session. Both options have positives/negatives:
Now Playing means that the user can use the lock screen/remote events to resume playback. That simplifies recovering from the cases above that simply can't be avoided.
As long as it's background memory usage is "reasonable" (my guidance is <100 MB), the Now Playing app is generally safe from memory termination.
Being mixable means that other kinds of audio (like a music app or podcast player) can play as well.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
I've found this issue from several reports from users. Sometimes it also occurs on my phone too, though I don't know the exact method to replicate it.
It seems that while sleeping, not only my app but other background apps also get suspended together. Investigating users' screenshots of system settings-battery page, every 'Screen Idle' app gets suspended at some point (mostly while sleeping) and audio stops after that.
The app is using mixable audio mode since some users want to listen to music simultaneously. Therefore, I am not going to use 'Now playing' as you mentioned. @DTS Engineer
Hi,
So, let me start here:
It seems that while sleeping, not only my app but other background apps also get suspended together. Investigating users' screenshots of system settings-battery page, every 'Screen Idle' app gets suspended at some point (mostly while sleeping) and audio stops after that.
The thing to understand here is that what you're describing is a relatively high level "user issue" ("Audio stopped playing"), not what actually occurred on the device. At a high leve, all three of these cases will look exactly the same ("audio stopped"):
The device rebooted to install an update.
The app was killed to install an app update.
The app was interrupted and failed to resume properly.
...but #3 is the only one that your app can really address.
That does lead me to a follow up question on this point:
The problem is that my app sometimes gets suspended
Do you specifically KNOW that your app was suspended (not terminated)? It's easy to be imprecise about terminology but the distinction is important here. There are lots of reasons an app might stop running "overnight" but most of what the system does would specifically mean that it terminated the app entirely, not just suspended it.
Moving to here:
I've found this issue from several reports from users. Sometimes it also occurs on my phone too, though I don't know the exact method to replicate it.
If you want to dig into this "in depth", then you basically need two things:
A sysdiagnose that cover the time the failure was taken, ideally without a user reboot having occurred since the problem happened.
(ideally) Log data from your app so you can determine when the failure actually happened.
If you have #2, then this is basically a matter of opening up the console log (from inside #1), finding that time in the log, then reading through the log to see "what happened". The system generates pretty clear logging for app suspension/termination and you'll also be able to see it "reacting" if your app crashes. Without #2, some investigation is still possible, but it's more work since you'll be looking at much larger time window trying to find a specific failure.
The app is using mixable audio mode since some users want to listen to music simultaneously. Therefore, I am not going to use 'Now playing' as you mentioned.
OK.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware