Service

Why Background Work Needs a Contract

When an application moves to the background, Android assumes the user has finished interacting with it. The Activity Manager Service (AMS) will eventually kill the application process to reclaim memory for other tasks. If your application is playing music or syncing a database, you need a way to tell the operating system that valuable work continues. A silent background thread is not enough, because the system does not track arbitrary threads.

The Service component solves this process management problem. A Service acts as a lifecycle contract between your application and the system. Starting a Service elevates your process priority out of the cached background state. This protection signals to the out-of-memory (OOM) killer that your process remains active. By default, a Service executes on the main thread of your application. You must manually spawn a background thread for heavy network operations, or you will block the UI and trigger an Application Not Responding (ANR) error.

So a Service prevents premature process death, but applications use background tasks for different reasons. Sometimes you need to fire off a quick backup, while other times you need a persistent connection to stream data.

The Two Execution Paths: Started and Bound

Applications interact with background tasks using two distinct patterns. An Activity might trigger a file download and not care what happens next. A different UI component might need an open channel to stream data continuously from a local database manager. Android handles these two scenarios with Started Services and Bound Services.

A Started Service acts as a fire-and-forget operation initiated via startService(). The Service runs indefinitely in the background until it explicitly terminates itself using stopSelf(). The system invokes the onStartCommand() lifecycle callback to deliver the actual intent data. A Bound Service acts as a persistent client-server interface created via bindService(). This approach establishes a direct connection, allowing clients to pass requests and results across process boundaries. A Bound Service only stays alive as long as at least one client remains connected to it.

These two lifecycles operate differently within the system. This flowchart shows the execution paths for both Service types. Visualizing these paths clarifies their lifecycle differences. Look at how Bound Services depend on clients to stay alive, while Started Services run until you explicitly stop them.

The diagram demonstrates that the started path flows linearly from creation to termination. The bound path remains active as long as clients maintain their connections. The system does allow a single Service to take both paths simultaneously. The OS will only destroy a dual-path Service once both execution conditions resolve.

While Started Services keep processes alive, they created a massive issue early in Android's history. Developers realized they could use them to keep applications running permanently in the background.

The Battery Problem and Foreground Services

Silent background services used to drain batteries severely. Applications would run polling loops or track location without the user realizing it. The system needed a way to restrict background execution without breaking legitimate long-running tasks like fitness trackers. Modern Android solves this process abuse by introducing Foreground Services.

A Foreground Service requires the application to perform its work transparently. The operating system forces the Service to display an un-dismissible notification in the status bar. This strict visibility requirement guarantees users always know when an app consumes resources in the background. When you launch a Foreground Service, the system starts a strict five-second countdown timer. If your application fails to call startForeground() within that window, AMS assumes the app is behaving maliciously. The OS immediately crashes the application with a SecurityException.

To promote a background service to foreground priority, you must build a notification and pass it to the system. This code binds the ongoing task to a visible UI element. The user will see this notification until the Service stops.

Intent intent = new Intent(this, MainActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, intent, PendingIntent.FLAG_IMMUTABLE);

Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID)
        .setContentTitle("Syncing Data")
        .setContentText("Uploading files")
        .setSmallIcon(R.drawable.ic_sync)
        .setContentIntent(pendingIntent)
        .build();

startForeground(1, notification);

Common Mistake: Engineers often start a background thread to do setup work before calling startForeground(). If that thread blocks or delays execution, the five-second window expires and the app crashes. Always call this method immediately inside onCreate() or onStartCommand().

By enforcing this visibility, the system successfully trades silent background power for user awareness. But how does the system actually track these timers, notifications, and client connections across every running process?

Tracking State with ServiceRecord

The system server must monitor every background component globally to make intelligent memory decisions. Just having a Java class in your application process does not mean the system knows about it. The Activity Manager Service needs a centralized way to evaluate which background tasks deserve to live. AMS tracks these components internally using an object called ServiceRecord.

When you call startService() or bindService(), the request crosses the Binder boundary into AMS. The system allocates a new ServiceRecord to act as the absolute source of truth for the Service's state. AMS uses this record to track client connections, process priorities, and CPU time consumption. When the device experiences extreme memory pressure, the OOM killer scans these records. The memory manager evaluates the binding counts and foreground status to decide which services it can safely terminate.

You can inspect these internal system records on any running device. The following command queries AMS to output the current state of all active Services. You will see the exact priority adjustments applied to hosting processes.

adb shell dumpsys activity services

Common Mistake: Engineers frequently run this command blindly and get overwhelmed by the output. The raw dump lists every background component on the device. Always pipe the results to grep with your application package name to find your specific ServiceRecord.

Interview Note: Interviewers often ask how to guarantee a background process will never be killed. The correct answer is that no such guarantee exists on Android. Even Foreground Services terminate if the system runs critically low on memory. Always design your tasks to resume gracefully.

The ServiceRecord proves that a Service represents a system-level entity rather than a simple application thread. AMS strictly manages these records to keep the entire operating system stable. However, Services only solve one half of the background communication puzzle. When you need to broadcast a message to multiple applications simultaneously, a direct Service connection is not enough. You need an entirely different component to handle system-wide announcements.