Introduction to Android Boot Optimization with systemd

In the realm of advanced Android customizations and embedded systems, boot time is a critical performance metric. While stock Android primarily relies on its `init` system, many customized Android distributions, embedded Linux systems running Android frameworks, or specialized industrial Android devices leverage `systemd` for its robust service management capabilities. Understanding and optimizing `systemd` unit file dependencies is paramount to shaving precious seconds off the boot sequence, enhancing user experience, and improving system responsiveness.

This expert-level guide delves into identifying and resolving `systemd` dependency bottlenecks in an Android-centric environment. We’ll explore how to diagnose slow-starting services, dissect `systemd` unit file structures, and implement strategic modifications to parallelize processes and streamline the boot flow.

The Role of systemd in Custom Android Environments

For clarity, it’s important to note that the core Android Open Source Project (AOSP) uses its own `init` process. However, in scenarios such as Android running on a full Linux distribution (e.g., through Anbox or Waydroid setups), or deeply embedded systems where Android’s userspace is built on top of a `systemd`-managed Linux kernel, `systemd` plays a vital role. In these contexts, `systemd` manages system services, device initialization, and the overall boot ordering, making its optimization crucial.

Identifying Boot Bottlenecks with systemd-analyze

The first step in any optimization effort is diagnosis. `systemd-analyze` is an invaluable tool for visualizing the boot process and pinpointing services that are delaying startup. Run these commands from your device’s shell (e.g., via `adb shell` if applicable, or a direct console):

systemd-analyze blame
systemd-analyze critical-chain
systemd-analyze plot > boot_analysis.svg

• `systemd-analyze blame`: Lists all running units, ordered by the time they took to initialize, with the slowest at the top. This immediately highlights potential culprits.
• `systemd-analyze critical-chain`: Shows a tree-like dependency chain of the services that blocked the boot process the most. This is crucial for understanding why a slow service might be delaying others.
• `systemd-analyze plot > boot_analysis.svg`: Generates an SVG image displaying a Gantt chart of the entire boot process, providing a visual representation of parallelization and sequential execution. Transfer this SVG to your PC for detailed inspection.

Look for services with unusually long initialization times or services that are part of the critical chain early in the boot process.

Understanding systemd Unit Files and Dependencies

`systemd` manages services, mount points, devices, and other system resources through unit files, typically located in `/etc/systemd/system/` or `/lib/systemd/system/`. We’ll focus on `.service` and `.target` units for boot optimization.

Key Dependency Directives:

The `[Unit]` section of a unit file defines its dependencies and ordering:

• `Wants=`: A weaker dependency. If the wanted unit fails to start, the current unit will still attempt to start. This is ideal for non-critical services.
• `Requires=`: A stronger dependency. If the required unit fails to start, the current unit will also fail. Use this for essential services.
• `After=`: Specifies that this unit should start *after* the listed units. This is an ordering dependency, not a failure dependency.
• `Before=`: Specifies that this unit should start *before* the listed units. Also an ordering dependency.
• `PartOf=`: Links units such that starting/stopping one unit also affects others. Often used for grouping services under a target.
• `Conflicts=`: Ensures that specified units are stopped if this unit is started, and vice-versa.

The interplay of `Requires`, `Wants`, `After`, and `Before` determines the parallelization potential. Services with only `Wants` and `After` dependencies are excellent candidates for parallelization, provided their actual runtime doesn’t depend on the full completion of the `After` unit, only its initiation.

Practical Optimization: Customizing Unit Files

When modifying system unit files, always use drop-in snippets (`.d/` directories) or override files to avoid directly editing original files, which could be overwritten by system updates. For a service named `my-custom-android-hal.service`, create a directory `/etc/systemd/system/my-custom-android-hal.service.d/` and place `.conf` files inside it (e.g., `override.conf`).

Scenario: Deferring a Non-Critical Service

Imagine `custom-sensor-calibration.service` takes 10 seconds and is currently pulled in by `basic.target` using `Requires=`. This is delaying the core Android environment.

Original `custom-sensor-calibration.service` (simplified):

[Unit]
Description=Custom Sensor Calibration Service
Requires=basic.target
After=basic.target other-hardware-init.service

[Service]
ExecStart=/usr/bin/custom-sensor-calibrator
Type=forking

[Install]
WantedBy=multi-user.target

Optimization Steps:

1. Identify the service: Use `systemd-analyze blame`.

