Scanning Bluetooth Low Energy (BLE) beacons in the background is essential for apps that offer proximity-based functionalities, such as indoor navigation, proximity marketing, and asset tracking. However, Android, in an attempt to optimize battery life, has introduced various restrictions over time on apps’ ability to perform background tasks. These restrictions make continuous background beacon scanning a significant challenge for Android developers.
Background Service Limitations
Before Android 8.0 (API level 26), developers could use Android Services to perform background tasks, including beacon scanning.
However, starting with Android 8.0, Google introduced Background Execution Limits, limiting how frequently an app can retrieve the user’s current location while running in the background [1][2]. Apps can receive location updates only a few times an hour. This limitation applies to all apps running on devices with Android 8.0 or higher, regardless of the app’s target SDK version [1].
Android 8.0 introduced Foreground Services as a way for apps to perform background tasks indefinitely, but with the requirement to show a persistent notification to the user. Moreover, apps must declare the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permissions for BLE scanning, and starting with Android 10, the ACCESS_BACKGROUND_LOCATION permission is also required for background scanning.
Android 12 (API level 31) introduced further restrictions regarding background resource management, with a specific focus on privacy and energy consumption [3]. The most significant updates related to BLE scanning are:
- Additional location permissions restrictions: With Android 12, applications must obtain explicit user consent before accessing background location data. If an app requests background location permission, the user can choose whether to allow or deny access based on their preferences.
- Limitations on BLE scan frequency: Android 12 reduces the frequency of BLE beacon scanning in the background, limiting how often apps can scan in the background to avoid excessive battery consumption.
Solutions
Despite the limitations imposed by Android, there are several alternative solutions for background beacon scanning:
- Using Geofencing: Android’s Geofencing API allows apps to be notified when the device enters or exits a predefined geographic area [4]. This functionality can be used to trigger beacon scanning only when the device is near an area of interest, reducing energy consumption.
- Periodic Scanning with WorkManager: WorkManager is an Android API that allows scheduling of background tasks in an energy-efficient manner [5]. You can use WorkManager to schedule beacon scanning at regular intervals, even when the app is not in the foreground. However, WorkManager is not suitable for apps that require continuous real-time scanning.
- Using a BroadcastReceiver and Thread: An interesting alternative solution is proposed by D. Young in [6], where the author provides an in-depth analysis of the evolution of Android Services, which, due to restrictions introduced in Android 8 and 12, have become increasingly complex and limited for executing background code. The author proposes an alternative using BroadcastReceiver and threads to perform BLE beacon scanning in the background without using Android Foreground Services (thus avoiding service-related restrictions), offering greater freedom and flexibility to the developer (the article also provides code for a reference app [7]). This approach offers more flexibility than other solutions but requires more careful management of the app’s lifecycle and energy consumption. The operating system allows only 10 seconds to exit the onReceive method of the BroadcastReceiver before terminating the app. Executing a new thread within the onReceive method allows for indefinite execution of code. However, the operating system may still suspend code execution during deep sleep periods, and the app could be terminated due to insufficient memory or third-party task killers.
If the approaches mentioned above do not yield the desired results, the definitive solution—if compatible with the app’s requirements—is to bring the app to the foreground [1]: when an app is in the foreground, the behavior of location updates is the same as in Android 7.1.1 (API level 25) and earlier versions. However, if an app retrieves near-real-time location updates for a long period of time, the device’s battery life will be significantly reduced.
Challenges and Considerations
It is important to note that all the alternative solutions come with challenges. For example, using Geofencing can result in significant energy consumption if the monitored geographic area is too large. Periodic scanning with WorkManager might not be suitable for apps that require continuous, real-time scanning. The approach with BroadcastReceiver and threads, while flexible, requires careful management of the app’s lifecycle to prevent the system from terminating the app.
Additionally, it is essential to thoroughly test the background beacon scanning implementation across different devices and Android versions to ensure reliable behavior and optimized energy consumption.
Conclusion
Scanning BLE beacons in the background on Android is a complex challenge due to the restrictions imposed by the operating system. However, several alternative solutions exist that developers can adopt to achieve the desired behavior. The choice of the most suitable solution depends on the specific requirements of the app and the limitations of the available techniques. It is important to carefully evaluate the challenges and thoroughly test the implementation to ensure an optimal user experience and acceptable energy consumption.
References
[1] https://developer.android.com/about/versions/oreo/background
[2] https://developer.android.com/about/versions/oreo/background-location-limits
[3] https://developer.android.com/about/versions/12
[4] https://developer.android.com/develop/sensors-and-location/location/geofencing
[5] https://developer.android.com/develop/background-work/background-tasks/persistent/getting-started
[6] http://www.davidgyoungtech.com/2022/06/25/the-rise-and-fall-of-the-foreground-service