For all of their technical razzle-dazzle and their abilities to perform seemingly countless tasks, there is one area where Smartphones fall short – Battery Life. Android devices are not immune to this. When you compare the battery life of a typical Android OS powered device to a standard cell phone, the ordinary phone keeps chugging along while the Android phone will likely need a recharge over the course of the day with typical use patterns.
Even those users who take care to fully charge their devices each night find that they are running out of juice before the end of the working day. Users do have the ability to reduce the energy drain by limiting usage of power-hogs like viewing videos or processor intensive applications like games, but the Android App Developer can also reduce the power suck by thinking proactively.
Beware of the Power Vampires
It’s no great secret that processors need power to operate. That’s true on a PC, and it’s certainly true on a SmartPhone or Tablet, be it running Android or iOS. But unlike our trusty desktop behemoth, our mobile devices are intended to be mobile and unplugged. So that battery power supply is a finite resource.
When developing an app for Android, one of the prime power suckers can be an overuse of the Location Based aspect of the operating system. Certainly a GPS type of application would need to make fairly constant calls determine the location of the device, but other apps might only need to determine the location on a limited basis. Too many calls to determine the location could result in excessive power drains, and worse, compel the end user to delete the app and post a negative review. Those negative reviews can reduce future adoption rates and that means lower sales of that app.
The Location API and the Location Update Request
With Great Power comes Great Responsibility, right? We’ve all heard that before, but when we look at it from an Android Development point of view, one could revise the quote to something like “Great Power Usage is Our Great Responsibility”. Okay, not the greatest turn of phrase, but the point is that it is up to the Android App Developer to only access resources that an app really needs to offer functionality to the end user.
In the code example below, there are some serious problems that would result in a far more rapid power drain than what is needed.
If you’re not seeing the problems, they include:
- Location listeners which are not unregistered.
- Location updates which are probably occurring too often.
- Location updates are requested from multiple providers.
Yes, the code it technically bug free, but in the real world, the end user will see their battery level going down at a rapid rate of speed. This is not good.
Before we address some potential fixes, let’s first be aware that there isn’t going to be one solution that will suit every possible use case. Your app might need to access location more often than another one might. So, take these fixes with a grain of salt.
Unregistering a Listener
First ask yourself – does your app really need to constantly listen for a location update? If not, consider accessing the location upon app load and then stop the constant listening for the location, as seen below:
Adjusting the Frequency of Updates
There are two key parameters that will determine how often the location information needs to be updated:
- The minimum time duration between updates
- The minimum distance moved between updates
Here’s some code to show how that works:
There are the location providers available within the Android operating system.
- GPS (Global Positioning System)
- Network (using Cell-ID and WiFi locations)
- Passive (since API level 8)
The GPS Location Provider (
LocationManager.GPS_PROVIDER) is typically the most accurate of the three as it provide a horizontal accuracy of approximately 11 yard (10 meters).
The Network Location Provider is not as accurate as the GPS Location Provider. Its accuracy will depend on how many cell towers the system can use to compute the device’s location. Typically the locational information is somewhat more accurate when polling from a WiFi signal, but this still isn’t as granular as is GPS.
The Passive Location Provider doesn’t request location information directly. Rather it updates when other apps, services or system components request location information.
There are pros and cons to each of these location providers. GPS is the most accurate, but it can take the most time and energy to provide a location. Keep in mind that this provider needs to lock onto multiple satellite signals. In an open field this might take a few seconds, but if the user is indoors or in a parking garage they may be precluded from accessing any signal. Even when a signal is available, structural elements can delay getting an accurate position by up to a minute.
As noted earlier, the Network Location Provider requires access to cell signals or WiFi. In the case of cell signals, the device needs to triangulate against multiple towers in order to increase accuracy. With no signal of either type locating the device becomes impossible.
The Passive Location Provider may be the best choice when real-time location information isn’t required by the App. When used in your application, it is effectively telling the Android operating system that “I’m interested in getting location updates, but you only need to tell me when another app, service or component is getting that information.”
When you use the Passive Location Provider, your app isn’t placing an additional strain on the device by continually polling for the location. That, in turn, reduces the power consumption driven by your app.
Leverage the Last Known Location
In addition to the Passive Location Provider option, the Android developer might want to include code that checks to see if a location is already known by the device and cached by the system. The best way to do that is to use the LocationManager class. The LocationManager class defines the getLastKnownLocation() method, which returns the last known location for a given provider.
Admittedly there is a risk to this, as the location may be out of date, but the tradeoff is that the stored location can be retrieved instantaneously and calling this method won’t start a provider.
We hope that this helps Android developers as they seek to create applications that are useful but are not resource hogs. Tell us what you think in the comment section below, and please share this blog with your peers.