Service Manager, one of the binder mechanisms of the android System

Although Android is built on Linux, it implements a lightweight IPC Mechanism instead of using Linux to provide the IPC Mechanism.
-- Binder Mechanism. And android
Based on the Binder Mechanism, the android framework provides a set of encapsulation that can implement object proxy (proxy for objects in Remote Processes in local processes ). This article briefly analyzes android
Binder Mechanism.

Binder Scenario Analysis

We can understand an IPC communication as a client-server mode. Therefore, we will analyze the typical binder application mode here:

1. The client obtains the proxy object of the server in some way (which will be described in detail later. From the client perspective, there is no difference between the proxy object and its local object. It can call its method and access its variables like other local objects.
2. The client sends a request to the server by calling the server proxy object.
3. the proxy object sends user requests to the server process through the binder driver of the android kernel (Linux kernel.
4. The server process processes user requests and returns the processing results to the client's server proxy object through the binder driver of the android kernel (Linux kernel.
5. The client receives the returned results from the server.

If you are familiar with COM or CORBA, what do the above scenarios remind you? That's right! All are object proxies. The above scenarios are often used in Android. If you haven't noticed this, this article is perfect for you.

Composition of the Binder Mechanism 1. Binder driver

The binder is a character driver in the kernel located at:/dev/binder. This device is the core part of the Android system IPC. The client service proxy is used to forward
The server sends a request. The server also returns the processing result to the client's Service proxy object. We only need to know its functions. The focus of this article is not here, so
This part will not be specifically introduced later, because few will show that the device is opened to develop Android programs. For more information, see binder. c In the kernel source code.

2. Service Manager

Manages services. In step 1, the client needs to query and obtain the required services from the Service Manager. The server also needs to register its own services with the Service Manager. We can see that service manager is the big manager of services.

3. Service (server)

It should be emphasized that the service here refers to the system server rather than the SDK server. For details, refer to "(transfer) high hall-what is the underlying structure of the android framework?" Introduction to the two types of servers (in fact, there should be three types, and the server called by init is lost and configured in init. Rc ).

4. Client

Generally, it refers to applications on the Android system. It can request services in the server.

5. Object proxy

It refers to the server proxy generated in the client application ). From the application perspective, there is no difference between the proxy object and the local object. You can call its method. The methods are both synchronous and the corresponding results are returned.

Big internal manager-Service Manager

The general manager of the Binder Mechanism in Android is service manager. All servers (system servers) need to register with them, and applications need to query corresponding services. This article first introduces Service Manager.

Through the above introduction, we know that service manager is very important and has a great responsibility. Then how can we become a service?
What about Manager? Can anyone become a service?
What about Manager? How can I handle Server Registration and application query and retrieval services? To answer these questions, check the service in Android
Manager source code, which is located:

frameworks\base\cmds\servicemanager\service_manager.c

We found the main function, which means that it is a process. In init. RC, we found that:

service servicemanager /system/bin/servicemanager    user system    critical    onrestart restart zygote    onrestart restart media

It indicates that it is the core Android program and runs automatically upon startup.

Next, let's look at its code. The main function is very simple:

int main(int argc, char **argv){    struct binder_state *bs;    void *svcmgr = BINDER_SERVICE_MANAGER;    bs = binder_open(128*1024);    if (binder_become_context_manager(bs)) {        LOGE("cannot become context manager (%s)\n", strerror(errno));        return -1;    }    svcmgr_handle = svcmgr;    binder_loop(bs, svcmgr_handler);    return 0;}

We can see that it first calls binder_open to open the binder device (/dev/binder), and then it calls the binder_become_context_manager function, which changes itself to the "Server Manager". The Code is as follows:

int binder_become_context_manager(struct binder_state *bs){    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);}

That is, declare "I am the Server Manager" to the binder device through IOCTL ".

Service
As a Server Manager, manager is also a server. Since it is a server, you must always prepare to provide services for the client. Best Service
The manager calls binder_loop to enter the cyclic State and provides a callback function to wait for the user's request. Pay attention to his service
The Manager Client includes both applications (query and retrieval services) and servers (registration services ).

Service
How can managers request their services? The answer is that the scenario we mentioned above is the same. You need to create a server proxy in your own process. There is no place to query the service.
How does a customer generate a Service proxy object? The answer is that the binder device (/devbinder) maintains a handle for each service and calls
The binder_become_context_manager function becomes a service of "Server Manager". Its handle is always 0, which is a "well-known" handle.
Each program can create

Service Manager Proxy object. The handle of other services on the binder device is not fixed. You need to query the "Server Manager" to know.

Now we need to study how the server registers the service, or in its source code, we can see in its service processing function (as mentioned above, the callback function registered by the binder_loop function to the binder device) the following code is available:

    case SVC_MGR_ADD_SERVICE:        s = bio_get_string16(msg, &len);        ptr = bio_get_ref(msg);        if (do_add_service(bs, s, len, ptr, txn->sender_euid))            return -1;        break;

When a server writes a request to the binder device to register a service, the service processing callback function of Service Manager is called. Let's take a closer look at the implementation of the do_add_service function:

int do_add_service(struct binder_state *bs,                   uint16_t *s, unsigned len,                   void *ptr, unsigned uid){    struct svcinfo *si;//    LOGI("add_service('%s',%p) uid=%d\n", str8(s), ptr, uid);    if (!ptr || (len == 0) || (len > 127))        return -1;    if (!svc_can_register(uid, s)) {        LOGE("add_service('%s',%p) uid=%d - PERMISSION DENIED\n",             str8(s), ptr, uid);        return -1;    }    si = find_svc(s, len);    if (si) {        if (si->ptr) {            LOGE("add_service('%s',%p) uid=%d - ALREADY REGISTERED\n",                 str8(s), ptr, uid);            return -1;        }        si->ptr = ptr;    } else {        si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));        if (!si) {            LOGE("add_service('%s',%p) uid=%d - OUT OF MEMORY\n",                 str8(s), ptr, uid);            return -1;        }        si->ptr = ptr;        si->len = len;        memcpy(si->name, s, (len + 1) * sizeof(uint16_t));        si->name[len] = '\0';        si->death.func = svcinfo_death;        si->death.ptr = si;        si->next = svclist;        svclist = si;    }    binder_acquire(bs, ptr);    binder_link_to_death(bs, ptr, &si->death);    return 0;}

We can see that we first check whether we have the permission to register the service. If we do not have the permission, we are sorry, and an error is returned. Then we can check whether we have registered or registered the service.
Service cannot be registered again. Construct a svcinfo object and add it to svclist in a global linked list. Last notification binder device: There is
Service Registration.

Let's take a look at how the client obtains the service through the Service Manager, or in the service processing function (the callback function registered to the binder_loop function as mentioned above), there is the following code:

    case SVC_MGR_GET_SERVICE:    case SVC_MGR_CHECK_SERVICE:        s = bio_get_string16(msg, &len);        ptr = do_find_service(bs, s, len);        if (!ptr)            break;        bio_put_ref(reply, ptr);        return 0;

We can see that if we find the service through do_find_service, write it to reply and return it to the client.

In this article, we have briefly analyzed service manager. We will continue to analyze other parts of the android Binder Mechanism in the future.

Original