Develop Reference

What can I expect when onCreate() calls startService()

I am trying to understand the Service Life Cycle while working through some Android Open Source Code.
I was looking at a Service implementation which I distilled down to something like the following...
public class MyService extends Service {
public MyService() { super(); }
#Override
public void onCreate() {
super.onCreate();
init();
//==this seems odd to me
//comment in AOSP says startService() is called to make
//sure Service stays around long enough for the async call
//to complete.
startService(new Intent(this, myservice.class()));
doSomeMoreInitAsync();
}
#Override
public int onStartCommand(final Intent intent, final int flags, final int startId) {
if(actionableIntent(intent,flags,startId)) {
//do something
//NOTE: the Intent passed to startService() in onCreate()
//above will go around this block of code, doing nothing
//except returning START_STICKY
}
return START_STICKY;
}
public void onDestroy() {
//destroy stuff
}
#Override
public IBinder onBind(final Intent intent) {
return mBinder; //an instance of android.os.Binder derivative
// created when this service was instantiated
}
//other stuff
}
Why would someone want to have onCreate() call startService() on itself like above, doing nothing? The comment in code sheds some light, but it's like assumptions are being made about the Life Cycle that I don't understand. I.e., is it reasonable to expect onCreate() to effectively start its own service?
I know that if a service has already been started then onCreate() will only be called once (unless destroyed and restarted, then a new instance of the service is created and onCreate() is called once on it). My first concern with this example would be that there is an expectation placed upon the underlying Service API implementation that the Service is already in the initialized state before onCreate() is called (else there be an infinite recursion, but there is not).
But isn't onCreate() supposed to be part of the initialization (albeit an optional part for the subclass)?
Is this coding logic a reasonable way of making sure the Service is forced to be an Unbounded Service? Or am I looking at a bad example in the AOSP which may have undefined behavior in the future?

You are correct in that a Service will call onCreate and onStartCommand if it is started via Context.startService. So in this sense, when you return START_STICKY, the Service will continually run until an explicit call to stopService() is called. It will also be destroyed and restarted during this lifecycle.
Another way to create a Service, is by binding to it. As per the docs:
Clients can also use Context.bindService() to obtain a persistent connection to a service. This likewise creates the service if it is not already running (calling onCreate() while doing so), but does not call onStartCommand().
So, it's possible for a Service to be created by simply binding to it. However, the lifecycle of a Service indicates that it will remain if it is started or a client is still bound to it. Meaning, that if it was created by a bind command, it will immediately be destroyed as soon as the client unbinds.
So, if a Service starts itself in the onCreate(), it will ensure that it puts itself in the started state regardless of whether it was created by binding or by an explicit call to startService. Since there's no actionable intent, the onStartCommand will just pass straight through. An clients that call startSevice will, presumably, have actionable Intents in which case the Service will perform its duties.

When is onStartCommand of a service executed

When is onStartCommand of a service exactly executed?
In the following code my service is started from the onCreate in my activity
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Intent intent = new Intent(this, CenseDroidService.class);
//onStartCommand is not extecuted immediatly after startService
startService(intent);
bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
}
So when does the Android system decide to call onStartCommand? All that I know is that is runs on the main thread some time after calling startService. The onCreate is fully executed before onStartCommand is called.

From the documentation.
Called by the system every time a client explicitly starts the service by calling startService(Intent), providing the arguments it supplied and a unique integer token representing the start request
What this means is, every time you call startService(intent) with an Intent, then onStartCommand will be called. If you have a hundred Activities that all need to start and bind to this service, then they will all call startService() and onStartCommand will be called.
Now when it is exactly called is a bit trickier to answer. It is sometime in the future which is why your ServiceConnection works asynchronously. Most likely it can be within the next UI Thread cycle, but it is not something you should rely on.
If you need a reasonable knowledge of when the Service started, you could use the LocalBroadcastManager to broadcast the event to all registered listeners. The LocalBroadcastManager#sendBroadcastSync will actually block until all listeners respond so it may be useful for this scenario.

Android the difference between onHandleIntent & onStartCommand

