Developing applications for the platform Android is impossible without understanding how background processes work. When you need an app to download files, play music, or track geolocation even after the interface is minimized, standard activities are no longer enough. This is where the component Servicecomes into play, which is a fundamental element of the OS architecture.
Creating a service is not just about running code in the background, it is about working with a life cycle that is fundamentally different from the user’s usual screens. In modern versions of the operating system, Google has implemented strict restrictions on background activity, so simply starting a process no longer guarantees its survival. You will have to take into account many nuances, from API versions to the type of task being performed.
In this guide, we will look at how to properly design and implement a service so that it is not destroyed by the system and does not cause ANR errors. We will touch on both classical approaches and modern architectural recommendations, including the use of WorkManager and JobScheduler for deferred tasks.
What is Service and why do you need it?
A Service in Android is an application component that performs long-running operations in the background without providing a user interface. Unlike Activity, the service does not interact directly with the user, but works for other components or system processes. This makes it an ideal tool for tasks that require continuous execution.
There are two main types of services that developers use depending on the requirements of the task. Started Service runs to perform a single operation and does not return a result to the calling component, running even after the application that called it has finished. Bound Service allows other components to communicate with it and interact, using the IPC (Inter-Process Communication) mechanism.
⚠️ Attention: Starting with Android 8.0 (API level 26), the system imposes strict restrictions on the launch of background services. If your application is in the background, it cannot start a service in the normal way without the risk of being immediately stopped by the system.
Understanding the differences between service types is critical to choosing the right implementation strategy. An error in choosing the type can lead to memory leaks or, conversely, to premature completion of an important data loading process.
- 📱 Started Service: ideal for downloading files, loading large amounts of data or synchronization.
- 🔗 Bound Service: necessary when the Activity must receive data from the service in real time, for example, a loading bar.
- 🎵 Foreground Service: a special view of the launched service with a visible notification, used for players and navigation.
It is important to note that services run in the main thread of the application process by default. This means that if you perform heavy calculations or network requests directly in the method onStartCommand, you will block the UI thread.
⚠️ Attention: Blocking the main thread for more than 5 seconds will result in the ANR (Application Not Responding) dialog appearing, which will have an extremely negative impact on the user experience and application rating.
To solve this problem you need to create separate threads or use high-level abstractions such as Kotlin Coroutines or RxJava, inside the service body.
Basic structure and application manifest
Before writing code, you need to declare the service in the manifest file AndroidManifest.xml. Without this step, the system simply will not know about the existence of your component, and any attempt to run it will result in an exception SecurityException or simply ignoring the request.
In the manifest, you define the class name, access rights and, if necessary, intent filters. For modern applications, especially those running Android 5.0 and above, it is important to properly configure the attribute to control whether other applications can call your service. The attribute allows the system to instantiate the service and prevents access to it from the outside, which is a good security practice for internal services of the application. exportedto control whether other applications can call your service.
<serviceandroid:name=".MyBackgroundService"
android:enabled="true"
android:exported="false" />
Attribute android:enabled="true" allows the system to instantiate the service, and exported="false" blocks access to it from the outside, which is a good security practice for internal application services.
After the declaration in the manifest, a service class is created that inherits from the base class Service. In this class, you will have to override several key lifecycle methods, such as onCreate, onStartCommand and onDestroy.
⚠️ Attention: The interfaces and rules for working with background processes are updated regularly by Google. Always check the latest requirements in the official documentation before publishing the application on Google Play.
Particular attention should be paid to the method onStartCommandthat returns an integer value that determines the behavior of the service after it is forced to terminate by the system.
- 🔄 START_STICKY: the service will restarted by the system, but without the last Intent (suitable for players).
- 🚀 START_NOT_STICKY: the service will not be restarted unless new tasks arrive (suitable for periodic checks).
- 📦 START_REDELIVER_INTENT: the service will be restarted with the last Intent (important for guaranteed message delivery).
Implementation of Started Service and working with threads
The most common scenario is launching a service to perform a one-time task. When implementing such a service, you must take care of creating a worker thread yourself, since the service, as already mentioned, runs in the UI thread.
Inside the method onStartCommand usually a new thread is started Thread or used HandlerThread. This allows you to perform long-running operations without blocking the interface. However, manually managing threads in Java or Kotlin can be error-prone. To make things easier, Google previously provided a class that automatically created a worker thread and processed requests sequentially. Although it is marked as obsolete in the latest versions of the SDK (
To make things easier, Google previously provided a class IntentService, which automatically created a worker thread and processed requests sequentially. Although in the latest versions of the SDK it is marked as deprecated (deprecated), understanding how it works remains useful.
| Parameter | Service | IntentService (Legacy) | WorkManager |
|---|---|---|---|
| Execution thread | Main (needs its own thread) | Separate working | Asynchronous |
| Life cycle | Manually managed | Automatic | System-managed |
| Fulfillment guarantee | Low (in background) | Medium | High |
| Usage | Long processes | Short tasks | Delayed tasks |
If you still decide to use classic Service, you will have to manually call the method stopSelf or stopService after completion of work, otherwise the service will continue to hang in memory, wasting battery resources.
A modern alternative to manual thread management is to use Kotlin Coroutines inside the service. This allows you to write asynchronous code in a linear style, avoiding nesting of callbacks and simplifying error handling.
Foreground Service and notifications
For tasks that the user expects to see in real time (music, navigation, fitness tracking), it is necessary to use Foreground Service. Such a service must have a visible notification that is displayed in the status bar and cannot be brushed away by the user in the usual way.
To put the service in the foreground mode, you must call the method startForeground inside the method onStartCommand or onCreate. This method requires a notification ID and the object itself Notification.
val notification = NotificationCompat.Builder(this, CHANNEL_ID).setContentTitle("Music Player")
.setContentText("Playing song...")
.setSmallIcon(R.drawable.ic_music)
.build
startForeground(1, notification)
Starting with Android 12 (API 31), the requirements for Foreground Service have become even stricter. You must specify the service type (media, location, dataSync, etc.) in the manifest, otherwise the application will not run on new devices.
Use Foreground Service only when the user really needs it. Excessive use of such services may lead to the removal of the application from Google Play for poor battery optimization.
It is also important to consider that on Android 14 there are additional restrictions on running services in the background, requiring the use foregroundServiceType and the corresponding permissions in the manifest.
- 📍 location: for services using geolocation.
- 🎵 media: to play media content.
- 📡 dataSync: to synchronize user data.
- 🏃 health: to track health indicators.
Modern approach: WorkManager
Instead of creating your own services for background tasks, Google strongly recommends using the library WorkManager. This is a part of Android Jetpack that ensures that deferred background tasks are guaranteed to run even if the application is closed or the device is restarted.
WorkManager selects the optimal way to complete the task using JobScheduler on new versions of Android and proprietary mechanisms on old ones. This saves the developer from having to write complex code for compatibility.
Working with WorkManager is built around creating Worker a class that performs a task in a background thread. You describe the startup conditions (for example, the presence of a network or charging) and plan the work.
val constraints = Constraints.Builder.setRequiredNetworkType(NetworkType.CONNECTED)
.build
val request = OneTimeWorkRequestBuilder
.setConstraints(constraints)
.build
WorkManager.getInstance(context).enqueue(request)
Using this approach allows the Android system to efficiently manage resources, combining tasks from different applications to save battery power. This is especially important for tasks that do not require immediate execution, such as downloading news or syncing cloud data.
⚠️ Attention: WorkManager is not suitable for tasks that must be completed immediately or when the application is minimized and requires an immediate response (for example, a VoIP call).
Additionally, WorkManager supports task chaining, periodic queries, and storage of execution results, making it a powerful tool for complex background logic.
Lifecycle and optimization
Understanding the lifecycle of a service helps avoid memory leaks and performance issues. The onCreate method is called only once when the service is first instantiated, making it an ideal place to initialize resources.
The onDestroy method is called before stopping the service. Here you need to release all occupied resources: close connections to the database, unregister receivers, stop threads. Ignoring this step will result in the GC (Garbage Collector) not being able to delete the service object.
☑️ Checklist before starting the service
Optimizing the service also includes proper use wakelocks. If your service needs to prevent the processor from going to sleep while a task is running, you must manage power locks carefully, releasing them immediately after the job is completed.
It's worth remembering that services consume more resources than normal processes. Therefore, if a task can be completed faster and more efficiently by other means (for example, through Firebase Cloud Messaging for push notifications), it is better to use them.
To debug services, it is convenient to use the tool adb. The command adb shell dumpsys activity services will show a list of all running services and their status, which helps to find frozen processes.
Frequently asked questions (FAQ)
Can the service work if the application is completely closed?
Yes, but with limitations. Foreground Service can run until the system decides to stop it due to lack of memory. For background tasks, it is better to use WorkManager, which guarantees execution even if the application is closed, as long as device conditions are met.
What is the difference between Service and IntentService?
Service runs on the main thread and requires manual threading and stopping. IntentService (deprecated) automatically created a worker thread, processed tasks in the queue and stopped itself after completion.
Why is my service killed by the system after a few minutes?
Most likely, you did not put it in Foreground mode or did not use WorkManager. Android aggressively clears memory, killing background processes that have no visible priority for the user.
Do you need to register a service in Manifest?
Required. Without writing to AndroidManifest.xml the Android security system will not allow the application to start the service, and you will receive a runtime error.