Service#onstartcommand return value resolution

Service#onstartcommand return value resolution

ServiceClass has a life-cycle method called onStartCommand , and each start-up service (StartService) will callback this method. The prototype of this method is as follows:

public int Onstartcommand (Intent Intent, int flags, int startid)

It is interesting to note that this method has an integer return value, which has the following options:

START_STICKY_COMPATIBILITYSTART_STICKYSTART_NOT_STICKYSTART_REDELIVER_INTENT

So what are the effects of these kinds of return values?

By reading the documentation, I found that they would affect the behavior of restarting 服务异常终止 the service in the case, by default, when our service is aborted due to system memory tightness or other reasons, the system will attempt to restart the service at some point, if the Service#onStartCommand method returns

1. Start_not_sticky:
   The service will not be re-created unless you callstartService

2. Start_sticky/start_sticky_compatibility:
   The service re-creates and starts, callback Oncreate,onstartcommand, but if no new intent is passed to the service, the onStartCommand accepted will be an empty one intent .
   Start_sticky_compatibility is a compatible version of Start_sticky, which is used under 2.0, it does not guarantee a certain call onStartCommand .

3. Start_redeliver_intent:
   The service is re-created and started, callback Oncreate,onstartcommand in turn, and the last pass to the service is intent sent again onStartCommand .

System default Policy

Onstartcommand Policy for service:

publicintonStartCommandintint startId) {      onStart(intent, startId);      return mStartCompatibility ? START_STICKY_COMPATIBILITY : START_STICKY;  }

Visible, the default policy is Start_sticky, and the support service terminates the re-creation unexpectedly.

Intentservice Implementation strategy:
IntentServiceShould not be re onStartCommand -implemented, but to replicate onHandleIntent .

@Override public int onStartCommand(Intent intent, int flags, int startId) { onStart(intent, startId); return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY; } public void setIntentRedelivery(boolean enabled) { mRedelivery = enabled; }

It is visible that IntentService only two return values are supported by default, START_REDELIVER_INTENT START_NOT_STICKY and setIntentRedelivery are determined by the method and are START_NOT_STICKY not recreated by default.

Test:

Test machine: nexus5,android6.0

Note: The Kill service here simulates a situation where the services were accidentally killed, where I use the Nexus
close background appsfunction, that is, click the menu button to slide the app to start. Because this practice is a life-cycle approach that kills the service by the system and therefore does not callback serviceonDestroy

1. Onstartcommand return Service.start_sticky

   • Kill Service:

   The service restarts, re-executes, onCreate and the onStartCommand method, noting that onStartCommand when the reboot intent is null executed, the parameters will be
   

   • Stop Service:

   Execute only onDestroy and do not restart the service
   

2. Onstartcommand return Service.start_not_sticky

   • Kill Service:

   Service does not restart
   

   • Stop Service:

   Execute only onDestroy and do not restart the service
   

3. Onstartcommand return service.start_redeliver_intent

   • Kill Service:

   The service restarts, re-executes, onCreate and onStartCommand methods, noting that when the reboot is performed, the onStartCommand intent parameters are not null , that is, the previous intent is sent again.
   

   • Stop Service:

   Execute only onDestroy and do not restart the service
   

Service#onstartcommand return value resolution