Start_Sticky and Start_Not_Sticky

What is START_STICKY,START_NOT_STICKY and START_REDELIVER_INTENT Service

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.

Must be one of: Service.START_STICKY_COMPATIBILITY, Service.START_STICKY, Service.START_NOT_STICKY, Service.START_REDELIVER_INTENT

If you meant to return START_STICKY, which is of type int equal to 1, from onStartCommand(...), you did nothing wrong. This is your IDE that prompts it.

You can ignore the warning. In case of absence of other errors, your code will compile and run successfully.

If the warning is annoying, return START_STICKY instead.

android service START_STICKY START_NOT_STICKY

you will want to set a BOOT receiver which starts your Service ALARM (which will wake up intermittently and make sure your Service is running) when the device boots. The ALARM receiver should wakes up every minute (or so) to see that your Service hasn't been cleaned up by Android (which will happen from time to time).

[EDIT]

You'll want a BootReceiver to start your alarm that will look like this:

public class BootReceiver extends BroadcastReceiver {
    @Override
       public void onReceive(Context context, Intent intent) {

          AlarmManager alarmMgr = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
          PendingIntent pendingIntent =
                   PendingIntent.getBroadcast(context, 0, new Intent(context, AlarmReceiver.class), 0);

          alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 2000,  60000, pendingIntent);
       }
    }

And an alarmReceiver would look like this:

public class AlarmReceiver extends BroadcastReceiver {
    private String TAG = "AlarmReceiver";
   // onReceive must be very quick and not block, so it just fires up a Service
   @Override
   public void onReceive(Context context, Intent intent) {     
      Intent i = new Intent(context, MyLovelyService.class);      
      PendingIntent.getService(context, 0,i, 0).send();    
   }
}

and lastly this needs to go into your manifest:

<receiver android:name=".BootReceiver">
  <intent-filter>
     <action android:name="android.intent.action.BOOT_COMPLETED" />
  </intent-filter>
 </receiver>

 <receiver android:name=".AlarmReceiver" />

How to setup START_STICKY in service

All you need to do is return the START_STICKY flag in the onStartCommand() method:

@Override
public int onStartCommand (Intent intent, int flags, int startId){

    // several lines of awesome code

    return START_STICKY;
}

Further considerations:

If you use a Service without overriding onStartCommand(), it returns START_STICKY by default, although normally the code run by a Service is put in the onStartCommand() method.

That's it. You're done, go home.

About START_STICKY in Service

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.

And answer for your query is the service only recreate if it's killed by the OS in any circumstances when working with START_STICKY. if we were terminating the service why android need to reproduce it again.if your using stopSelf() the service does not recreate even it is sticky.

---

Related Topics