2. Analyze its purpose: Is `custom-sensor-calibration.service` absolutely critical for the initial `basic.target` or `multi-user.target`? If it can run in the background after the user interface is available, we can defer it.

3. Create an override: Create `/etc/systemd/system/custom-sensor-calibration.service.d/defer.conf`.

   [Unit]
   # Remove the strong dependency on basic.target if it's not truly needed early
   Requires=
   # Change WantedBy to a later target, or a custom target if needed
   # Or, if it should still be started by multi-user.target, just ensure ordering
   After=network.target # Example: requires network, or simply a later stage
   
   [Install]
   # Ensure it's not pulled in by basic.target, but by the more common multi-user.target
   WantedBy=multi-user.target

4. Remove default `WantedBy` from original unit: Sometimes, the original unit might have `WantedBy=basic.target` in its `[Install]` section. While drop-ins can add `WantedBy`, they can’t easily *remove* it from the original `[Install]` section. In such cases, if you have write access to the original unit file (which is generally discouraged), you might change `WantedBy=basic.target` to `WantedBy=multi-user.target`. A safer approach is to introduce a new target unit that explicitly starts your service *later* and make `multi-user.target` want *your* new target.

Scenario: Parallelizing Dependent Services

Suppose `display-driver-init.service` and `gpu-accelerator.service` are currently starting sequentially due to `After=display-driver-init.service` in `gpu-accelerator.service`, but `gpu-accelerator.service` only needs `display-driver-init.service` to have *started*, not necessarily completed its lengthy initialization.

Original `gpu-accelerator.service`:

[Unit]
Description=GPU Accelerator Service
After=display-driver-init.service
Requires=display-driver-init.service

[Service]
ExecStart=/usr/bin/gpu-accelerator-start
Type=simple

[Install]
WantedBy=basic.target

Optimization Steps:

1. Assess true dependency: Does `gpu-accelerator.service` *absolutely require* `display-driver-init.service` to be fully up and running before it can start? Or can it start in parallel, perhaps retrying connection to the display driver if it’s not ready immediately?

2. Relax `Requires` to `Wants`: If `display-driver-init.service` failure isn’t catastrophic for `gpu-accelerator.service` (e.g., `gpu-accelerator` can fall back to a software renderer or retry), change `Requires` to `Wants`.

3. Modify `gpu-accelerator.service.d/parallelize.conf`:

   [Unit]
   # Change the strong dependency to a weaker one if possible
   Requires=
   Wants=display-driver-init.service
   
   # Keep After= to ensure it doesn't try to start before display-driver-init is at least initialized
   # If it can truly run in parallel from the very beginning, After= can be removed or adjusted.
   # Example: If GPU can init alongside, but needs display-driver-init.service's socket later
   # You might consider using a socket unit activation if applicable.
   # For now, we assume After= is still needed for a minimal ordering.
   After=display-driver-init.service

Applying Changes

After modifying or creating override files, inform `systemd` about the changes:

systemctl daemon-reload
systemctl start custom-sensor-calibration.service # To test manually
systemctl reboot # To test full boot process

Re-run `systemd-analyze blame` and `systemd-analyze critical-chain` after a reboot to verify the impact of your changes. Iterate on this process, targeting the next slowest or most critical service.

Advanced Considerations

• Cgroup Management: For resource-intensive services, `systemd` can apply cgroup settings directly in the unit file (e.g., `CPUSchedulingPolicy=idle`, `MemoryLimit=`). This doesn’t affect boot time directly but can improve overall system responsiveness during boot by limiting resource contention.
• Transient Units: For one-off services started dynamically, `systemd-run` can create transient units. While not directly for boot optimization, understanding this capability is part of advanced `systemd` management.
• System Targets: Beyond `basic.target` and `multi-user.target`, targets like `graphical.target` (for GUI environments) or custom targets (e.g., `android-ready.target`) can be used to group services and define more granular boot stages.

Conclusion

Optimizing Android boot times in `systemd`-managed environments is a meticulous process involving careful analysis of service dependencies and strategic modifications of unit files. By leveraging `systemd-analyze` to identify bottlenecks and intelligently adjusting `Wants`, `Requires`, `After`, and `Before` directives, developers and system integrators can significantly reduce startup delays. This not only enhances the perceived performance of custom Android devices but also contributes to a more efficient and responsive embedded system overall.