Android bound service I: Basics

Overview

The bound service is a service in a client-server interface. the bound ervice allows components (such as activities) to be bound to the service, send requests, receive responses, and even execute inter-process communication (IPC ). the Bound service generally only exists in the Process of serving other application components and does not always run in the background.

This document shows you how to create a bound service, including how to bind other application components to the service. however, you should also refer to the Service documentation to learn more general knowledge, such as how to send notifications from servcie, how to set the service to run on the front-end, and so on.

 

Bind to a "running" Service

As described in the Service documentation, you can create a service that is both "running" and "Bound. that is, this service can be started by calling startService (), which enables the service to run forever and allows a client to bind to it by calling indService.

 

If you allow your services to be "running" and "Bound", after the service is started, the system will not destroy the service after all clients are unbound. Instead, you must stop this service explicitly by calling stopSelf () or stopService ().

 

Although you should usually implement onBind () or onStartCommand (), sometimes you need to implement both. for example, a music player may find it useful to allow its service to run permanently and be bound at the same time. in this way, an activity can start the service to play some music, and the playback continues even if the user leaves the application.

 

Basic knowledge

A bound service is an implementation of a class Service that allows an application to be bound and then interacted. to bind a service, you must implement the onBind () callback method. this method returns an IBinder object that defines the program interface that the client can use to interact with the service.

 

A client can bind to a service by calling bindService. in this case, it must provide a ServiceConnection implementation. this implementation is used to monitor the connection between the client and the service. the bindService () method returns immediately without returning any value. However, when the Android system creates a connection between the client and the service, it calls the onServiceConnected () method of ServiceConnection () to send the IBinder that the client uses to communicate with servcie.

 

Multiple Clients can connect to a service at the same time. however, the system only calls the onBind () method of your service to receive IBinder when the first client is bound. the system then transmits the same IBinder to other clients, so it will not call onBind ().

 

When the last client unbinds the service, the system destroys the service (unless the service is also a "running" service ).

 

When you implement your bound service, the most important part is to define the interface returned by your onBind () callback method. there are many different ways to define your service's IBinder interface, and the following sections will discuss each technology.

 

Create a bound Service
When creating a bound service, you must provide an IBinder client for interaction with the service. You can define this interface in three ways:

 

 

Derived from class Binder

If your service is a private object of your own application and runs in the same process as the client (this is generally the case ), you should create your interface by deriving from the class Binder and return an instance of it from onBind. the client receives the Binder and then uses it to directly perform operations on the implemented public interfaces of the Binder and even the Service.

This is the best choice when your service is only working in the background and only serving your own applications. the only reason you cannot create your interface in this way is that your service is used by other applications or cross-process.

Use a Messenger

If you need your interface to work across processes, you can create an interface with Messager for the service. in this way, the service defines a Handler to take charge of different types of Message objects. this Handler is the basis for Messenger to share an IBinder with the client. It allows the client to send commands to servic using the Message object. the client can define its own Messenger so that the service can send messages back.

This is the easiest way to execute IPC, because Messenger puts all requests in the queue and sends them to one thread in sequence, so you do not have to design your service as thread-safe.

Use AIDL

AIDL (Android Interface Definition Language) executes all the work of IPC by breaking down objects into basic bodies that can be understood by the operating system and can be sent across processes. as mentioned above, the use of a Messenger is actually based on AIDL. as mentioned above, Messenger creates a queue in a thread to accommodate all client requests, and uses the service to receive only one request at a time. however, if you want your service to process multiple requests at the same time, you can directly use AIDL. in this case, your service must be multi-threaded and secure.

To directly use AIDL, you must create. the aidl file defines the program interface. the AndroidSDK tool uses this file to generate an abstract class that implements interfaces and processes IPC. Then you can derive it from your service.

Note: Most applications should not use AIDL to process a bound service, because it may require multithreading and make the implementation more complex. similarly, AIDL is not suitable for most applications and this document will not discuss how to use it in your service. if you are sure you need to use AIDL directly, please refer to the AIDL documentation.

 

From the column of nkmnkm