21

I am creating a service for my android app, providing data to the service via Intents. The problem is that when the service is destroyed by the system than the intent data provided to it can't be restored, as a result of which my app crashes.

I have heard START_REDELIVER_INTENT will restart my service as soon as there is sufficient memory available restoring the intent data provided to service whereas the START_STICKY will not restore the intent data.

am i right ? or is there something I don't know ?

Also my service is taking forever to restart after it is destroyed by the system.

enter image description here

1
  • Why is it stopped by your system in the first place? Is your device low on memory? Commented Mar 2, 2015 at 21:43

2 Answers 2

30

START_STICKY- It will tell the system to create a newest copy of the service, when available memory is sufficient to do, after it retains state and recovers from the low memory. In this process we will loose the results that might have calculated before.

START_REDELIVER_INTENT- It will tell the system to restart and regain the service after the crash and also redeliver the intents that were present at the time of crash happened.

beside this we can have also a little note about START_NOT_STICKY

START_NOT_STICKY- It will tell the system not to worry and bother about to restart the service, even when it is having sufficient available memory.

please visit for more

http://developer.android.com/reference/android/app/Service.html

3
  • 1
    will making the service foreground keeps away from killing the service (except extreme OOM!) ?
    – nmxprime
    Commented Feb 27, 2014 at 4:17
  • 1
    It depends how you used,Foreground services can still be killed please visit stackoverflow.com/questions/6619143/… Commented Feb 27, 2014 at 4:19
  • I think it would be really clear also if some of you guys explain why the heck name it as STICK and NOT STICKY? At least REDELIVER_INTENT is very intuitive to make sense of, but the other two? Not so much. Why is it called stick and not sticky?
    – nww04
    Commented Nov 6, 2016 at 5:49
-2

If you are overriding onstartCommand() method, its your responsibility to stop it when not needed by calling stopSelf() or stopService() command.

3
  • Really though, you don't HAVE to stop it.
    – Clocker
    Commented Apr 6, 2017 at 3:44
  • @Clocker you have to call stopSelf() or stopService() to destroy the service, otherwise it's instance will be alive in the memory even if it isn't running.
    – CopsOnRoad
    Commented Feb 4, 2018 at 9:18
  • old thread but @Jack Oreo now calls stopSelf() for you if your app is no longer in the foreground.
    – Clocker
    Commented Feb 4, 2018 at 19:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.