Android：Service

public abstract class

Service

extends ContextWrapper
implements ComponentCallbacks Class Overview

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().

 

Service主要用於兩種目的：

1、在後台長時間執行某個任務，不和使用者直接互動

2、給其他應用程式提供某種功能服務

 

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 IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done.

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

 

 

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

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).

Service不是一個獨立的進程，而是工作在應用程式所在的進程之中。Service也不是一個線程。

 

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(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(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().

 

Service對調用的三種方式：

1、當系統中調用Context.startService()時，系統就會搜尋是否存在合適的Service響應，如果存在，就調用它的onCreate()函數建立它，然後再調用它的onStartCommand()，Service會一直運行直到出現Context.stopService()或stopSelf()的調用。

2、用戶端代碼也可以調用Context.bindService()來獲得與某項服務的長期綁定，這樣也會調用Service的onCreate()方法，但不會調用onStartCommand()方法。用戶端代碼會得到一個IBinder對象，如果它調用Service的onBind()方法，這允許用戶端通過IBinder對象對Service進行回調。Service會一直在後台運行，即使當前沒有用戶端代碼對service的IBinder對象的引用。

3、Service也可以同時被開啟並綁定，在這種情況下，Service會在開啟狀態或存在對Service綁定串連狀態下保持運行。但是一旦兩種條件都不成立，那麼Service的onDestroy()函數就會被調用。所以在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(String) method before executing the implementation of that call.

 

在Service對應的manifest檔案中需要添加<service>標籤，但是在使用Service的用戶端需要使用<uses-permission>標籤。

 

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.

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

android.app.Service

 

下面是一些常用的成員方法：

 

public void onCreate () Since: API Level 1

Called by the system when the service is first created. Do not call this method directly

 

public void onDestroy () Since: API Level 1

Called by the system to notify a Service that it is no longer used and is being removed. The service should clean up an 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.

 

public int onStartCommand (Intent intent, int flags, int startId) Since: API Level 5

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. Do not call this method directly.

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

 

Parameters

intent	The Intent supplied to startService(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).

 

 

public abstract IBinder onBind (Intent intent) Since: API Level 1

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 this can be found in Application Fundamentals: 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.

public final void stopSelf () Since: API Level 1

Stop the service, if it was previously started. This is the same as calling stopService(Intent) for this particular service

 

 

SDK中的localService還沒有研究。。。。。