I have an app that plays audio streamed from a server (or locally).
According to what we've seen*, if playing audio through a background Service, the audio will keep playing. However, some users report that the audio will stop when their device goes to sleep. I haven't seen any documentation on audio behaviour while sleeping, definitely the API docs don't mention anything: http://developer.android.com/reference/android/media/MediaPlayer.html . Are there any guarantees that the MediaPlayer will continue playing while sleeping, and if not, should I enable the WAKE_LOCK while playing?
*(and this question seems to support it: Playing music in sleep/standby mode in Android 2.3.3)
I don't think setting the wake lock will matter, in my experience it has nothing to do with keeping a service alive. The Android Service documentation states that services that don't use the startForground() method can be killed to free up memory. It's likely the service is either being killed to free up resources or an exception is causing it to silently crash.
If you app goes into the background, it can be killed by the OS. This is most likely what is happening. You can reduce the chance of this happening greatly by making your Service a foreground service by using startForeground(). A wake lock will not help. Under intense memory strain, your foreground service may be killed, but this is very unlikely when the phone is asleep.
Related
I am just clearing up my Android doubts. So lets talk about Services, we use services when we have to perform an operation in the background. Lets say Playing Music in the background? Thats one of the most popular reasons why people use Services.
But i just used Mediaplayer in my Mainactivity and i used .start() method in onCreate of my activity. I then minimized the app, but guess what....music still plays. I open the app again, and the music is still playing. I then remove the app from recent apps, basically destroying it and the music stops. Basically the app performs how it is supposed to. Works PERFECT!
Then why do we use services at all for these kind of tasks?
Is there any scenario this code might create a problem? Or is this creating some memory leak or something?
When "minimized" the App continues to play music due to OS delay which allow an User to re-open the App without delay (due to a closure mistake?) because all remained in memory (even the Music) in the previous state.
But the memory is limited, and the CPU the same, so the OS could kill or freeze (using Doze) a background Activity in any moment without prompt User/Developer.
An Activity could be killed to claim Memory or freezed to save CPU cycles. In this situation only explicitely declared Background Services are allowed to run (however with some limitations and special-behaviours), so if you don't use Service your Music could stop in any moment in the future.
PS: even Background Service could be killed from OS, but this case is very-very rare and only on Extreme Low Memory situations.
It will play as long as Android lets it live. It may stop at any moment, usually after 10-20 minutes.
Consider using Foreground Service to playback music. It will last until user kills it, and also provides notification bar with control over the playback.
I'm building a music streaming app for Android.
In this app, I have a Service which is responsible for playing audio from an HTTP server. Before playing, I make sure to startForeground() and acquire a partial WakeLock, so that my service isn't killed. I also get a WifiLock, just in case.
The service works fine... as long as my phone isn't on "battery saving mode". The minute I turn on battery saving and disconnect my phone from power source, my service is killed with fire!
Unfortunately it doesn't even seem that onDestroy() is called, so my notification from startForeground() stays visible, even if the service is dead.
The phone is a Samsung Galaxy S6, with Android 6.0.1 on it.
Two questions:
Is there a way I can keep the service alive despite the battery saver thingy?
If not, I'd like to know at least when my service is killed, so that I can do a bit of cleanup (remove notification & internal stuff).
Any suggestions?
This is possible by using a foreground service in a separate process holding a partial wakelock.
android:process="process_name"
(documentation: http://developer.android.com/guide/topics/manifest/service-element.html)
Note that you shouldn't use SharedPreferences in a multi-process environment.
See also this issue: https://code.google.com/p/android/issues/detail?id=193802
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?
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.)
I have implemented Android Speech Recognition as a service on Android 4.1 & 4.2 recognition solution in my application, with some minor modification(e.g: 1500ms countdown, mute beep), which works basically fine.
I would like to run this service for hours. I tested a lot this solution and i experienced unexpected stops.
The recognition is running in the background, notification icon is displayed, which indicates, when the recognition service is on. After 10-15 minutes continuous listening without any exception the whole applications stops. (But it happened, after 8 recognition periods as well, after 30 secs.) When it happens, I was able to trace one thing, one more time the thread enters the extended Application class' onCreate() method, where the logs are printed out, but nothing else works. The displayed notification can't be removed.
I don't have leak related exception during listening or any suspicious log message.
Is anyone experienced similar stops? Is anyone has any idea why it happens?
I've tried to restart the service after every 20th (handler) starts to avoid this behaviour, so the service is not running for that long. But the situation is the same.
If you have any suggestion what are the possibilities to run the service for many hours, please share.
BEFORE READING THE FIX BELOW, PLEASE BE AWARE THAT
Keeping a service on for a long time and not allowing the system to kill is a bad idea. The phone has limited battery and the Service runs even when is sleep mode.
Android will kill different services based on the memory state, so on devices with more memory it might not stop. But make it not stop you need to tell the OS that your service is important and, quote from android reference, it can't "be killed without too much harm". To tell the system that you want your service when it can be killed and when it cannot, take a look at startForeground and stopForeground methods, described below.
Start Foreground
It makes the service run in the foreground, making the system prefer to kill other services other than yours to free memory. But, even if you use this method, it is not guaranteed that your service will not stop. It may stop if the phone is on very low memory. Also:
You can set this flag if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.
Stop foreground
Remove this service from foreground state, allowing it to be killed if more memory is needed.
Links to documentations:
Start Foreground method
Stop Foreground method
i'm building app for listening to acc stream. I m using this library:
https://code.google.com/p/aacdecoder-android/
Especially this player.
PlayerCallback clb = new PlayerCallback() { ... };
MultiPlayer aacMp3Player = new MultiPlayer( clb );
aacMp3Player.playAsync( "http://..." ); // URL of MP3 or AAC stream
It's playing in AsyncTask, but for some smarphones when you put app to backround playing just stop.
Only in methond onDestroy i'm stopping AsyncTask, not in onPause or oStop.
Anyone have an idea why player stops?
Short answer: Music streaming apps need to have a Service running to avoid being terminated by Android.
On a cheaper device or when memory resources run low, Android will simply terminate processes as soon as they go into the background or when more memory is needed. This likely explains why it only happens on "some smartphones" as you mentioned. You can also go into the Developer Options on your phone and play with the "Don't Keep Activities" and "Background process limit" settings to simulate the same thing.
You can read more about how Android prioritizes processes and activities for termination when they are not the active app in the foreground at this link here. You'll read that Services are at higher priority for being kept around than background processes (e.g. Activities that the user exited from, but still have a running thread).
On my music streaming app, when music starts, I start a service (same process as the Activity) and add my app's Main Activity to the Notification area. When the user stops the music, I stop the service and remove the app from the notification area. You'll likely notice very similar behavior between the NPR App, Spotify, i-heart-radio, and others.