21 Services and WorkManager

Overview

In Android, not all work should happen directly in activities or fragments. Some tasks need to continue when the user navigates away from the screen or even when the app is not visible. Other tasks must run at specific times or under specific conditions, such as when the device is charging or connected to Wi‑Fi. Services and WorkManager are the two main tools Android provides for these kinds of background operations.

This chapter introduces the overall role of Services and WorkManager in Android apps, how they differ, and when to use each. Later child chapters will focus on detailed usage, lifecycle, and implementation of each piece. Here you will build a mental model of background work on Android and how these two APIs fit together.

Background Work in Android

Android does not allow apps to run arbitrary work in the background without restrictions. The system needs to protect battery life, device performance, and user privacy. Because of this, background work is separated into different categories.

Short tasks that happen while the app is visible can often be handled directly with threads or coroutines. Longer running or out‑of‑app tasks usually require Services or WorkManager. When you plan background work, you always need to consider user expectations, system limits, and how critical the work is.

There are two broad kinds of background work. One kind is ongoing or long running work that might need to keep running as long as possible, sometimes with a visible notification. The other kind is deferrable work that can be scheduled to run later, maybe under certain conditions. Services target the first kind, WorkManager targets the second kind.

Where Services Fit

A Service is a component that can run in the background without a user interface. It lets you perform work even when an activity is not in the foreground. However, this does not mean it will run forever. The system can still stop or restart services depending on memory and policies.

Services are suitable when you need more immediate and ongoing work. A media player that keeps playing music when the user leaves the app is a common example. A navigation app that continues to provide turn‑by‑turn instructions is another. These use foreground services, which show a notification while they run.

Services integrate with the overall app lifecycle and can interact with other components, for example by broadcasting updates or communicating with activities. Because they are more flexible and closer to the system, they require careful control. Misusing services can quickly drain the battery. The dedicated child chapters will explain the different service types and their lifecycles.

Where WorkManager Fits

WorkManager is a high level library for running deferrable and guaranteed background work. Deferrable means the work does not have to run immediately. Guaranteed means WorkManager will try to run it even if the app process is killed or the device restarts.

WorkManager is ideal for tasks such as uploading logs, syncing data with a server, or processing files that do not need instant execution. You can declare conditions, such as only run when the device is charging or only run when there is network connectivity. WorkManager will plan and execute the work at an appropriate time.

One of the key features of WorkManager is that it abstracts away the underlying implementation. Depending on the device and API level, it may use JobScheduler, AlarmManager, or other mechanisms behind the scenes. From your point of view, you only define units of work and their constraints and WorkManager takes care of the rest.

Comparing Services and WorkManager

To choose between Services and WorkManager, you need to understand their core differences. Services are a low level component that you control directly. WorkManager is a higher level scheduler that you configure and then mostly leave alone.

Services focus on ongoing or immediate tasks. If you need to start work now and keep it running as long as needed, a service can help. Foreground services in particular are used when the user expects continuous behavior, such as music playback or fitness tracking. The service can run as long as the user clearly knows it is active.

WorkManager focuses on scheduled and persistent work. If a task can happen later, or should be retried until it succeeds, WorkManager is a more suitable choice. It can survive app restarts. It can chain multiple tasks, for example first compress a file, then upload it, then clean up.

A simple way to think about it is: if the user is actively aware that something is running and it must feel continuous, consider a service. If the user just expects that something will eventually be done, such as synced or uploaded, consider WorkManager.

System Restrictions and Background Limits

Android has introduced many restrictions on background execution over time. These changes strongly affect how you should design your background work. Old patterns that kept a service running all the time are no longer acceptable on modern Android versions.

Unrestricted background services are heavily limited, especially when the app is in the background. To keep long running work active, apps often must use a foreground service, which shows a notification and signals to the system that the user has consented to the ongoing work.

WorkManager is designed to respect these restrictions. It schedules work in a way that aligns with system rules and optimizations. For example, it can batch network tasks with other jobs to save battery. This is one of the reasons WorkManager is preferred for many background tasks on modern Android.

When designing your app, you should assume that the system can stop background components at any time. This means your long running or important tasks must be resilient. Services and WorkManager both provide mechanisms to restart or continue work when conditions allow, but you must plan for interruptions.

Typical Use Cases

Developing an intuition for which tool fits a given task is important. Some scenarios clearly belong to services, others clearly belong to WorkManager, and some require a combination.

