Effective foreground services on Android

This is the fourth in a series of blog posts that describe strategies and guidance in the mobile app development with respect to power.

A process is not forever.

Android is a mobile operating system designed to work with limited memory and battery. For this reason, a typical Android application may have its process destroyed by the system to recover memory. The process that is being eliminated is chosen based on a classification system of how important that process is for the user at that time. Here, in descending order, is the classification of each kind of process. The higher the range, the lower the probability that the process will kill.

The processes of the native Linux daemon are responsible for running everything (including the process killer itself).

System The process of the system server, which is responsible for maintaining this list.

Persistent applications Persistent applications such as Phone, Wi-Fi and Bluetooth are crucial to keep your device connected and provide its most basic functions.

Foreground application the application that the user is currently using is an application that is in the foreground and with a ground connection.

Perceptible applications: are applications that the user can perceive that they are running. For example, an application with a foreground service that plays audio, or an application configured as the preferred voice interaction service will be linked to the system server, effectively promoting it at the Perceptible level.

Service fund service as download manager and synchronization administrator.

Home The Launcher application that contains desktop backgrounds

Previous application the previous application in the foreground that the user was using. The previous application lives on top of the cached applications, since it is the most likely application that the user will change to the next one.

Cached applications: these are the remaining applications that have been opened by the user and then as a background. First they will be killed to recover their memory and the strictest restrictions will be applied to them in modern versions. You can read about them in the Behavior Changes pages of Nougat, Oreo and Pie.

The foreground service

There is nothing wrong with becoming a cached application: sharing the user's device is part of the life cycle that every application developer must accept to maintain a happy ecosystem. In a device with a discharged battery, 100% of the applications are not used. And an application blamed for killing the battery could even be uninstalled.

However, there are valid scenarios to promote your application to the foreground: the prerequisites for using a foreground service are that your application is executing a task that is immediate, important (must complete), that the user can perceive (in the most of the cases, because it was initiated by the user), and must have a well-defined beginning and end. If a task in your application meets these criteria, it can be promoted to the foreground until the task is complete.

There are some guidelines on the creation and administration of foreground services. For all API levels, a persistent notification must be displayed with at least PRIORITY_LOW while the service is being created. When you point to API 26+, you must also configure the notification channel in at least IMPORTANCE_LOW. The notification must have a form for the user to cancel the work; this cancellation can be linked to the action itself: for example, stopping a music track can also stop the music playback service. Finally, the title and description of the service notification in the foreground must show an accurate description of what the service is doing in the foreground.

For more information about the foreground services, including several important updates in recent versions, see running a service in the foreground.

Close-up service use cases

Some good examples of foreground service uses are music playback, the completion of a purchase transaction, tracking the high-precision location for the exercise, and recording the sensor data for rest. The user will initiate all these activities; it must occur immediately, have an explicit beginning and end, and the user can canceled them at any time.

Another good use case for a foreground service is to make sure those critical and immediate tasks (for example, saving a photo, sending a message, and processing a purchase) are completed if the user moves away from the application and a new one begins.