The SystemServer needs a functioning Binder so that services can be added to, and retrieved from, the ServiceManager as it starts up.
A service is added as a name/Binder pair using the android.os.ServiceManager
public static void addService(String name, IBinder service)
method.
A service is retrieved by name using the android.os.ServiceManager
public static IBinder getService(String name)
If it is found then the corresponding Binder registerd with the ServiceManager is returned, which can then be used to access the functionality of the named service.
The ServiceManager server implementation can be found in
$(ANDROID_SRC)/frameworks/base/cmds/servicemanager
It is implemented in C, so sticking with the no native code policy, a new one needs to be implemented in Java. As we have a functioning Binder implementation written in Java this is fairly simple. All it needs to do is handle invocations and hold a map of name/Binder pairs.
The Android runtime uses the ServiceManager to add services, and to find them, but the ServiceManager itself is accessed via a Binder. It cannot be used to find itself so how is this Binder obtained ? This is the standard bootstrap problem, and can be solved in the usual way, that is, by making the ServiceManager a special case whose location is determined in some other way, for example, hard-wiring.
Here’s what the initial stages of the start-up of the SystemServer looks like from the point of view of the ServiceManager.
The triple on the left of each line is the pseudo pid/gid/uid of the process making the call. When a service is found the triple after the service name shows the same information for the process where the Binder is located. At this point only the SystemServer is running so its the only process you can see the triple for.
Note that all of the services being added have been persuaded to run one way or another at this point, which is not the same as saying they actually do anything.