Efficiently manage Android front desk services

This is the fourth installment in the Android power management series, and hopefully provides strategic insights and practical guidance on device battery life for developers.

As a mobile operating system, Android was designed with resource constraints such as memory and power in mind. As a result, the system shuts down some processes when memory is tight to make room for higher-priority tasks. So how does the system evaluate priority? The criteria are simple. The key is how important the application process is to the user. Android classifies processes into the following categories, in descending order of importance: the higher a process is ranked, the less likely it is to be recycled.

Application caching is normal: every developer should realize that sharing device resources is part of lifecycle management to help foster a healthy Android ecosystem. When the battery runs out, all applications cannot be used, and applications that consume abnormal power may be uninstalled.

However, in certain cases, developers do need to move applications from the background to the foreground. If the tasks performed by an application meet the following conditions, you can create foreground services for the application until the tasks are complete: (1) Perform the tasks immediately. (2) Important (must be done); (3) Perceived by users (initiated by users in most cases); (4) Have a clear start time and end time.

In order to help you better create and manage the front desk service, we have summarized the following three operational points:

1. Applies to all API levels: When an application creates a service, it must display persistent notifications of at least PRIORITY_LOW level.

2. If the application’s target API level is higher than 26, you also need to set the notification channel level to at least IMPORTANCE_LOW. The user can click on a notification to cancel a task, and the cancellation action can be tied to an action. For example, when the user stops playing a song, the playback service will also stop.

3. The notification title and description must accurately represent the operations being performed by the foreground service.

If you want to learn more about foreground services, including the most recent major updates to the Android platform, see Running Services in foreground.

Typical use cases for front-desk services include playing music, completing purchase transactions, high-precision geolocation tracking (fitness apps), and sensor data entry (monitoring a user’s sleep status). These tasks are initiated by the user and must be performed immediately, with a clear start and end time and the user can cancel the operation at any time.

In addition, you can create foreground services for critical tasks that need to be performed immediately, such as saving images, sending messages, processing transactions, etc., so that the execution of these tasks will not be affected even if the user exits the current application and starts a new one. When the device is out of memory, the system may forcibly stop the previous application that is still running, resulting in data loss or other unexpected events. A good application should have the ability to monitor its own progress in real time, and then, once the process is in the background, move key tasks that take less time to the foreground.

If the application needs to run the service in the foreground all the time, it is not enough to create the foreground service. You are advised to select the optimal solution from the following use cases to meet the application requirements and save battery power.

It is not recommended that you implement passive location tracking through the foreground service. If the user has allowed your application to perform location tracking, please call the FusedLocationProvider API to obtain location updates and set an appropriate acquisition frequency (not too frequently). Send notifications to the user via the Geofencing API when the host device enters or leaves a specific area. For more technical details, see optimizing Location management for Extended Device Life.

CompanionDeviceManager is used to pair the bluetooth device. If the application needs to reconnect to the device, call the startScan method in BluetoothLeScanner that accepts the PendingIntent parameter, which will be triggered when the filtering conditions are met.

If a task must be completed but deferred execution is allowed, use WorkManager or JobScheduler for optimal task scheduling and scheduling at the system level. ThreadPools or Kotlin Coroutines are recommended for tasks that need to start immediately but stop once the user exits the application.

The DownloadManager helps you process long downloads in the background, and it supports breakpoint continuation, allowing you to continue the last download even if the network connection is down or the device is restarted.

When used correctly, the application can use the “communication channel” of the foreground service to inform the system that it is currently working on tasks that are important to the user. Correct tool decisions are the best path to a first-class user experience. Welcome you to speak in the community and give us positive feedback, together with the majority of developers to make better decisions, put the user first!

Click here to learn more about P&E products