2011-9-16 20:52:15

 

2011-9-16 20:52:15

 android.app.Service

A Service is an application component that runs in the background,

 not interacting with the user, for an indefinite period of time.
 
  Each service class must have a corresponding <service> declaration in its package's AndroidManifest.xml.
 
   Services can be started with Context.startService() and Context.bindService().

Note that services, like other application objects, run in the main thread of their hosting process.

 This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations,
 
  it should spawn its own thread in which to do that work. More information on this can be found in Application Fundamentals: Processes and Threads.

The Service class is an important part of an application's overall lifecycle.

Topics covered here:

Service Lifecycle
Permissions
Process Lifecycle
Service Lifecycle

There are two reasons that a service can be run by the system. If someone calls Context.startService() then the system will retrieve the service

 (creating it and calling its onCreate method if needed)
 
  and then call its onStartCommand method with the arguments supplied by the client.
 
   The service will at this point continue running until Context.stopService() or stopSelf() is called.
  
    Note that multiple calls to Context.startService() do not nest (though they do result in multiple corresponding calls to onStartCommand()),
   
     so no matter how many times it is started a service will be stopped once Context.stopService() or stopSelf() is called; however, services can use their stopSelf(int) method to ensure the service is not stopped until started intents have been processed.

For started services, there are two additional major modes of operation they can decide to run in, depending on the value they return from onStartCommand(): START_STICKY is used for services that are explicitly started and stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are used for services that should only remain running while processing any commands sent to them. See the linked documentation for more detail on the semantics.

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(). The client will receive the android.os.IBinder object that the service returns from its onBind method, allowing the client to then make calls back to the service. The service will remain running as long as the connection is established (whether or not the client retains a reference on the service's IBinder). Usually the IBinder returned is for a complex interface that has been written in aidl.

A service can be both started and have connections bound to it. In such a case, the system will keep the service running as long as either it is started or there are one or more connections to it with the Context.BIND_AUTO_CREATE flag. Once neither of these situations hold, the service's onDestroy method is called and the service is effectively terminated. All cleanup (stopping threads, unregistering receivers) should be complete upon returning from onDestroy().

Permissions
Global access to a service can be enforced when it is declared in its manifest's <service> tag. By doing so, other applications will need to declare a corresponding <uses-permission> element in their own manifest to be able to start, stop, or bind to the service.

In addition, a service can protect individual IPC calls into it with permissions, by calling the checkCallingPermission method before executing the implementation of that call.

See the Security and Permissions document for more information on permissions and security in general.

Process Lifecycle
The Android system will attempt to keep the process hosting a service around as long as the service has been started or has clients bound to it.

 When running low on memory and needing to kill existing processes, the priority of a process hosting the service will be the higher of the following possibilities:

If the service is currently executing code in its onCreate(), onStartCommand(), or onDestroy() methods, then the hosting process will be a foreground process

to ensure this code can execute without being killed.

If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen,

 but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed
 
 except in extreme low memory conditions.

If there are clients bound to the service, then the service's hosting process is never less important than the most important client. That is, if one of its

clients is visible to the user, then the service itself is considered to be visible.

A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user

is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)

Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens,

the system will later try to restart the service. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it.

Other application components running in the same process as the service (such as an android.app.Activity) can, of course,

 increase the importance of the overall process beyond just the importance of the service itself.