68

I am unable to understand

  1. START_STICKY,
  2. START_NOT_STICKY and
  3. START_REDELIVER_INTENT

Can anyone explain clearly with examples.

I went through this link but couldn't understand it clearly.

CopsOnRoad
  • 237,138
  • 77
  • 654
  • 440
Kittu Rajan
  • 775
  • 1
  • 9
  • 7

3 Answers3

137

These are related to services. We all know that services keeps on running in the background and they also consume some memory to execute.

So, as more of the application runs on android device, the device memory keeps on getting low and when the time arises, when the device memory gets critically low, the android system starts terminating processes, so as to release the memory occupied by the processes.

But you might be doing some important task with the services, that could also get terminated as the service stops. so these concepts are to tell the android system what action you want to perform when the device memory gets stable and when it is ready to relaunch the services.

The simplest explanation of these could be,

START_STICKY- tells the system to create a fresh copy of the service, 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- tells the system not to bother to restart the service, even when it has sufficient memory.

START_REDELIVER_INTENT- tells the system to restart the service after the crash and also redeliver the intents that were present at the time of crash.

Goran Horia Mihail
  • 3,536
  • 2
  • 29
  • 40
Sahil Mahajan Mj
  • 11,033
  • 8
  • 53
  • 100
  • Does the return code (e.g. START_STICKY or START_NOT_STICKY) have any influence on how Android selects services to be killed? – jmng Jun 04 '14 at 10:23
  • 1
    @derelict : No, It has nothing to deal with *How android selects services to be killed*. Whenever the android system gets low on memory, it will start calling **onDestroy()** method of the services. These intents(return code) are only useful when the system recovers and has enough memory to start the services again. – Sahil Mahajan Mj Jun 05 '14 at 06:00
  • @SahilMahajanMj, OK, just checking. BTW, there's no guarantee that the service's onDestroy() will be called when the system runs out of memory. – jmng Jul 03 '14 at 16:12
  • Best explanation ever! – Mr.Noob Dec 03 '15 at 11:40
8

Well, I read the thread in your link, and it says it all.

if your service is killed by Android due to low memory, and Android clears some memory, then...

  1. STICKY: ...Android will restart your service, because that particular flag is set.
  2. NOT_STICKY: ...Android will not care about starting again, because the flag tells Android it shouldn't bother.
  3. REDELIVER_INTENT: ...Android will restart the service AND redeliver the same intent to onStartCommand() of the service, because, again, of the flag.
stealthjong
  • 10,858
  • 13
  • 45
  • 84
7

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 redelivery the same intent to onStartCommand().

This article by Dianne Hackborn explained the background of this a lot better then the official documentation.

Source: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

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.

Sazzad Hissain Khan
  • 37,929
  • 33
  • 189
  • 256
  • 2
    From last paragraph, I don't agree that `START_REDELIVER_INTENT` is like `START_NOT_STICKY`. Instead it is like `START_STICKY` – CopsOnRoad Feb 04 '18 at 09:16