Understanding Android Client/Server Architecture and System Services

Android's client/server (C/S) architecture treats the app layer as the client and system services running in the system process as the server.

Public manager APIs in the SDK are stub classes compiled only for building apps; they are not packaged into the APK and rely on IPC to communicate with the actual server implementations, which inherit from Stub classes such as public class PhoneInterfaceManager extends ITelephony.Stub .

Example code for retrieving cell location demonstrates the client calling getITelephony() and handling RemoteException :

public CellLocation getCellLocation() {
    try {
        Bundle bundle = getITelephony().getCellLocation();
        return CellLocation.newFromBundle(bundle);
    } catch (RemoteException ex) {
        return null;
    }
}

Server‑side components are built using AIDL, bound services, and the ServiceManager. System services are registered via ServiceManager.addService(name, service, allowIsolated, dumpPriority) and may be implemented as either a bound Service or a SystemService subclass that receives boot‑phase callbacks.

The Android boot process creates and registers these services in SystemServer , invoking methods such as startBootstrapServices() , startCoreServices() , and startOtherServices() , and stores them in a list to prevent garbage collection.

Hidden APIs are marked with @hide in the source; they are omitted from the stub SDK at compile time but remain accessible via reflection at runtime, so security checks must be enforced in the server implementation.

Since Android 10, the platform supports modular APEX packages, allowing system components like the Bluetooth module to be updated independently via the Play Store.