Is location provider really a battery drain?

Question

I need to implement location-based service. I don\'t need fine location, so no GPS is needed.

Easiest would be to start listening for locations updates at app start,

Answer 1

There is a topic about this included in the Android Developers Guide. I would recommend that you take a look at the code examples on the page.

This is what they mention regarding conserving battery and various parameters.

Adjusting the model to save battery and data exchange

As you test your application, you might find that your model for providing good location and good performance needs some adjustment. Here are some things you might change to find a good balance between the two. Reduce the size of the window

A smaller window in which you listen for location updates means less interaction with GPS and network location services, thus, preserving battery life. But it also allows for fewer locations from which to choose a best estimate. Set the location providers to return updates less frequently

Reducing the rate at which new updates appear during the window can also improve battery efficiency, but at the cost of accuracy. The value of the trade-off depends on how your application is used. You can reduce the rate of updates by increasing the parameters in requestLocationUpdates() that specify the interval time and minimum distance change. Restrict a set of providers

Depending on the environment where your application is used or the desired level of accuracy, you might choose to use only the Network Location Provider or only GPS, instead of both. Interacting with only one of the services reduces battery usage at a potential cost of accuracy.

Basically, consider reducing the frequency of the updates you request or the length of time you request them. This is like golf, the less locations you request the better. Consider the following use case:

In the example the application waits until the user performs an action that needs a location and then stops polling once the location data is no longer needed.

While polling constantly would allow the application to have a location ready at an instant notice its simply not worth the wasted resources, to mitigate the delay when requesting a location you can use getLastKnownLocation (String provider).

Edit: There is a way to determine power usage for the various LocationProviders!

Calling getPowerRequirement () on a LocationProvider will return one of three constants.

int     POWER_HIGH  A constant indicating a high power requirement.
int     POWER_LOW   A constant indicating a low power requirement.
int     POWER_MEDIUM    A constant indicating a medium power requirement.

To make your code more readable look into using meetsCriteria (Criteria criteria) in any boolean checks to make your code more readable.

I would use this to determine what method your application should use for the lowest power cost, Also you have the benefit of supporting devices that have different power requirements for providers.

Answer 2

Your 100m distance filter will do little for you from a battery drain standpoint. That will only control how many times your PendingIntent gets executed due to fixes.

Your 10 second time value might be used by the OS to control power usage, but there is no guarantee. And, with that low of a value, it seems highly unlikely that it would be used. Every hour, maybe, but not every 10 seconds.

The bigger thing is that you will be needing to keep the CPU powered on all the time. And, since you're using the PendingIntent flavor of requestLocationUpdates(), I am guessing that you plan on collecting data for a long time.

If you only have COARSE permission, Android hopefully eschews the WiFi hotspot proximity detection, which will save a bit of power.

On the whole, the network provider will consume less power than will the GPS provider. "Less" is a far cry from "little". On a Nexus-class Android device, GPS + CPU gives me a few hours battery life (as determined by using Google Navigation). I would expect network provider + CPU to last a few hours longer, but that's about it, because the CPU is a fairly significant battery drain in its own right.

My bigger concern is:

Easiest would be to start listening for locations updates at app start, and leave it ON

This sounds like you aren't actually planning on removing your location updates. This is a really bad idea, with any sort of provider (except maybe the passive provider). Please have a more concrete plan for when you are registering and removing the updates. In particular, make sure the user has the ability to control when you are consuming battery to this degree.