Bound Service↗

Basics

A bound service is the server in a client-server interface. It lets components such as activities bind to the service, send requests, receive responses, and perform interprocess communication (IPC). A bound service typically lives only while it serves another application component and does not run in the background indefinitely.

A bound service is an implementation of the Service class that lets other applications bind to it and interact with it. To provide binding for a service, you implement the onBind() callback method. This method returns an IBinder object that defines the programming interface that clients can use to interact with the service.

ServiceConnection

A client binds to a service by calling bindService(). When it does, it must provide an implementation of ServiceConnection, which monitors the connection with the service.

When the Android system creates the connection between the client and service, it calls onServiceConnected() on the ServiceConnection. The onServiceConnected() method includes an IBinder argument, which the client then uses to communicate with the bound service.

Multiple can connect to bind service

The system calls the service's onBind() method to generate the IBinder only when the first client binds. The system then delivers that same IBinder to all additional clients that bind to that same service, 

When the last client unbinds from the service, the system destroys the service, unless the service was started using startService().

The most important part of your bound service implementation is defining the interface that your onBind() callback method returns. The following section discusses several ways that you can define your service's IBinder interface.

Create Bound service

There are three ways you can define the interface:

1. Extend the Binder class

If your service is private to your own application and runs in the same process as the client, which is common, create your interface by extending the Binder class and returning an instance of it from onBind(). The client receives the Binder and can use it to directly access public methods available in either the Binder implementation or the Service.

This is the preferred technique when your service is merely a background worker for your own application. The only use case when this is not the preferred way to create your interface is if your service is used by other applications or across separate processes.

2. Use a Messenger

If you need your interface to work across different processes, you can create an interface for the service with a Messenger.

This Handler is the basis for a Messenger that can then share an IBinder with the client, letting the client send commands to the service using Message objects.

This is the simplest way to perform interprocess communication (IPC),

3. Use AIDL

Android Interface Definition Language (AIDL) decomposes objects into primitives that the operating system can understand and marshalls them across processes to perform IPC. The previous technique, using a Messenger, is actually based on AIDL as its underlying structure.

To use AIDL directly, create an .aidl file that defines the programming interface. The Android SDK tools use this file to generate an abstract class that implements the interface and handles IPC, which you can then extend within your service.

Note: For most applications, AIDL isn't the best choice to create a bound service, because it might require multithreading capabilities and can result in a more complicated implementation. Therefore, this document does not discuss how to use it for your service. If you're certain that you need to use AIDL directly, see the AIDL document.

1. Implement by Extending the binder class

Here's how to set it up:

1. In your service, create an instance of Binder 

2. Return this instance of Binder from the onBind() callback method.

3. In the client, receive the Binder from the onServiceConnected() callback method and make calls to the bound service using the methods provided.

Note: The service and client must be in the same application so that the client can cast the returned object and properly call its APIs. The service and client must also be in the same process, because this technique doesn't perform any marshalling across processes. Unlike AIDL

<service 

android:name="com.sor.LocalService">

</service>

 Implement Using messenger

Implement Using AIDL

Above both implementation is not discussed here. It is require when IPC or other application is the client for the Bind service

Started service becomes bind service

As discussed in the Services overview, you can create a service that is both started and bound. That is, you can start a service by calling startService(), which lets the service run indefinitely. You can also let a client bind to the service by calling bindService().

If you let your service be started and bound, then when the service starts, the system doesn't destroy the service when all clients unbind. Instead, you must explicitly stop the service by calling stopSelf() or stopService().

Ex: Although you usually implement either onBind() or onStartCommand(), it's sometimes necessary to implement both. For example, a music player might find it useful to let its service run indefinitely and also provide binding. This way, an activity can start the service to play some music, and the music continues to play even if the user leaves the application. Then, when the user returns to the application, the activity can bind to the service to regain control of playback.