i'm creating a location tracking app to let users plot a heat map of where they traveled throughout the day. this involves constantly gps querying the user's location, a battery-intensive operation. one way i thought to reduce the app's power consumption is to set up a geofence after a few location updates return roughly the same value, and shutting down the location updates until the user exits the geofence (signifying that they are once again on the move).
this will allow my app to only perform frequent GPS queries when the user is actually moving (triggered by them exiting a geofence).
however, i'm not quite sure if this will reduce power consumption, because if the geofence is triggered by constantly querying the user's location to see if they have moved outside the fence, it will have basically the same effect on the battery.
so my question is, how does the geofence know when the user has left/entered the area? is it based on simple periodic location queries? or is there some more clever mechanism involved? thanks!
link to current version of app:
https://play.google.com/store/apps/details?id=com.russ.locationalarm&hl=en
The way Android is handling geofencing is quite complex. There are many differences between devices, but also between Android versions. But as a quick answer, your solution could save battery, because detecting a zone exit don't necessarily require GPS, but could use other location methods like Cell ID or Wifi, which are much less battery consuming. You also need to know that geofencing is not a 100% reliability solution, in particularly on Zone Exit events (less than 50% of zone exits detected in average), that are less reliable than Zone Enter events. Some companies like Herow, Radar, Foursquare are building SDKs that manage specifically geofencing.
Related
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.
I'm trying to send a notification through my iOS and Android apps when a user walks through the front door of a restaurant. I've tried Geofencing, but the minimum radius isn't small enough and people will get notifications from multiple restaurants in the area. I know iBeacons exist. Are they my only option? (I know Foursquare sends these kinds of notifications, but I don't think they use iBeacons.)
Beacons are much more accurate than Geofences, but they still have a range of about 40 meters. In a dense urban area, beacons might still trigger notifications from multiple adjacent restaurants at the same time. You might also trigger the notification as the user walks by on the sidewalk. There are ways you can lesson the likelihood of this by placing beacons inside the restaurant so the signal is very weak outside. But you cannot eliminate it.
The Foursquare does use beacons. I know this because the Android version of their started being bundled with the Android Beacon Library about two years ago, and I'm the lead developer on that open source project. That said, I suspect they use a combination of geofences and beacons, only using beacons for cases where customers actually have them installed.
Geofence-based notifications are especially problematic on iOS because geofences often fall back to location from cell towers to save battery when no location apps are in the foreground. Cell tower locations are only accurate within a kilometer or two, and will trip a geofence of the outer range of the location uncertainty overlaps with the geofence. This can trigger a restaurant welcome notification from over a mile away.
One way to improve bad Geofence-based notifications like this is to use the following technique on iOS:
Request an extra 180 seconds of background running time when the geofence is tripped.
Request location updates with GPS, and monitor these updates for 180 seconds in the background.
Using the location update data, if you find that the accuracy of the fix is high enough and the distance from the restaurant is small enough, then trigger the notification. Until and unless this happens, don't trigger it at all.
You would need a beacon inside the restaurant already, otherwise geofencing is going to be your only option. You could combine geofencing with a gps call and see if the gps call is within a lat long you have deemed to be inside that establishment, and then repeat this gps call every few minutes while you are inside the geofence until it matches a coordinate inside the place.
The disadvantage to this approach is that the battery drain will be higher than using ibeacons, which operate using BLE (bluetooth low energy)
I'm trying to know when your device leaves your home, but I don't need fine GPS location nor high update rate (i.e. it's fine if I know the user is out only 10 minutes after he left his home and he's already 100 meters away).
Which of the two solutions should use less battery (both should use already less battery than plain GPS location listener)?
Receiving Location Updates | Android Developers with PRIORITY_BALANCED_POWER_ACCURACY
Creating and Monitoring Geofences | Android Developers
The first is for sure using a more battery saving solution and I can control the frequency to be low.
The second is a higher level API which does just what I want but I've no idea what it does and it looks like it'll use fine GPS location constantly while the user is within the geofence (remember I want to reduce battery usage).
Anyone has some insight on this regarding mostly battery usage?
The answer here might be a combination of things. The Location and battery Drain video explains more about how the GPS & Location chips burn up battery in your device. (Battery Drain and Networking will detail how the Radio chips work.)
Basically, using a FusedLocationProvider will allow you to scale back accuracy vs. power drain. Basically less-resolution results in less battery drain.
Knowing that, I'd suggest a set of low-power checks as early-warnings before moving to the higher-power checks:
Use ConnectivityManager to determine if the mobile device is on the CellularNetwork or not. If they are, there's a good chance they've moved outside of the wifi boundries.
Check if the WiFi they are connected to is the common home WiFi (so you don't mistake the coffeeshop wifi as home).
Use a back-off system on your checks. If the user is home, chances are, they will be there for a while; so scale back how often you check position.
If the user is on Cell network, use a Course Location to determine if you're within 100ft of your known home location.
Use a Fine location check to resolve issues / corner cases with the Course Location check.
When all else fails, do a Geo Fencing check; but then turn it off as soon as you've resolved the issues.
Basically, you want the least-power draining options to run the most often, and only use the most power-draining when you're resolving discrepancies in position.
There are a few hints in the documentation that Google wants you to use the Geofencing (or the new Awareness API) for your use case.
The first method need to be triggered from a LocationRequest, and from
https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest
Activities should strongly consider removing all location request when entering the background (for example at onPause()), or at least swap the request to a larger interval and lower quality.
This shows that this API is designed to be used only when your application is active, hence the "Request" term.
Google soon realized that a lot of apps (including their own Google Now) are requesting for location in the background, and they want to improve it in such a way that the requests can be pooled and shared, hence they created Geofencing and eventually Awareness API.
From the Fence API document,
https://developers.google.com/awareness/overview#fences_and_snapshots
Fence API lets your app react to the user's current situation, and provides notification when a combination of context conditions are met. For example, "tell me whenever the user is walking and their headphones are plugged in". Once a fence is registered, the Fence API can send callbacks to your app even when it's not running.
So, in your use case, if your app is not running, you should be using the second method.
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
I'm creating an app wherein I'm need to perform an action when I'm within a certain radius of a location. But I don't want to be continuously polling the location because that'll drain the battery.
I thought about just putting an option for the user to specify how often to query the location. However, I'm concerned that if the user sets it too long, then my app will miss performing the action when it's near the location.
I in one Google IO session that Pay With Square had an auto tab feature, I'm not sure if they're constantly polling the location, have setting for the delay between querying the location or a third option that's efficient without draining the battery.
I would like to ask for suggestions on how to approach this.
Thanks in advance.
It looks like your question actually is: "how can I get an accurate position measurement while saving the battery of my device?"
There are mainly two ways to save battery AND have a good positioning:
Do not use GPS (that is a real battery hog)
Set a large interval between poll actions
You can get a quite good positioning (from 40 to 150m radius, that is better than GPS in many cases) using only the wi-fi and phone cell data. Just select "ACCURACY_COARSE", "ACCURACY_LOW" and/or "POWER_LOW" as a provider selection criteria in your code.
See the following links at Google Developer's web site:
Location Strategies
Location and Maps
LocationManager
And in particular these two:
getProviders
Criteria
You can select/set a battery-saving poll interval on the basis of the measured speed of the user. If the user is walking (less than 5 km/hour), you can use a 30 - 60 seconds interval without any risk to miss your alert. If the user is traveling by car (more than 50 km/hour) you will have to set a 1 - 10 second interval. Consider that location space accuracy is usually quite bad (100 m or so) so it does make very little sense to try to "cath" the point with a very high time (speed) accuracy.
Have a look at Google documentation for this, as well.
In any case, Google explicitly suggests to NOT try to save battery using your own code and rely on the getProviders criteria for this.