IT. Expert System.

Android Reference

Service


android.app

Class Service

  • All Implemented Interfaces:
    ComponentCallbacks, ComponentCallbacks2
    Direct Known Subclasses:
    AbstractInputMethodService, AccessibilityService, BinderThreadPriorityService, BordeauxService, DreamService, IntentService, LocalService, MessengerService, RecognitionService, RemoteViewsService, SpellCheckerService, TextToSpeechService, VpnService, WallpaperService

    public abstract class Service
extends ContextWrapper
implements ComponentCallbacks2
    A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use. 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 Processes and Threads. The IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done.

    Topics covered here:

    1. What is a Service?
    2. Service Lifecycle
    3. Permissions
    4. Process Lifecycle
    5. Local Service Sample
    6. Remote Messenger Service Sample

    Developer Guides

    For a detailed discussion about how to create services, read the Services developer guide.

    What is a Service?

    Most confusion about the Service class actually revolves around what it is not:

    • A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
    • A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).

    Thus a Service itself is actually very simple, providing two main features:

    • A facility for the application to tell the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it.
    • A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it.

    When a Service component is actually created, for either of these reasons, all that the system actually does is instantiate the component and call its onCreate() and any other appropriate callbacks on the main thread. It is up to the Service to implement these with the appropriate behavior, such as creating a secondary thread in which it does its work.

    Note that because Service itself is so simple, you can make your interaction with it as simple or complicated as you want: from treating it as a local Java object that you make direct method calls on (as illustrated by Local Service Sample), to providing a full remoteable interface using AIDL.

    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(android.content.Intent, int, int) 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 IBinder object that the service returns from its onBind(android.content.Intent) 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.

    As of Build.VERSION_CODES.GINGERBREAD, when using Context.startService(Intent), you can also set Intent.FLAG_GRANT_READ_URI_PERMISSION and/or Intent.FLAG_GRANT_WRITE_URI_PERMISSION on the Intent. This will grant the Service temporary access to the specific URIs in the Intent. Access will remain until the Service has called stopSelf(int) for that start command or a later one, or until the Service has been completely stopped. This works for granting access to the other apps that have not requested the permission protecting the Service, or even when the Service is not exported at all.

    In addition, a service can protect individual IPC calls into it with permissions, by calling the ContextWrapper.checkCallingPermission(java.lang.String) 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 Activity) can, of course, increase the importance of the overall process beyond just the importance of the service itself.

    Local Service Sample

    One of the most common uses of a Service is as a secondary component running alongside other parts of an application, in the same process as the rest of the components. All components of an .apk run in the same process unless explicitly stated otherwise, so this is a typical situation.

    When used in this way, by assuming the components are in the same process, you can greatly simplify the interaction between them: clients of the service can simply cast the IBinder they receive from it to a concrete class published by the service.

    An example of this use of a Service is shown here. First is the Service itself, publishing a custom class when bound:

    With that done, one can now write client code that directly accesses the running service, such as:

    Remote Messenger Service Sample

    If you need to be able to write a Service that can perform complicated communication with clients in remote processes (beyond simply the use of Context.startService to send commands to it), then you can use the Messenger class instead of writing full AIDL files.

    An example of a Service that uses Messenger as its client interface is shown here. First is the Service itself, publishing a Messenger to an internal Handler when bound:

    If we want to make this service run in a remote process (instead of the standard one for its .apk), we can use android:process in its manifest tag to specify one:

    Note that the name "remote" chosen here is arbitrary, and you can use other names if you want additional processes. The ':' prefix appends the name to your package's standard process name.

    With that done, clients can now bind to the service and send messages to it. Note that this allows clients to register with it to receive messages back as well:

    • Constructor Detail

      • Service

        public Service()

    • Method Detail

      • getApplication

        public final Application getApplication()
        Return the application that owns this service.

      • onCreate

        public void onCreate()
        Called by the system when the service is first created. Do not call this method directly.

      • onStartCommand

        public int onStartCommand(Intent intent,
                 int flags,
                 int startId)
        Called by the system every time a client explicitly starts the service by calling Context.startService(android.content.Intent), providing the arguments it supplied and a unique integer token representing the start request. Do not call this method directly.

        For backwards compatibility, the default implementation calls onStart(android.content.Intent, int) and returns either START_STICKY or START_STICKY_COMPATIBILITY.

        If you need your application to run on platform versions prior to API level 5, you can use the following model to handle the older onStart(android.content.Intent, int) callback in that case. The handleCommand method is implemented by you as appropriate:

        Note that the system calls this on your service's main thread. A service's main thread is the same thread where UI operations take place for Activities running in the same process. You should always avoid stalling the main thread's event loop. When doing long-running operations, network calls, or heavy disk I/O, you should kick off a new thread, or use AsyncTask.

        Parameters:
        intent - The Intent supplied to Context.startService(android.content.Intent), as given. This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except START_STICKY_COMPATIBILITY.
        flags - Additional data about this start request. Currently either 0, START_FLAG_REDELIVERY, or START_FLAG_RETRY.
        startId - A unique integer representing this specific request to start. Use with stopSelfResult(int).
        Returns:
        The return value indicates what semantics the system should use for the service's current started state. It may be one of the constants associated with the START_CONTINUATION_MASK bits.
        See Also:
        stopSelfResult(int)

      • onDestroy

        public void onDestroy()
        Called by the system to notify a Service that it is no longer used and is being removed. The service should clean up any resources it holds (threads, registered receivers, etc) at this point. Upon return, there will be no more calls in to this Service object and it is effectively dead. Do not call this method directly.

      • onConfigurationChanged

        public void onConfigurationChanged(Configuration newConfig)
        Description copied from interface: ComponentCallbacks
        Called by the system when the device configuration changes while your component is running. Note that, unlike activities, other components are never restarted when a configuration changes: they must always deal with the results of the change, such as by re-retrieving resources.

        At the time that this function has been called, your Resources object will have been updated to return resource values matching the new configuration.

        Specified by:
        onConfigurationChanged in interface ComponentCallbacks
        Parameters:
        newConfig - The new device configuration.

      • onLowMemory

        public void onLowMemory()
        Description copied from interface: ComponentCallbacks
        This is called when the overall system is running low on memory, and would like actively running process to try to tighten their belt. While the exact point at which this will be called is not defined, generally it will happen around the time all background process have been killed, that is before reaching the point of killing processes hosting service and foreground UI that we would like to avoid killing.

        Applications that want to be nice can implement this method to release any caches or other unnecessary resources they may be holding on to. The system will perform a gc for you after returning from this method.

        Specified by:
        onLowMemory in interface ComponentCallbacks

      • onBind

        public abstract IBinder onBind(Intent intent)
        Return the communication channel to the service. May return null if clients can not bind to the service. The returned IBinder is usually for a complex interface that has been described using aidl.

        Note that unlike other application components, calls on to the IBinder interface returned here may not happen on the main thread of the process. More information about the main thread can be found in Processes and Threads.

        Parameters:
        intent - The Intent that was used to bind to this service, as given to Context.bindService. Note that any extras that were included with the Intent at that point will not be seen here.
        Returns:
        Return an IBinder through which clients can call on to the service.

      • onUnbind

        public boolean onUnbind(Intent intent)
        Called when all clients have disconnected from a particular interface published by the service. The default implementation does nothing and returns false.
        Parameters:
        intent - The Intent that was used to bind to this service, as given to Context.bindService. Note that any extras that were included with the Intent at that point will not be seen here.
        Returns:
        Return true if you would like to have the service's onRebind(android.content.Intent) method later called when new clients bind to it.

      • onRebind

        public void onRebind(Intent intent)
        Called when new clients have connected to the service, after it had previously been notified that all had disconnected in its onUnbind(android.content.Intent). This will only be called if the implementation of onUnbind(android.content.Intent) was overridden to return true.
        Parameters:
        intent - The Intent that was used to bind to this service, as given to Context.bindService. Note that any extras that were included with the Intent at that point will not be seen here.

      • onTaskRemoved

        public void onTaskRemoved(Intent rootIntent)
        This is called if the service is currently running and the user has removed a task that comes from the service's application. If you have set ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this callback; instead, the service will simply be stopped.
        Parameters:
        rootIntent - The original root Intent that was used to launch the task that is being removed.

      • stopSelfResult

        public final boolean stopSelfResult(int startId)
        Stop the service if the most recent time it was started was startId. This is the same as calling Context.stopService(android.content.Intent) for this particular service but allows you to safely avoid stopping if there is a start request from a client that you haven't yet seen in onStart(android.content.Intent, int).

        Be careful about ordering of your calls to this function.. If you call this function with the most-recently received ID before you have called it for previously received IDs, the service will be immediately stopped anyway. If you may end up processing IDs out of order (such as by dispatching them on separate threads), then you are responsible for stopping them in the same order you received them.

        Parameters:
        startId - The most recent start identifier received in onStart(android.content.Intent, int).
        Returns:
        Returns true if the startId matches the last start request and the service will be stopped, else false.
        See Also:
        stopSelf()

      • setForeground

        @Deprecated
