Managers and services: the pattern

getSystemService(Context.CAMERA_SERVICE) returns a CameraManager. That object is not the camera service. It is not even a thin wrapper around a socket. It is a client-side object holding a Binder proxy, and every method you call on it is a remote call to a different process.

TL;DR#

• The pattern is: Context constant → XxxManager (client) → Binder proxy → XxxService (server, usually in system_server).
• SystemServiceRegistry maps constants to manager objects. It is a static block in the framework, not a lookup on the server.
• The manager object is cheap to hold and is cached per Context. You rarely need to cache it yourself.
• Binder calls are synchronous by default and run on the calling thread. A slow service call is a blocked UI thread.
• Not every manager forwards to system_server: AudioManager reaches native code, NfcManager reaches an app process, and Mainline modules implement their own services.

Mental model#

Think of a company's switchboard numbers.

You keep a short list of extensions in your phone: 2100 for facilities, 2200 for IT, 2300 for accounts. Dialling 2100 does not put facilities in your pocket. It connects you to a desk in another building, and the conversation happens there.

The extension is the Context constant. The desk is the service. The phone is the manager object. And like a phone, the manager can be held while the desk is closed — dialling then just fails.

Where the analogy breaks#

A phone call is asynchronous: you leave a message. A Binder call is synchronous by default: you are on hold until the other side answers, and if the desk is slow, so are you. That difference is the single most important operational fact about the pattern, and it is why "don't call binder services on the main thread" is not folklore.

The big picture#

Deep dive#

The four parts#

1. The constant. Context.ACTIVITY_SERVICE is a String, "activity". That is not a coincidence: the constant is the Binder name. Context.WINDOW_SERVICE is "window", and the names are public API, so they are effectively frozen.¹

2. The manager. android.app.ActivityManager is a client class. It holds an IActivityManager proxy and implements convenience methods on top of it. The class is in framework.jar, which is why every app has it without shipping it.

3. The registry. SystemServiceRegistry is a static initialiser with one registerService(...) call per constant. Each call supplies a factory that builds the manager, and some also supply a "cached" variant that reuses the instance per process. That is why getSystemService normally returns the same object each time.

4. The service. ActivityManagerService is a Binder subclass published as "activity" in servicemanager. It implements IActivityManager.Stub.

• ‹›SystemServiceRegistry.java↗constant → manager factory, the client half of every service
• ‹›ContextImpl.java↗getSystemService's implementation, including the cache
• ‹›SystemServiceManager.java↗the server-side lifecycle every system service follows

What the call looks like on the wire#

// Client side, roughly what the generated proxy does.
public int getRecentTasks(int maxNum, int flags) throws RemoteException {
    Parcel data = Parcel.obtain();
    Parcel reply = Parcel.obtain();
    try {
        data.writeInterfaceToken(DESCRIPTOR);
        data.writeInt(maxNum);
        data.writeInt(flags);
        mRemote.transact(TRANSACTION_getRecentTasks, data, reply, 0);
        reply.readException();
        return reply.readInt();
    } finally {
        reply.recycle();
        data.recycle();
    }
}

Three things are worth noticing. The arguments are flattened into a Parcel (glossary definition); there is no object graph crossing the boundary, only bytes. The call is blocking on transact unless the oneway flag is set. And readException() exists because an exception on the server has to be re-thrown on the client — Binder does not propagate Java exceptions natively, it marshals them.

Why the client is cheap#

A manager object holds a proxy, and a proxy holds a Binder handle — an integer. That is the entire client-side state. There is no connection to establish, no handshake, no buffer to allocate. The kernel looks up the handle in the caller's Binder context and routes the transaction to the owning process.

This is why the pattern scales to a hundred services.² If each manager needed a socket and a connection thread, an app that touches ten services would pay ten times. Instead it pays a handle each.

The ones that do not fit#

The pattern is not universal, and the exceptions are instructive:

That last row explains a common confusion: SensorManager is in system_server, but the sensor samples do not travel over Binder. The service configures a native poller and, on modern Android, the data goes through shared memory (ASensorEventQueue with a BitTube), not one transaction per sample.

getSystemService returning null#

It can return null, and the reasons are worth knowing because they are all different:

• The name is wrong. A typo in a string constant returns null silently. getSystemService takes a String, and there is no compile-time check that the string exists.
• The service is not available on this device. Some services are optional or gated by hardware. A device without NFC has an NfcManager class but nothing to connect to.
• The process is too early. A ContentProvider.onCreate or Application.attachBaseContext may run before the registry is fully populated for that context.
• The service is restricted. Some services are unavailable to apps without a permission and return null instead of throwing, which is a deliberate choice to avoid making the restriction discoverable.

The catalogue#

Below is a cut of this site's service dataset: thirty of the most-used services, with the constant you pass, the manager you get back, the Binder name the service is published under, and the API level the manager class appeared. Filter it to find the one you are looking for.

Two columns repay study. The binder name column shows how often the name differs from the constant: STORAGE_SERVICE maps to "mount", TELEPHONY_SERVICE maps to "phone", SENSOR_SERVICE maps to "sensorservice". Those names predate the public constants and cannot be changed without breaking every native client.

The host process column shows that the pattern is about the client API, not about system_server specifically. A manager can front a native daemon or a module.

Writing your own#

The pattern is not reserved for the platform. A bound Service with an AIDL interface is the same shape at a smaller scale: the client holds a proxy, the service implements a Stub, and the arguments are parcelled. What you do not get is the SystemServiceRegistry shortcut, because that is registered by the framework, not by apps.

How it evolved#

The pattern itself has not changed since 2008. What changes is where the server lives. Services have been split (ActivityTaskManager, PermissionManager), moved into Mainline modules (Wi-Fi, Bluetooth, MediaProvider), and occasionally moved out of system_server entirely (NFC). The client API has stayed stable through all of it, which is the entire point of the boundary.

Under the hood#

• ‹›SystemServiceRegistry.java↗the static map from Context constants to manager factories
• ‹›ContextImpl.java↗getSystemService and the per-context cache
• ‹›Context.java↗the constants themselves, which are the Binder names
• ‹›ActivityManager.java↗a hand-written manager class on top of a generated AIDL proxy

Curiosity corner#

• The Binder name is not always the constant lowercased. STORAGE_SERVICE is "mount" because the service predates the constant and the name was already used by native clients.
• getSystemService can return an object whose service is not running. The manager exists regardless; the failure happens on the first call, not on the lookup.
• Context.getSystemService is cached per context, not per app. Two contexts in the same process may return two manager objects wrapping the same proxy.

Try it#

$ 
adb shell service list | head -20
adb shell service list | grep -E "activity|package|window"

Found 218 services:
0	android.app.IActivityManager: []
1	android.view.IWindowManager: []
2	android.content.pm.IPackageManager: []

service list prints the Binder name and the interface descriptor. It is the ground truth for the pattern: if a name is not in that list, no amount of getSystemService will reach it.

Check yourself#

Sources#