CODEWITHSUNDEEP
androidservice
stdout
stdout

Reputation: 2651

Service class onStartCommand() method's return value

I was re-reading the Service documentation and something drew my attention on the return values of the onStartCommand() method.

The thing is if you return START_NOT_STICKY for example, and if you have "pending start commands" the service is re-started if it'd be killed by the system. That's totally OK except one thing. What's the "pending start commands" here? More precisely, how there exist "pending start commands" since it's not possible to call startService() out of main thread?

The only thing comes to my mind is startService gets called and put into the tail of the main thread's (Looper's) event queue and before it gets executed, service is destroyed and leaves the event queue with "pending start command(s)".

Do you think am I totally lost or on the correct path?

Upvotes: 0

Views: 1286

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006944

One of the parameters passed to onStartCommand() is an int identifying this command (typically called startId). That startId can be passed to stopSelf(). Whereas the zero-parameter stopSelf() says "I am done with this service", the one-parameter stopSelf(int) says "I am done with this command and all commands that have preceded it".

So, suppose we have this series of events:

  • onStartCommand() called with a startId of 1
  • onStartCommand() called with a startId of 2
  • onStartCommand() called with a startId of 3
  • stopSelf() called with a startId of 2
  • the process is terminated

Here, if your return value from onStartCommand() has been START_STICKY or START_REDELIVER_INTENT, Android will start up your process again (when memory conditions improve), so that you can do whatever startId of 3 was.

START_NOT_STICKY says "if you terminate my process due to low memory conditions, and memory improves, that's OK, I'll stay dead, until there is some new command to process".

Upvotes: 3

Related Questions