public final void setForeground(boolean isForeground)
        Deprecated. This is a now a no-op, use startForeground(int, Notification) instead. This method has been turned into a no-op rather than simply being deprecated because analysis of numerous poorly behaving devices has shown that increasingly often the trouble is being caused in part by applications that are abusing it. Thus, given a choice between introducing problems in existing applications using this API (by allowing them to be killed when they would like to avoid it), vs allowing the performance of the entire system to be decreased, this method was deemed less important.

      • startForeground

        public final void startForeground(int id,
                   Notification notification)
        Make this service run in the foreground, supplying the ongoing notification to be shown to the user while in this state. By default services are background, meaning that if the system needs to kill them to reclaim more memory (such as to display a large page in a web browser), they can be killed without too much harm. You can set this flag if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.

        If you need your application to run on platform versions prior to API level 5, you can use the following model to call the the older setForeground() or this modern method as appropriate:

        Parameters:
        id - The identifier for this notification as per NotificationManager.notify(int, Notification).
        notification - The Notification to be displayed.
        See Also:
        stopForeground(boolean)

      • stopForeground

        public final void stopForeground(boolean removeNotification)
        Remove this service from foreground state, allowing it to be killed if more memory is needed.
        Parameters:
        removeNotification - If true, the notification previously provided to startForeground(int, android.app.Notification) will be removed. Otherwise it will remain until a later call removes it (or the service is destroyed).
        See Also:
        startForeground(int, Notification)

      • dump

        protected void dump(FileDescriptor fd,
        PrintWriter writer,
        String[] args)
        Print the Service's state into the given stream. This gets invoked if you run "adb shell dumpsys activity service <yourservicename>". This is distinct from "dumpsys <servicename>", which only works for named system services and which invokes the IBinder.dump(java.io.FileDescriptor, java.lang.String[]) method on the IBinder interface registered with ServiceManager.
        Parameters:
        fd - The raw file descriptor that the dump is being sent to.
        writer - The PrintWriter to which you should dump your state. This will be closed for you after you return.
        args - additional arguments to the dump request.


Content

Android Reference

Java basics

Java Enterprise Edition (EE)

Java Standard Edition (SE)

SQL

HTML

PHP

CSS

Java Script

MYSQL

JQUERY

VBS

REGEX

C

C++

C#

Design patterns

RFC (standard status)

RFC (proposed standard status)

RFC (draft standard status)

RFC (informational status)

RFC (experimental status)

RFC (best current practice status)

RFC (historic status)

RFC (unknown status)

IT dictionary

License.
All information of this service is derived from the free sources and is provided solely in the form of quotations. This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 276 / 158794724. Delta: 0.04009 с