If you return START_STICKY
, the documentation says:
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.
If, instead of START_STICKY
, you return START_REDELIVER_INTENT
, the documentation says:
if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), then it will be scheduled for a restart and the last delivered Intent re-delivered to it again via onStartCommand(Intent, int, int). This Intent will remain scheduled for redelivery until the service calls stopSelf(int) with the start ID provided to onStartCommand(Intent, int, int). The service will not receive a onStartCommand(Intent, int, int) call with a null Intent because it will will only be re-started if it is not finished processing all Intents sent to it (and any such pending events will be delivered at the point of restart).
So, it sounds to me like you either need to return START_STICKY
and understand that on a restart onStartCommand()
will be called with a null Intent
object or you need to return START_REDELIVER_INTENT
and understand that if your service is not currently executing the onStartCommand()
method when it is killed that it won't be restarted at all.
If you need to save the most recent value of myString
, you can write this to shared preferences.