(1)START_NOT_STICKY
If the system kills the service after onStartCommand() returns, do not recreate the service, unless there are pending intents to deliver.
This is the safest option to avoid running your service when not necessary and when your application can simply restart any unfinished jobs.
(2)START_STICKY
If the system kills the service after onStartCommand() returns, recreate the service and callonStartCommand(), but do not redeliver the last intent.
Instead, the system calls onStartCommand() with a null intent, unless there were pending intents to start the service, in which case, those intents
are delivered. This is suitable for media players (or similar services) that are not executing commands, but running indefinitely and waiting for a job.
(3)START_REDELIVER_INTENT
If the system kills the service after onStartCommand() returns, recreate the service and call onStartCommand()with the last intent that was delivered
to the service. Any pending intents are delivered in turn. This is suitable for services that are actively performing a job that should be immediately
resumed, such as downloading a file.
public static final int START_NOT_STICKY
This mode makes sense for things that want to do some work as a result of being started, but can be stopped when under memory pressure and will
explicit start themselves again later to do more work. An example of such a service would be one that polls for data from a server: it could schedule an alarm
to poll every N minutes by having the alarm start its service. When its onStartCommand(Intent, int, int) is called from the alarm, it schedules a new alarm for
N minutes later, and spawns a thread to do its networking. If its process is killed while doing that check, the service will not be restarted until the alarm goes off.
public static final int START_STICKY
If this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)),then leave it in the started state but don't retain this
delivered intent. Later the system will try to re-create the service. Because it is in the started state, it will guarantee to call onStartCommand(Intent, int, int) after
creating the new service instance; if there are not any pending start commands to be delivered to the service, it will be called with a null intent object, so you must
take care to check for this.
This mode makes sense for things that will be explicitly started and stopped to run for arbitrary periods of time, such as a service performing background music playback.