service는 stopSelf(), stopService()가 호출되지 않는 이상 멈추지 않는다. 혹 OS에 의해서 잠시 멈춰질수 있으나 다시 service를 작동할 환경이 되면 다시 시작된다. 어떤 이유에서건 멈추어진 command 는 onStartcommand에서 지정된 flag – START_NOT_STICKY, START_REDELIVER_INVENT, START_STICKY- 에 따라서 다시 시작되기도 하고 아니기도 하게 된다.
service는 lifecycle을 가진다. onCreate(), onStartCommnad( 인텐트obj, 플래그정수, 스타트id ), onDestroy()
START_STICKY and START_NON_STICKY and START_REDELIVER_INTENT
Both codes are only relevant when the phone runs out of memory and kills the service before it finishes executing.
START_STICKY tells the OS to recreate the service after it has enough memory and call
onStartCommand() again with a null intent.
START_NOT_STICKY tells the OS to not bother recreating the service again. There is also a third code
START_REDELIVER_INTENT that tells the OS to recreate the service and redeliver the same intent to
This article by Dianne Hackborn explained the background of this a lot better than the official documentation.
The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:
START_STICKY is basically the same as the previous behavior, where the service is left “started” and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.
START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.
START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service’s process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can’t complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.
from big nerd android programming p484
START_NON_STICKY service는 stopSelf() 또는 stopSelf( 스타트id인티저 ) 를 통해 멈추어질수 있다. 작업중 os에의해 갑자기 멈추어진 경우 service는 사라진다. IntentService가 대표적 START_NON_STICKY service이다.
START_REDELIVE_INTENT service는 stopSelf() 또는 stopSelf( 스타트id인티저 ) 를 통해 멈추어질수 있다. 작업중 os에의해 갑자기 멈추어진 경우 본래 가지고 있던 intent를 이용 나중에 다시 작업한다.
START_STICKY service 는 stopService( 인텐트obj ) 를 통해 정지할수 있다. 작업중 os에의해 갑자기 멈추어진 경우 null intent를 이용 나중에 다시 작업한다.