Develop Reference

Activity Recognition Client battery comsumption

I wish to use for my app ActivityRecognitionClient, and I wish it will run always in the background. But how much battery actually it consume and what is the best interval for battery optimization?
In the reference it only says
"Larger values will result in fewer activity detections while improving battery life. Smaller values will result in more frequent activity detections but will consume more power since the device must be woken up more frequently"
Can you tell me in real life how much it will consume per refresh rate?

It is nearly impossible to correctly answer this question because the answer is a resounding "it depends."
The amount of battery power that a particular action will consume on a phone is difficult to determine because there are a ton of different factors that play into it.
First, Android attempts to batch many types of requests such as this together, so if 10 different apps wants to detect updates ever 5 minutes, it will only do it once every 5 minutes instead of 10 times every 5 minutes. Which app and which action is responsible for that?
Second, activity detection relies on whatever sensors (and models of sensors) are available on the device. Different devices have different GPS chips, accelerometer chips, etc. Some devices may not have all of those types of sensors as well. These all change the amount of energy activity recognition will consume.
These are just a few of the reasons it is difficult to determine how much energy an update will consume.
The answer for "how often should I request updates" is "as infrequently as your app can tolerate." Think about your use case and the general statement that more frequent updates will consume more power, and make the appropriate decision from there.

Battery impact of polling for location updates less often?

