PowerManagerService, NetworkManagementService, and Other Services - AOSP Framework & Internals

While the Big Four (AMS, PMS, WMS, IMS) are crucial, the system relies on dozens of other specialized services to handle hardware and networking.

PowerManagerService (PMS) Initialization

PowerManagerService (often abbreviated as PowerMS to avoid confusion with PackageManagerService) manages power states, wake locks, and screen brightness.

During its initialization, PowerMS instantiates the Notifier (to handle screen on/off broadcasts) and connects to the SuspendControlService to communicate with the kernel's suspend mechanisms. It parses the power_profile.xml from the framework resources, which defines the power consumption (in mAh) of various hardware components, crucial for the Battery stats UI.

NetworkManagementService (NMS) Startup

NetworkManagementService (NMS) does not manage Wi-Fi or Cellular connections directly. Instead, it is a low-level service that interacts directly with the Linux kernel's networking stack via netd (the native network daemon).

During startup, NMS establishes a connection to netd using a local socket. It configures firewall rules (iptables/nftables), manages interface routing, and handles bandwidth quotas. For example, when Android's "Data Saver" is turned on, ConnectivityService tells NMS to instruct netd to drop packets from background applications.

Service Dependency Management

Because SystemServer starts services linearly, late-starting services must carefully handle dependencies.

If ServiceA requires ServiceB, but ServiceB hasn't started yet, ServiceA cannot look up ServiceB in its constructor. Instead, ServiceA must wait for the systemReady() callback or use a lazy-loading mechanism.

For example, many services need to show notifications. They cannot access NotificationManagerService until the ActivityManager has broadcast ACTION_BOOT_COMPLETED. Attempting to push a notification earlier will crash the system.

Adding a New Service to System Server

If you are modifying AOSP and need to add a custom service, the general workflow is:

Define the Interface: Create an AIDL file (e.g., IMyCustomService.aidl).
Implement the Stub: Create a Java class extending IMyCustomService.Stub.

Register the Service: In SystemServer.java, within the startOtherServices() method, instantiate your service.

try {
    Slog.i(TAG, "My Custom Service");
    ServiceManager.addService("my_custom", new MyCustomService(context));
} catch (Throwable e) {
    reportWtf("starting My Custom Service", e);
}

SELinux: You must declare the new service context in service_contexts and grant permissions in the .te policy files, otherwise ServiceManager will reject the addService call.