X

Tech Talk: Google's War Against Power Consumption

Featured image for Tech Talk: Google's War Against Power Consumption

One of the biggest problems with smartphones is not the size of the screen, how well the camera works when it’s getting dark, or cellular data coverage – but instead is how long the device lasts on a charge. Part of the problem is that as devices become more and more capable, as we add more applications and as each becomes more and more sophisticated, we are placing greater strain on the battery. It is possible to disable many of the smart features that make our smartphones so useful, but then we are arguably as well to buy a feature phone instead of a smartphone. At the recent Google I/O Developer Conference, Google outlined some of its plans with how to optimize battery life for Android. We’ve already seen some of the improvements to power management to be introduced into Android N but it might surprise you to learn that Google’s primary weapon against power hogging applications is a technology introduced into Android 5.0 Lollipop: the JobScheduler API.

This JobScheduler code is an activity scheduler designed to improve the network power efficiency of applications by cooperating with one another and the operating system. Developers are able to determine when their application should connect to the Internet within a time frame and the operating system considers all such requests, then manages the connection to the Internet and allows applications to connect and sync their data. The advantage of this is that it is more efficient to combine network activity into one brief moment rather than allowing applications to connect as and when they want. Each time the device connects, it performs what is known as a “wakelock,” which is the Android equivalent of rapid eye movement. The screen is off but the handset is working away. Wakelocks consume battery power.

Android 6.0 Marshmallow introduced App Standby and Doze, two technologies designed to reduce battery use by preventing applications from waking the device when either they have not been in the foreground for some time, or when the device has been idle, respectively. Both the App Standby and Doze functions may be considered in a sense to enforce a crude version of the JobScheduler by suspending network activity. Doze merits special mention because although technically clever, there is a major flaw in how Google implemented it for Android 6.o Marshmallow. The operating system will only drop the device into Doze mode when the device is stationary, and even then after over 30 minutes of idle time. Android N implements a new lighter touch Doze mode, which is triggered five minutes after the screen has been locked but the device may still enter a full Doze state after the requisite thirty minutes if it is not moved.

We have already alluded to how the JobScheduler API introduced into Android 5.0 can be used by developers to reduce battery use. A key point here is the word “can,” because currently it is optional. Indeed, when Google asked the developer audience how many had heard of the scheduler functionality, only half raised their hands. The reason for this? Because there are other (easier) ways to control how an application syncs data. How is Google going to encourage developers to use the JobScheduler code? Quite simply by removing the easy alternatives!

Current versions of Android have a number of implicit broadcast notifications, which may be used by developers to trigger actions. These include the device being plugged in or changing network conditions. Depending on the application, these can be used to start background activity: should a device be plugged in, an application may receive this notification and immediately start to sync data. In isolation, this technique has worked well, but not many users have just a few third party applications installed onto their device. The more applications installed that use implicit notifications, the more activities are launched at the same time and the poorer the user experience. By removing these implicit notifications, Google is encouraging if not forcing developers to use the JobScheduler code to launch a background service. This means applications will cooperate with the operating system when it comes to managing background services and activities.

The benefits of this is that Android will prioritize tasks and services according to foreground application use and available RAM. This means a smoother user experience, especially on lower end devices, as it should reduce interface lags when a background sync takes up computing resource when we are already using the device. The operating system will coordinate when applications can communicate with the network, aiming to run as many network tasks at the same time so as to reduce power consumption. Android will become a smarter operating system and it will result in fewer wakelocks and better battery life.

Android N will see more changes and improvements to battery management. These changes are part of Google’s evolution of battery management, which is going to unfold over the coming years. Google alluded to their plans in the video below. But what about devices running Android 4.4 Kit Kat or older? Not to worry as Google and Firebase are building the Firebase JobDispatcher, which will effectively port back much of the JobScheduler functionality into the older versions of Android via the Google Play Services application.

Google IO Battery 13
Google IO Battery 12
Google IO Battery 11
Google IO Battery 10
Google IO Battery 9
Google IO Battery 8
Google IO Battery 7
Google IO Battery 6
Google IO Battery 5
Google IO Battery 4
Google IO Battery 3
Google IO Battery 2
Google IO Battery 1
Google IO Battery 13
Google IO Battery 12
Google IO Battery 11
Google IO Battery 10
Google IO Battery 9
Google IO Battery 8
Google IO Battery 7
Google IO Battery 6
Google IO Battery 5
Google IO Battery 4
Google IO Battery 3
Google IO Battery 2
Google IO Battery 1