How does the very first Android system process (system_server) work?

system_server, the first System Process

The first process that will be forked by Zygote is system_server. Speaking about Zygote needs another article but in a word, it enables shared code across Dalvik/Art VM. It might be interesting to know that forking system_server is hardcoded inside ZygoteInit class.

Link to ZygoteInit class in AOSP

These hardcode arguments will be parsed to be converted to ZygoteArguments and be used as the input parameter by forkSystemServer method.

        /* Hardcoded command line to start the system server */
        String[] args = {
                "--setuid=1000",
                "--setgid=1000",
                "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1021,1023,"
                        + "1024,1032,1065,3001,3002,3003,3005,3006,3007,3009,3010,3011,3012",
                "--capabilities=" + capabilities + "," + capabilities,
                "--nice-name=system_server",
                "--runtime-args",
                "--target-sdk-version=" + VMRuntime.SDK_VERSION_CUR_DEVELOPMENT,
                "com.android.server.SystemServer",
        };

What does system_server exactly do?

I’m going to only explain about what/how other processes will be started by system_server. Having a look into SystemServer class you will notice that there’re four process types that will be started separately through different methods.

1. BootStrap services (by startBootstrapServices method)
2. Core services (by startCoreServices method)
3. Other services (by startOtherServices method)
4. Apex services (by startApexServices method)

The order of starting them is the same as they’re listed above. In each step system_server just focus on a specific process category to put them up and running. I will discuss each process category a bit below.

BootStrap services

This category contains the critical processes having mutual dependencies that it’s why they should initial in order and in one place. In fact, this step is crucial to get the system off the ground.

It begins by reading the system configuration that will be used later. Some of the classes are listed below but not in the order of calling:

1. FileIntegrityService
2. Installer
3. DeviceIdentifiersPolicyService
4. PowerStatsService
5. ActivityTaskManagerService
6. etc.

Core services

In this step, system_server starts some essential system services that were not included in the previous step listed below and the order is the same as calling:

1. SystemConfigService
2. BatteryService
3. UsageStatsService
4. WebViewUpdateService.
5. CachedDeviceStateService
6. BinderCallsStatsService
7. LooperStatsService
8. RollbackManagerService
9. NativeTombstoneManagerService
10. BugreportManagerService
11. GpuService

Other services

The list of services started here is so long that you can find many higher system-level services:

1. TelecomLoaderService
2. VibratorManagerService
3. DeviceStateManagerService
4. CameraServiceProxy
5. DevicePolicyManagerService
6. TelephonyRegistry
7. SystemUI
8. etc.

Apex services

The last services run by system_server are Apex services and no other system services must be run after them.

Also, there’s a watchdog mechanism provided by TimingsTraceAndSlog class especially to trace boot and shutdown timing. Besides, it utilizes Slog class to log the beginning, end and duration time of each process.

Note: The content is based on Android 13.