I've read a lot of conflicting information on this.
Suppose I use the Fused Location API in PRIORITY_HIGH_ACCURACY mode, does it make much difference if I set the interval to, say, 10 minutes vs 1 minute? 1 hour vs 10 seconds? If so, how drastically?
I don't know how it works internally so I'm just wondering what I can do to save battery if I need high accuracy location (and relative infrequency of polling isn't an issue).
https://developer.android.com/training/monitoring-device-state/index.html
The developer site has advice on how to save battery but they don't seem to give any concrete information on exactly how much polling frequency affects battery life.
Does enabling the service keep the GPS on all the time and therefore always using battery (and so the interval would be synthetic and solely for programmatic reasons)?
Thanks!

For Fused Location API, I'm not certain if they turn off GPS or adjust reporting interval while leaving it on, but I would assume they turn off GPS between updates, or else many others would complain about power drain.
As for what Android Location Service does, they do turn off GPS and allow the phone to idle between updates if the interval is greater than 0 (check out the source in LocationManagerService). I've done quite a bit of power testing on different android phones, and found that keeping the CPU from idling can draw a noticeable amount of power. Add the power draw of GPS (which keeps the CPU from idling) and you are looking at a decent power drain (about 50% of what the screen would draw for some devices).
In the end, I'd have to agree with Gabe Sechan and advise you on choosing whether accuracy is worth the battery drain. Just ask yourself these basic questions:
Do I need to know if my user is on one side of the street or the other?
If yes, use GPS, else use Network or low accuracy location.
How often do I need to check my user's location?
If you need it about once a minute, set your interval as such. If you only care when they leave a general area, setup a geofence, or use network locations. You can also listen to location updates from other apps, and make your app smarter about when to take updates.
If I can't get my user's location within X amount of time, can I skip this update altogether?
If you can, then put a timeout feature in your update logic. If not, I strongly recommend you re-evaluate the app logic in that case.

Battery consumption using android iBeacon library - short but regular scans

I only need a rough guide on this really at this point, though specific calculations would obviously be welcome too!
I'm looking at using Radius Network's Android iBeacon Library in an app which will listen for iBeacon advertisements.
I'm new to this but from what I understand it's the scanning for BT devices which is the most battery intensive part of the BLE system so it's not advised to have this running constantly, however I would like to be able to 'catch' devices when they are in a certain area, i.e. a person walking through a lobby.
The Android Beacon Lib's documentation states that the Battery Manager's default setting scans for 30 seconds every 5 minutes (actively scanning for 10% of the time) and this reduces the battery drain on a Nexus 5 from roughly 90mA to 37mA.
My question is... would scanning for 3 seconds every 30 seconds (also 10% of the time) acieve the same battery savings? Or is there an overhead involved in starting the scanning process which would mean the savings would be less? and if so by how much?

You would have to measure to be sure, but I would suspect you would get similar power savings from the cycle you describe (it may be slightly less savings because of startup overhead as you suggest.)
The disadvantage of this approach is that you may miss detections in a 3 second interval, especially in areas with lots of beacons, distant beacons, or with beacons transmitting infrequently. You have to decide if it is worth the tradeoff.
To test power savings, do the following:
On a test device, uninstall as many apps as possible to limit background activity that might use power in unpredicatble ways.
Install an app that implements background scanning on the cycle you describe and start it on your device.
Charge the battery to 100℅
Turn off WiFi and mobile data to prevent system downloads from using power in unpredictable ways.
Note the time, turn off the screen, and let the device rest, checking it every hour or so for battery level.
When the battery reaches 5%, note the time.
Repeat the above test with the app doing a constant scan in the background.
The end result of the above procedure will give you the time it took to drain the battery in both cases. From this you can calculate the percentage difference in power savings.
Please let us know what you find!

What is the most battery-efficient way of monitoring proximity to a number of locations in Android?

I have an app which will take some (internet) action every time the user approaches any one of a set of locations (for example, let's say it notifies a server whenever I am near a Starbucks shop, so my coffee habits can be analysed).
What's the most battery-efficient (yet reliable and relatively accurate) way of causing the phone to do something whenever it's at a certain location? I don't need perfect location accuracy - within 50m or so is fine.
Currently, I set a ProximityAlert for each location with a 100m radius, and have it raise an Intent, which is then served by a Service which runs in the background. The service also includes an Alarm which causes a download every three hours or so.
The Service itself doesn't appear to drain any significant amount of battery - the battery is all drained by "Android OS". According to the Android 4.1.2 Battery monitor, Android OS is using 3x as much CPU as a phone without my app, and has "stay awake" on for most of the time.
Would changing it to an IntentService make a difference?
Would reducing (or increasing) the radius of the alert make a difference?
Would converting it to a Geofence (https://developer.android.com/training/location/geofencing.html) make much difference?
Can I set it to use a cheaper location service unless it thinks it's close to one of the locations (or will it do that automatically?)

I have never worked with the LocationManagers proximity alert functions, so I do not really know how much they drain the battery, but as far I know the new Geofence services (https://developer.android.com/training/location/geofencing.html) were specially designed in a battery-friendly fashion.

LocationManagers pose a very difficult way to program something that you need. Google has reinvented its location providers to fuse them with sensors. Its the latest and best, uses less battery and does magic with your application, by removing all the 1000's of lines of useless code that you need to write between your gps / network providers.
The new api's are LocationClient api's. Watch this video and demo for yourself.

you can use new geo fence api provided by the Google recently,its more power efficient
https://developer.android.com/training/location/geofencing.html

Background GPS Polling from Web Service

I'd like to know if this is possible on either Android or iPhone:
I would like to have an application run in the background of the phone and send a GPS location to the server every N minutes. As far as I know this is difficult on the iPhone, but can it be done on an Android?
Thinking a bit more on the iPhone - could I create a web service that runs timers for each application and, on timer elapse, push a notification to the phone to start the GPS service and send the location information back to the server? Can I push notifications to an iPhone application in the background?
Thanks!

Re Android: yes, this is also possible, and just as with the iPhone, the less accuracy you need, the faster this will be. It is also asynchronous , so you will need a similar approach. As opposed to the iPhone though, you can start the GPS and wait for location updates in a background service, so that you can send the current location to the server whenever you have it.

Re iPhone: yes, you can push notifications when the app is in the background, but you should know that the location services API is an asynchronous API (having been working on it myself...:)) so you can't time it per se (you can for example "expose" it every N seconds, saving the last location that was provided - so essentially implementing a logic that will make it asynchronous, but with a certain cost to the user experience).
Also note that having location services running in the background is a huge drain of battery. here it really depends on the type of application that you are building. If you dont need high accuracy (say, knowing the city is enough) you could set the accuracy of the API to be large, which wont trigger WiFi and GPS, and will use only cell - less battery drain. If you need really high accuracy (street corner, etc.) this wont be super useful for you.
Adding some more info for your convenience: like I mentioned, accuracy requirement will trigger the different location services, which in return affect batter consumption. In general the accuracy is:
GPS: ~10 meters
WiFi: ~100 meters
Cell: 500 meters (urban canyon environment) to 50Km (in open environment)
Hope that helps.