We have been testing with Google’s major update to the Android Operating System, named Android Oreo since the first developer preview was launched back in March. Android Oreo was released to the public last week and it has a few nice optimizations. The idea is to restrict what an app can do while it is in the background to improve the battery life and the experience for the users.
An app can be in one of two states on an Android device.
Foreground: which is currently being executed and is interacting with the user (or) Background: an app which is not interacting with the user.
Apps running in the foreground can drain battery quicker, but that’s OK since user has made a conscious choice to play a game or watch a video and is expecting a battery drain. However, background tasks can consume some of device’s limited resources without interacting with user, the user has little or no knowledge of what these are doing and how much drain in battery.
Background Service Optimizations
To improve user experience, Android 8.0 Oreo (API level 26) imposes background execution limits, a mechanism which limits certain behaviors by apps that are not running in the foreground.
It should be noted that for the purpose of service limitations the definition of background is distinct from the definition used by memory management.
An app is considered to be in the foreground if it has a visible activity (started or paused), if it has a foreground service, or if another foreground app is connected to the app, either by binding to one of its services or by making use of one of its content providers.
This means that a music player is considered a foreground app since it will have a foreground service (with a notification for the status bar, placed under the Ongoing heading) even though the main UI is not in the foreground and isn’t interacting with the user.
When an app is in the foreground, it can create and run both foreground and background services freely. When an app goes into the background, it is given several minutes in which it can still create and use services. At the end of that time slot, the app is considered to be idle and the Operating System will stop the app’s background services.
What all this means is that if an app, say a social media app, wants to check whether there are new posts available, even if it isn’t running in the foreground, then it can no longer just use a background service which checks with the cloud, as this background service will be stopped under the background execution limits mechanism.
Background Location Limits
The Android Oreo limits how frequently your app can gather location in the background, regardless of the app’s target SDK version. Background apps will receive location updates only a few times each hour (location update interval may be adjusted in future). Foreground apps are not affected by these limits.
Given these limits, using foreground updates and foreground services are few of the alternatives to be considered for more frequent location updates. This involves displaying a notification to users denoting the use of location.
The changes to the Location APIs are positive in a broader sense as they make the app owners think deeply about how the location information is used. The app owners will also have the opportunity to tell their users through the notification about the ultimate value they deliver to the users.
Changes to the Bluedot Point SDK
The service infrastructure of the Point SDK for Android has been re-engineered to work with background service limitations and also it is a requirement to set a notification that appears in the notification tray to let the app user know of the use of location in the background.
If you are targeting Android O or higher API level, then call ServiceManager.setForegroundServiceNotification
API to set the notification, which will be displayed on devices running Android O and above. If the notification is not set, a non-fatal error is delivered to the app. Refer to ForegroundNotificationNotSetError for additional information.