I am currently writing a android program which needs an IntentService. When I put the code in the onHandleIntent function, the code does not run, but it doesn't give errors in the MainActivity. But when I copy my code into the onStartCommand, it runs perfectly.
The problem is that I wanna know what are the differences between onHandleIntent and onStartCommand. Thanks.
CODE:
In onHandleIntent:
System.out.println("SERVICE STARTED! ! !");
//System.out.println(intent.getBooleanExtra("once", Boolean.FALSE));
if (intent.getBooleanExtra("once", Boolean.FALSE)) {
Check();
}
mHandler.postDelayed(mRunnable, 3000);

As from the docs:
The IntentService does the following:
Creates a default worker thread that executes all intents delivered to onStartCommand() separate from your application's main thread.
Creates a work queue that passes one intent at a time to your onHandleIntent() implementation, so you never have to worry about
multi-threading.
Stops the service after all start requests have been handled, so you never have to call stopSelf().
Provides default implementation of onBind() that returns null.
Provides a default implementation of onStartCommand() that sends the intent to the work queue and then to your onHandleIntent()
implementation.
And also:
All this adds up to the fact that all you need to do is implement
onHandleIntent() to do the work provided by the client. (Though, you
also need to provide a small constructor for the service.)
So an IntentService is a "Custom" Service with those special properties. So there's no need to override the onStartCommand(), actually, you shouldn't do it unless you're using the regular Service class.
Some example of IntentService usage:
Activity.java
Intent it = new Intent(getApplicationContext(), YourIntentService.class);
it.putExtra("Key", "Value");
startService(it);
YourIntentService.java
public YourIntentService() {
super("YourIntentService");
}
#Override
protected void onHandleIntent(Intent intent) {
if (intent != null) {
String str = intent.getStringExtra("key");
// Do whatever you need to do here.
}
//...
}
You can also check this tutorial or this one for more info about Service and IntentService.
Also, check the docs.

onStartCommand() is used when you use a Service. onHandleIntent() should be used instead when you use an IntentService. IntentService extends Service. And as per documentation
"You should not override this method(onStartCommand) for your
IntentService. Instead, override onHandleIntent(Intent), which the
system calls when the IntentService receives a start request."
If you have overridden onStartCommand(), that might be why your onHandleIntent() is not getting called.

You should not override onStartCommand() for your IntentService.
If you do, make sure to return super.onStartCommand(); because that sends the Intent to the work queue and then to your onHandleIntent() implementation.

Service notification when an activity is killed

My application has an activity and a service running in the same process. When the user terminates the activity by clicking the STOP button, the activity causes the service to terminate.
From the Android documentation I understand that the system can kill a process to reclaim resources:
"Once your activity is stopped, the system might destroy the instance if it needs to recover system memory. In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback, ..."
Question 1: Is it possible for my activity to be killed but not the service? I would prefer my service remain alive.
If the answer is 'yes' then
Question 2: Is there a mechanism where the service can be notified that the activity has been killed?
IBinder.linkToDeath has the functionality I need but seems to apply to a process, not an activity.
I've thought of an indirect method like having the activity take ownership of semaphore and having the service use a thread to wait on it. Then when the activity gets killed it will release the semaphore and the service will get it, providing the notification. But I was wondering if there wasn't an android-centric technique I could use.
[begin edit]
After reading the very helpful comments you've provided I'd like to clarify the scenario I'm presenting.
I've started two components: an activity and a service. The application is configured so that service can continue to run after the activity has stopped and been destroyed. The user can restart/start the activity multiple times and it will use the same instance of the service.
Normally the activity will notify the service it has been destroyed during onDestroy(). But onDestroy() may not be called.
I'd like to know whether there is some android-specific mechanism I can use to notify the service that the activity has been killed without the call to its onDestroy() method having been made.
[end edit]
Thanks for your help.
Will

As I said before, single activity won't be killed by android without calling onDestroy(). If Android needs more memory it kills whole process(with all activities and services). Here is description, documentation is wrong about this.
Service can be also created in other process but it has to be set int the manifest. And then you can use iBinder to get notification when process(with all activities) is killed by Android

