3

I am working on an android app to play music.

So far I have returned START_STICKY from the onStartCommand of the Service responsible for playing the music without much thought becuase the tooltip in Eclipse states: "This mode makes sense for [...] a service performing background music playback".

The first thing this method does is looking in the intent what it is supposed to do (play, stop, next song, ...).

Recently when I killed the app while playing music (by dragging it out of the screen in the overview of recent apps) the app crashed. Looking in the log file I found that a NullPointerException was thrown when trying to access the intent in onStartCommand (after the Apllications's and Service's onCreate methods had been called).

My first reflex was to therefore insert at the beginning of the onStartCommand method:

if (intent == null){
    stopSelf();
    return START_NOT_STICKY;
}

But after reading the descriptions of START_STICKY and START_NOT_STICKY again I am wondering: Why would START_STICKY be recommended for a music player?

The way I understand it is that the difference between the two is that if a service started with START_STICKY is killed it will be restarted (then with intent=null). With START_NOT_STICKY the service will not be restarted (unless the user requests it), therefore it will always be called with an intent and I would not need to check whether it is null or not.

When the user kills the app it seems obvious to me that the service should not be restarted.

The other case I can think of where the service might be restarted is if the service had been killed by the system due to a lack of ressources. In that case, too, I don't think a user would want the music to unexpectedly start playing music just becuase some ressources became available.

The following two answers imply that the return code has no other meaning than whether the service should be restarted if the process was killed:

Why is START_STICKY recommended for a music player?

jakun
  • 624
  • 5
  • 13
  • playing music doesn't require a new service.Already a service is created when you use the mediaPlayer class – Sharath kumar Oct 04 '17 at 06:29
  • @Anonymous even if the music is supposed to keep running in the background while other apps are in the foreground? – jakun Oct 04 '17 at 06:43
  • Yes by default it wil be running in background..The music stops only when user clears the recent apps from the memory..for example like spotify – Sharath kumar Oct 04 '17 at 06:46
  • I tried MediaPlayer as @Anonymous points. However I don't think that is what the author asks. Jakun's question is why START_STICKY makes sense for music playback. Per the document, the service will be re-created with a null intent. So this means if we specify which music to play in the service via intent, the service won't work after re-created because the we cannot get the music to play with a null intent and, even if playing a fixed mp3, it will start from 0'00'' rather than where it stops when user clear the app from recent apps. So I have the same question too. – LiuWenbin_NO. Dec 15 '18 at 23:24

2 Answers2

1

START_STICKY- If the service is stopped due to low memory then service is recreated when sufficient memory is available, after it recovers from low memory. Here you will lose the results that might have computed before.

START_NOT_STICKY- If the service is stopped the system not to bother to restart the service, even when it has sufficient memory.

Also when user kills the app the service wont be stopped unless you stop the process by using some task killers.For more info on service check this link.

http://www.vogella.com/tutorials/AndroidServices/article.html

Sharath kumar
  • 4,064
  • 1
  • 14
  • 20
  • regarding the meaning of `START_STICKY` and `START_NOT_STICKY`: that looks very similar to what I have seen in the mentioned answers. I believe to understand the difference between the two. My question is: Why is START_STICKY recommended for a music player? – jakun Oct 04 '17 at 06:49
  • Ok coming to musicplayer advantage of creating service here is when the musicplayer application is killed and you have already created a song which is playing it wont be stopped.Using START_STICKY will ensure that if the service is killed by android system on gaining memory it restarts playing song but from the beginning but START_NOT_STICKY will not start the service again unless you manually go to application and play the song – Sharath kumar Oct 04 '17 at 06:57
  • regarding the killing of the app: I used a swipe to remove it from the list of recent apps which opens when long pressing the home button. Doing that, the music stopped playing immediately which is a clear sign to me that the service did stop. That the app crashed was after I returned to the home screen. – jakun Oct 04 '17 at 06:57
  • Yes thats what I said.Media player has a service which lets you hear song when you minimize the app and go to the other app also.But it gets killed when you clear app.If you check any sample music apps in playstore most of them have implemented this mechanism. – Sharath kumar Oct 04 '17 at 06:59
  • what you said "it wont be stopped" is that another difference between START_STICKY and START_NOT_STICKY? to which situation are you refering (the user killing the app or the operating system killing the app - is there even a difference)? – jakun Oct 04 '17 at 07:25
  • user killing the app this means app is killed but service will run in background.operation system kills the app also sometimes the running processes. – Sharath kumar Oct 04 '17 at 08:43
  • I think my Comments are more than answer..If you found my answer helpful please dont forget to accept it. – Sharath kumar Oct 04 '17 at 08:45
  • well, to be honest... I really appreciate that you are trying to help but your answer is mainly a duplicate of the answers I have linked in my question and your comments seem contradictory. On the one hand you are saying "it wont be stopped" and "app is killed but service will run in background" (which does not seem to be what is happening) and on the other hand you are saying "it gets killed when you clear app". – jakun Oct 04 '17 at 09:41
  • If you would say "a service started with START_STICKY is less likely to be killed by android than a service started with START_NOT_STICKY", that would answer my question but from all I have read so far that does not seem to be the case. Or if you would say "I as a user would want the app to suddenly start playing at some random time after it got killed by the operatirng system", that, too, would answer my question, but I can not believe that is the case. – jakun Oct 04 '17 at 09:46
0

int START_STICKY: Constant to return from onStartCommand(Intent, int, int): if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service. Because it is in the started state, it will guarantee to call onStartCommand(Intent, int, int) after creating the new service instance; if there are not any pending start commands to be delivered to the service, it will be called with a null intent object, so you must take care to check for this.This mode makes sense for things that will be explicitly started and stopped to run for arbitrary periods of time, such as a service performing background music playback.

so it is self-exolanatory refer this STICKY SERVICE

Hardik Mehta
  • 867
  • 1
  • 12
  • 20
  • What does that mean "leave it in the started state" "if this service's process is killed"? It sounds to me like the service should continue running but that does not seem the case. When I kill the app the music stops (immediately, before the app crashes). – jakun Oct 04 '17 at 07:36
  • Why should the service be restarted? I can not really imagine a user would want a device all of a sudden to start playing music (even if it was not him but the operating system which stopped the app at some time). – jakun Oct 04 '17 at 07:38
  • @jakun probably you have set an attribute in manifest Stopwithtask to true so that is why when you kill the app service stops.it will not suddenly start playing automatically you have control to stop service. – Hardik Mehta Oct 04 '17 at 07:45
  • no, in the manifest I am merely setting two attributes: android:name and android:enabled="true". No Stopwithtask. – jakun Oct 04 '17 at 09:16
  • sure, when the service restarts I could stop the service as described in my question. But then, why should I tell android that the service is suppossed to be restarted in the first place? – jakun Oct 04 '17 at 09:18
  • @jakun it is not we are telling Android to restart service it is START_STICKY which causes services to restart if it gets killed after started state. – Hardik Mehta Oct 04 '17 at 10:45
  • I mean, by returning START_STICKY we are telling android that the service is supposed to be restarted if it gets killed. So why not returning START_NOT_STICKY? – jakun Oct 05 '17 at 09:22
  • @jakun yes if your requirement is like that (i.e not to start service) then you can use that. – Hardik Mehta Oct 05 '17 at 09:40