The System_service process calls Systemmanager.getservice ("activity") to return the reference to AMS directly?

AMS runs in the System_service process, and recently saw the code found in the other service lines of this process thread in order to get AMS direct call:

Activitymanagerservice am = (activitymanagerservice) servicemanager.getservice ("activity");

Verify that the returned AM is directly an instance of AMS, no problem, why is this?

We generally use servicemanager.getservice in other processes to obtain the AMS service, the return is a remote Binder agent,

What happens if I use it in the same process? In order to explain this problem, we must first review the binder communication knowledge, because it is too complex, here can only outline the basic principles

Binder IPC Model

Binder in the kernel in two forms: Binder entity (binder_node), binder reference (BINDER_REF)
Binder_node:
{
binder_proc* proc; Service Process Information
void__user* ptr; Service instance pointer
}
Binder_ref:
{
binder_proc* proc; Service Process Information
binder_node* node; Point to Binder entity
unit32_t desc; Service handle value that uniquely identifies a service
}

Two typical processes

1. Service is registered with ServiceManager:
Create a binder entity (orange rectangle) in the kernel, a binder reference (blue hexagon),
In ServiceManager, use map to save the service name and binder reference (blue curve quadrilateral).
2. Client passes ServiceManager getService ("activity") case,
Client first communicates with the ServiceManager process
The client first constructs a binder reference (gray curve quadrilateral) with a handle of 0.
Send data to the kernel via this reference (containing the name "activity" of Servcie),
Create a ServiceManager Biner reference (gray hexagon) in the kernel space,
The binder entity (gray rectangle) for which ServiceManager is found,
Then wake up the ServiceManager process,
Through the ServiceManager instance in the Binder entity, call its GetService method,
ServiceManager found the binder reference for the Activitymanagerservice service by name,
Create a Activitymanagerservice binder reference for the client process in the kernel (blue hexagon)
and returns the binder's handle value to the client, creating an app-side binder reference in the client (blue curve quadrilateral)

The client can then communicate with AMS through the binder reference on the app side.
In App-service communication, the binder kernel drives the function of DNS, which is to find the binder entity of the corresponding service through binder reference.

Back to the beginning question:

The above step is to request the AMS service on the client side, here the client with AMS in two different processes,
If, in the same process, AMS is running in the system_server process, if other service threads request the AMS service through Systemmanager.getservice ("activity"),
Then this interface will return a reference to the Activitymanagerservice instance directly. What is the reason?
Mainly in the blue section of Case 2 step, the binder driver checks:

Static voidBinder_transaction (structBinder_proc *proc,structBinder_thread *Thread,structBinder_transaction_data *tr,intreply) {Switch(fp->type) {...         CaseBinder_type_handle: CaseBinder_type_weak_handle: {structBinder_ref *ref= Binder_get_ref (proc, fp->handle, FP->type = =binder_type_handle); if(ref==NULL) {Binder_user_error ("%d:%d got transaction with invalid handle,%d\n", Proc-PID, Thread->pid, fp->handle); Return_error=br_failed_reply; Gotoerr_binder_get_ref_failed; }            if (Ref->node->proc = = Target_proc) {if (Fp->type = = Binder_type_handle) F                P->type = Binder_type_binder;                else Fp->type = Binder_type_weak_binder;                Fp->binder = ref->node->ptr;                Fp->cookie = ref->node->cookie;                Binder_inc_node (ref->node, Fp->type = = Binder_type_binder, 0, NULL);                Trace_binder_transaction_ref_to_node (t, ref);                         Binder_debug (binder_debug_transaction, "ref%d desc%d, node%d u%016llx\n", ref->debug_id, Ref->desc, ref->node->debug_id, (u64) ref->node->p            TR); } Else {                structBinder_ref *New_ref; New_ref= Binder_get_ref_for_node (Target_proc,ref-node); if(New_ref = =NULL) {Return_error=br_failed_reply; Gotoerr_binder_get_ref_for_node_failed; } FP->binder =0; FP->handle = new_ref->desc; FP->cookie =0; Binder_inc_ref (new_ref, FP->type = =Binder_type_handle, NULL); Trace_binder_transaction_ref_to_ref (T,ref, New_ref); Binder_debug (Binder_debug_transaction,"ref%d desc%d-Ref%d desc%d (node%d) \ n",                         ref->DEBUG_ID,ref->desc, new_ref->debug_id, New_ref->desc,ref->node->debug_id); }        }  Break;...}}

Red Code
First Judge Ref->node->proc = = Target_proc, that is, the process of registration and now the process of getting AMS is the same,
If yes, overwrite Fp->type to Binder_type_binder, set fp->binder = ref->node->ptr;
The subsequent procedure returns the instance reference from the binder entity of AMs to the requestor,

So when you get the same process service, the reference to the instance is returned directly. Of course there is a more direct approach to access in a process, but in some special cases it is also possible, but less efficient, since the IPC has undergone a servicemanager

The System_service process calls Systemmanager.getservice ("activity") to return the reference to AMS directly?