In the Binder ecosystem, if Process A wants to communicate with Process B, it needs a handle (a pointer) to an object in Process B. But how does Process A find Process B in the first place? This bootstrap problem is solved by the servicemanager daemon.
ServiceManager as the Binder DNS
servicemanager acts as the DNS (Domain Name System) for Binder. Instead of IP addresses, it maps human-readable strings (like "activity" or "package") to the actual Binder object references.
It is one of the very first native daemons started by the init process during boot. It runs in its own process and holds a special, universally known Binder handle: Handle 0.
Registering Services: addService()
When the system_server (or a native daemon like audioserver) starts up, it instantiates its core services. It then must register them so others can find them.
It does this by making a Binder transaction to Handle 0 (servicemanager), calling the addService() function.
// Native example of registering a service
sp<IServiceManager> sm = defaultServiceManager();
sm->addService(String16("my_service"), new MyService());
servicemanager receives this request, verifies the caller's permissions (via SELinux), and stores the string-to-handle mapping in an internal dictionary.
Looking up Services: getService()
When a client app wants to talk to a system service, it calls context.getSystemService(). Deep down, this translates to a getService() call to servicemanager.
// Java framework internal example
IBinder b = ServiceManager.getService("activity");
IActivityManager am = IActivityManager.Stub.asInterface(b);
The client sends the string "activity" to Handle 0. servicemanager looks up the string, finds the corresponding Binder handle pointing to the ActivityManagerService in the system_server process, and returns that handle to the client.
servicemanager Process and its SELinux Context
servicemanager is highly privileged but tightly constrained. Because every process must talk to it, its SELinux context (u:r:servicemanager:s0) is heavily audited.
servicemanager actively enforces SELinux rules during addService and findService. When an app tries to look up "telephony.registry", servicemanager checks the service_contexts policy to ensure the calling app's domain is allowed to find that specific service. If not, it returns a null handle, blocking the IPC attempt entirely.
Context0 and the Special Binder Handle
As mentioned, Handle 0 is a magic number in the Binder driver.
When a process opens /dev/binder and sends a transaction directed to Handle 0, the kernel driver intercepts this and routes it directly to the process that registered itself as the "context manager" (which is servicemanager). This hardcoded routing allows the entire dynamic lookup system to bootstrap itself without any prior configuration.