Broadly speaking, a runnable app (meaning one that has been loaded into memory and can be executed) can be in one of two states on an Android device: it is either a foreground app, which is currently being executed and is interacting with the user; or it can be a background app, an app which is not interacting with the user.
Foreground apps can be battery killers, but that is OK, as the user has made a conscious choice to play a 3D game or watch a movie and is expecting a related drop in the battery level. However background tasks can be more insidious. Since they are not interacting with the user, the user has little or no knowledge of what these apps are doing and how much they are draining the battery.
Don’t miss: Our comprehensive video overview of Android Oreo
To try to limit the damage that background apps can do to the battery level, Android 8.0 Oreo implements background execution limits, a mechanism which limits certain behaviors by apps that are not running in the foreground.
At this point it is worth mentioning that the terms “foreground” and “background” here take on slightly different meanings compared to the more traditional definitions used by the memory management systems in Android.
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 Android 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. Instead the app should replace the background service with a scheduled job, which is launched periodically, queries the cloud, and then quits.
Apps should replace the background service with a scheduled job, which is launched periodically and then quits.
Job Scheduler
Android Oreo introduces a number of improvements to the JobScheduler, which are designed to help apps move from using background services to scheduled jobs. The JobScheduler is an API for scheduling various types of jobs that will be executed in your application’s own process.
The biggest change in Android 8.0 to the JobScheduler is the inclusion of a new work queue. When a job is running, it can take pending work off the queue and process it. This functionality handles many of the use cases where previously an app would have used a background service.
Many apps with background services would have used IntentService, a class based on background services that handle asynchronous requests on demand. Now with the Android Support Library 26.0.0, a new JobIntentService class has been introduced, which provides the same functionality as IntentService but uses jobs rather than background services when running on Android Oreo.
Finally, scheduled jobs now support several new constraints including isRequireStorageNotLow(), which ensures that a job does not run if the device’s available storage is low; and isRequireBatteryNotLow(), which stops a job from running if the battery level is low.
By default Background Execution Limits only apply to apps that target Android 8.0, but users can enable these restrictions for any app from the Settings.
Wrap up
The reasoning behind these changes is to stop over zealous apps taking up too many system resources while in the background. What is interesting is that by default Background Execution Limits only apply to apps that target Android 8.0. However, users can enable these restrictions for any app from the Settings, even if the app was built for a version of Android prior to 8.0.
The result of this is that Google is essentially forcing developers to abandon background services and instead use the more “smart” and controlled JobScheduler.
What do you think, are there any popular background apps that should be curtailed a little? Any apps that you would like to see move over to the alternative job mechanism?
source: http://ift.tt/2vbNhik
http://ift.tt/2vmiu1r