I have an application that is a service and what I want to do is have the service kick on when the user is in motion, going faster then 10 mph (or whatever value I want).
What I don't want to do is keep polling the GPS because if I do that, the battery will drain fast.
What are some options that I can use to do this? Realistic options that will not drain the battery would be great! Thank for the help.
One way to minimize having to constantly be listening for location updates (GPS) is you could toggle location updates on/off based on feedback you get from the accelerometer. For example, when you break a set threshold of movement with the accelerometer, you could start listening for location updates and check to see if the device is moving fast enough. If not, you could turn off location updates.
There are optimizations here like "if the accelerometer threshold was broken less than 30 seconds ago, ignore" so that you do not end up thrashing with location updates being turned on and of.
Here is a developer example of Accelerometer Usage.
One idea without GPS would be creating something like a step-counter:
The user has the phone in his trouser pocket.
Every time the phone detects a shake, the user made one step.
You would then need to know his "step-length" and count how many steps he does in one minute. Then, you multiply the count of steps with the length of one step and you have meters/minute
1 meter / minute = 0.0372822715 mph
This would also work with using meters/second:
1 meter / second = 2.23693629 mph
Of course, this only works if the user is actually running/going/riding his bike and it's not very accurate. If you want to check the speed of him traveling by car or boat, this won't work.
One way you could do it is by Inertial Navigation, but this it is doubtful that the built-in sensors are accurate enough to measure anything significant.
Another way would be to reference distances between your device and Wireless Access Points, I was talking to a guy who said this method would be accurate down to a micrometer. However, it presents its own problems. Gets complicated quickly, especially if you're not moving in a straight line, plus you have to have some WAPs.
I think GPS is the most viable option.
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 have a question regarding my programming approach for android - whether it's efficient or not. Just to give you an idea what I try to accomplish:
There are multiple points of interests on a map. If the user gets nearer to a PIT, a notification about the distance shall appear. There are let's say 3 notifications: At a distance of 1 mile, 0.5 miles and 0.1 mile. When the user is more or less exactly at the PIT, no more notifications are shown. The user is supposed to drive a car or another vehicle.
I'm currently using Geofences to detect whether the user has entered a radius of 1 mile. If so, I check the distance of his current location to the PIT. If it's about 0.5 or 0.1 miles away, a notification is fired. Therefore, I check the current location frequently (right now every 10 seconds). If the user is like at the PIT or rather very close, the Geofence is exited and done.
The code is working fine and this approach is the first thing that came to my mind while reading the Android Developer's tutorials etc. But is there another approach that is MORE EFFICIENT?
Although this is (currently) meeting my needs, I have two major concerns:
It seems to drain the battery quite a lot. Since the user is most likely to be in a car where he can charge his phone during usage, this might be less of a problem.
I read the number of PITs from a file on the SD card. In my example I have just a few PITs. But the user is able to modify the source data so that he can add as many as he wants to. Google says that only 100 active Geofences are supported per user. But what if my user has more than 100 PITs? Since I'm using a Geofence to sense whether I have to fire the first notification or not - this is a severe problem. So is there an alternative?
I have a few suggestions :
1) To lower the amount of gps fixes, you could calculate a sleep time. The idea is to do frequent gps fixes when near a 'border' and few when far away. This could be further enhanced by taking the speed parameter returned by the GPS into account.
If for instance the user is 20 miles from the nearest border while driving 20mph, you can easily wait 30 minutes before turning on the gps again, just to give a simple example.
2) I have run in to the same problem. My solution was simply to select only the POI's within X miles. This way ensuring never to risk hitting the limit of 100. When the user has moved (X-1) miles from his initial position, the geofences are rebuild using the new location.
If you think there is a high risk of having such a high density of points that the above strategy still might fall, I would consider making your own proximity checking entirely based on gps instead of geofences.
I am developing an app, where I need (GPS) coordinates every couple of seconds, unfortunately the GPS uses a lot of battery.
Is it possible to get a good estimated position (including altitude) based on the last GPS position(s) and motion sensors from an Android smartphone, for let's say 1 minute?
What algorithms would I need to look into?
This does not work with GPS.
The GPS chip has to track the sattelites all the time, so it makes no difference for battery consumption if you get once a minute or once a second.
Things changes when you only need a position evry 5 minutes, then it could make sense to stop location service, and restart again. (but even that is only a vague estimation).
Finally you have to measure which intervall really saves battery.
bye the way: i can record 8 hours of gps with one fix per second, on iphone 4
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.
Using a GPS app I find that inside a car I get maybe 3 satellites with low quality signals. The GPS never locks and so nothing that requires GPS will work. The GPS app says that it gets 0 feet accuracy which means that an app that requires GPS would never be notified of a successful GPS signal.
In an app is there any way to get very rough GPS information when the signal quality is low? The app I'm writing would work very well if all I could do is get a rough speed and direction. I don't need pinpoint information.
I know I can use cell signals for location information, but that information is useless for getting speed and direction. I can't find any example code for using the accelerometer to get rough information, but even if I did it would only work if the app was started when the car was stopped (so it could detect the acceleration).
If I could get a very rough signal I should be able to calculate speed and direction, yet there doesn't seem to be a way to register a listener for that.
To get speed only GPS_PROVIDER can help. All you can do is to set minTime as well as minDistance to 0. i.e. requestLocationUpdates (LocationManager.GPS_PROVIDER, 0, 0, listener) Do not put any criterias. This will make best use of GPS hardware chip inside your android. This would however drain battery much faster. I had observed that after getting 1st GPS fix even if you move a little inside of room, the flow of GPS updates still continues, where it would otherwise never would able to get a fix. Regarding of getting direction while in motion, if you know the position of device inside car, you could consider of keeping track of accelerometer readings, and with the help of orientation listener check on which axis you get the jerks more, then this will give you the direction of motion.
Technically, if you can get an okay signal from 3 satellites, you can get a fix. I'm not sure if such a low-quality fix is enabled on Android or not, but it is possible.
Regarding the accelerometer, it is not accurate enough to get an idea of direction. You will find too much noise, if anything from vibration.
Perhaps you should interface with a bluetooth GPS on top of the vehicle.
I'm not aware of any way to get a 'low quality' signal. In my own app I've noticed that GPS normally receives its first fix once I have 6-7+ satellites but this could vary (I've never seen a fix with only 3).
You really can't determine if you have a fix based on how many satellites are connected to.
I think you need four satellites to get a proper GPS reading (one for each variable in the GPS equation), but many of the Android devices on the market have access to the magnetometer. If you calibrate it (waving in a figure-8 for 4 or 5 cycles), you can get a pretty accurate direction determination using the "compass".
Other than using the GPS, I don't know of any technique of calculating speed.