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
{@link android.R.styleable#AndroidManifestService <service>}
declaration in its package's AndroidManifest.xml. Services
can be started with
{@link android.content.Context#startService Context.startService()} and
{@link android.content.Context#bindService 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 {@link android.content.Context#startService Context.startService()} then the system will
retrieve the service (creating it and calling its {@link #onCreate} method
if needed) and then call its {@link #onStart} method with the
arguments supplied by the client. The service will at this point continue
running until {@link android.content.Context#stopService Context.stopService()} or
{@link #stopSelf()} is called. Note that multiple calls to
Context.startService() do not nest (though they do result in multiple corresponding
calls to onStart()), so no matter how many times it is started a service
will be stopped once Context.stopService() or stopSelf() is called.
Clients can also use {@link android.content.Context#bindService Context.bindService()} to
obtain a persistent connection to a service. This likewise creates the
service if it is not already running (calling {@link #onCreate} while
doing so), but does not call onStart(). The client will receive the
{@link android.os.IBinder} object that the service returns from its
{@link #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
{@link android.content.Context#BIND_AUTO_CREATE Context.BIND_AUTO_CREATE}
flag. Once neither
of these situations hold, the service's {@link #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 {@link android.R.styleable#AndroidManifestService <service>}
tag. By doing so, other applications will need to declare a corresponding
{@link android.R.styleable#AndroidManifestUsesPermission <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
{@link #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
{@link #onCreate onCreate()}, {@link #onStart onStart()},
or {@link #onDestroy 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.
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 {@link #onStart onStart()}
to schedule work to be done asynchronously or in another thread, then you
may want to write information about that work into persistent storage
during the onStart() call so that it does not get lost if the service later
gets killed.
Other application components running in the same process as the service
(such as an {@link android.app.Activity}) can, of course, increase the
importance of the overall
process beyond just the importance of the service itself. | 