Yes services and activities can run independently of each other.
To achieve what you're trying to do I would explicitly start your service using startService() in your activity's onStart() function (or wherever you wish to launch it) and also bind to it at the same point. Binding without an explicit startService will cause the service to stop when you kill the activity (unless some other activity is still bound to it).
In your activity's onStop() call a function on your service to tell it the activity has been killed.
In your Activity:
private ServiceRecordJourney yourService;
private ServiceConnection serviceConnection = new ServiceConnection() {
#Override
public void onServiceConnected(ComponentName className, IBinder service) {
YourServiceBinder binder = (YourServiceBinder) service;
yourService= binder.getService();
}
#Override
public void onServiceDisconnected(ComponentName arg0) {
}
};
#Override
public void onStart(){
super.onStart();
startService(new Intent(this, YourService.class));
// Bind to Service
Intent intent= new Intent(this, YourService.class);
bindService(intent, serviceConnection , Context.BIND_AUTO_CREATE);
}
#Override
public void onStop(){
super.onStop();
if(yourService != null){
yourService.activityKilledFunction();
unbindService(serviceConnection);
}
}
Your service will need to be foreground (and display a notification) to further stop it from being killed off by the OS. Also as it's been explicitly started you will need to handle an explicit stop on the service (either call stopSelf() on the service or stopService() in a context object.
You can handle communication to the service using multiple startService() calls with different intents but I prefer the above approach (and I'm sure that in the case binding is the preferable approach).
Also whilst the service is running the activity will bind and unbind to the service each time the activity is started or stopped by the user.

Stop service when app goes to background, using a common Base Activity

I have a Base Activity class to implement common behaviour for all the Activities. All of them extend this BaseActivity.
I'm binding to a service in in the BaseActivity's onStart method and unbinding conditionally in the onStop method. With conditionally, I mean that depending on some option selected by the user, the service should or should not keep running in the background when the app goes to background.
The problem is that sometimes the service keeps running when it shouldn't (this is, when the option for killing it is enabled, and unbindService() is effectively called).
I'm thinking that on every Activity change the service is unbound and bound again. Since bound services are reference counted, maybe my service is bound more times than unbound, so that's why it keeps running at the end, even when I call unbindService().
Additionally, the documentation says something about that:
You should usually pair the binding and unbinding during matching bring-up and tear-down moments of the client's lifecycle. For example:
If you only need to interact with the service while your activity is visible, you should bind during onStart() and unbind during onStop().
If you want your activity to receive responses even while it is stopped in the background, then you can bind during onCreate() and unbind during onDestroy(). Beware that this implies that your activity needs to use the service the entire time it's running (even in the background), so if the service is in another process, then you increase the weight of the process and it becomes more likely that the system will kill it.
Since I'm kind of trying to implement both options, what should be the best approach to implement this?

Finally I changed my approach and decided to use only startService() and communicate with the service using a Local Broadcast Receiver.
I start the service in the onCreate() and stop it in the onDestroy() methods of the Base Activity.
Then, to send a message from the Service to the activity, I use this:
private void sendBroadcastMessage(String msg) {
Log.d(LOG_TAG, "send broadcast message: " + msg);
Intent intent = new Intent(MyService.class.getSimpleName());
// Add data
intent.putExtra("message", msg);
LocalBroadcastManager.getInstance(this).sendBroadcast(intent);
}
Then, to be notified in the activity:
// handler for the events launched by the service
private BroadcastReceiver mMyServiceReceiver = new BroadcastReceiver() {
#Override
public void onReceive(Context context, Intent intent) {
// Extract data included in the Intent
String message = intent.getStringExtra("message");
Log.d(LOG_TAG, "Got message: " + message);
// Do stuff...
}
};
And to register the Receiver in the activity:
#Override
public void onResume() {
super.onResume();
LocalBroadcastManager.getInstance(this).registerReceiver(mMonitorReceiver,
new IntentFilter(MyService.class.getSimpleName()));
}