If you are building a music streaming app, continuous playback when the user switches apps is a classic service use case. The playback will usually run in a foreground service. The user sees a notification that controls the playback and knows that something is active.

If you are building a messaging app, sending a message or uploading an attachment can often be done through WorkManager. When the user taps send, the app can enqueue a work request to handle the network operation. If the network is unavailable, WorkManager can delay and retry. The user simply expects that the message will eventually be delivered.

If your app periodically syncs data in the background, such as backing up photos or downloading new content, WorkManager is usually the correct choice. You can specify that it should run only with Wi‑Fi or only while charging. The system then runs these sync tasks at efficient times.

Sometimes an app combines both. For example, a fitness tracking app might use a foreground service during a workout to record sensor data in real time. Later, when the workout ends, it might use WorkManager to upload the collected data to a server in the background.

Lifecycle and Reliability Concepts

Services and WorkManager both extend the idea of lifecycle beyond activities, but in different ways. A service has its own lifecycle callbacks that tell you when it is created, started, or destroyed. This lifecycle is tied to the process and system decisions. The service may be killed and recreated, and you need to handle that gracefully.

WorkManager uses a different model. You do not control a lifecycle object directly. Instead, you define a Worker that represents a single unit of work. WorkManager schedules and executes these workers, possibly even across app restarts. The reliability comes from how it stores work requests and their state.

A critical difference is how each handles persistence. A standard service does not automatically persist across reboots. If you need the work to resume after a device restart, you must handle it manually, for example using broadcasts or alarms. WorkManager persists its work definitions and can continue after a reboot without much extra code.

Both approaches can report progress or completion. A service can communicate directly with activities, fragments, or notifications. WorkManager lets you observe work status, for example using LiveData, which fits well with modern app architectures.

Designing with User Experience in Mind

Background work is not only a technical detail. It has a strong impact on user experience. Unnecessary or poorly managed background tasks can drain the battery, consume data, and make the device feel slow. The user may then uninstall or disable your app.

Services should be used sparingly and only when truly needed. Every moment a foreground service runs, the user sees a notification. This can be distracting if it is not clearly useful. Foreground work should always match a task that the user understands, such as navigation, recording, or downloading a large file that they explicitly started.

WorkManager allows more subtle background behavior, but you must still be respectful. If you schedule frequent syncs or heavy processing, it will affect the device. You should consider offering settings that let users control background activity, such as sync frequency or network constraints.

A good design uses Services and WorkManager in a way that matches user expectations. If your app promises to keep track of a run, then a foreground service is appropriate. If it promises to back up photos in the background, then WorkManager fits better. Aligning the technical tool with the user promise is essential.

Integration with Other Components

Services and WorkManager do not exist in isolation. They connect with many other parts of an Android app. You will often start a service from an activity or fragment, for example when the user presses a play button. You may also stop it when the user finishes a task.

WorkManager is usually integrated into your higher level architecture. In an MVVM setup, for example, a ViewModel might enqueue work in response to user actions. The UI can then observe the status of that work, for example to show a progress indicator or an error message if syncing fails.

Notifications are a common bridge between background work and users. Foreground services require a notification. WorkManager tasks that run in the background may also use notifications to inform users of completed work, such as finished downloads or synced content.

Because Services and WorkManager are both part of the wider background system, they also interact with app permissions and security. For example, a service that accesses location requires proper permissions, and WorkManager jobs that access the network require the same. You must always respect security best practices, especially when running code that is not directly visible to the user.

Choosing Your Approach

When starting a new feature that involves background work, begin by asking two questions. Does this task need to start right now and feel continuous to the user, or can it happen later? Does it need to be guaranteed to finish, even across app restarts and device reboots?

If the task is immediate and ongoing, a service is the primary candidate. If the task is deferrable and persistent, WorkManager is usually the best option. If both aspects exist, you might combine them, using a service for the active part and WorkManager for follow up tasks.

Over time, Android has encouraged developers to move many types of background work to scheduled and constraint aware systems. WorkManager is a central part of that direction. You should consider it the default for many background tasks, especially network and disk related work, and only use Services where their behavior is clearly required.

Later sections will explore each of these tools in detail. You will learn how to create, start, and manage different kinds of services, and how to define and schedule work using WorkManager. With that knowledge, you will be able to design background features that are reliable, efficient, and friendly to users and their devices.