I have 2 android applications A and B, and both of them are reading gps values based on different parameters. Considering both the apps are running on the device, which of the folllowing approaches would be better?
Both A and B are to be different apps, each one with a component to read from GPS.
To develop a third application with a remote service component to transmit GPS data to both A and B
Would battery usage be minimized by going for the second approach or will the GPS component read once and serve all processes, as in the OS?
Please help
There is a very good explanation given in the Android Developers Website about Location Strategies. I would suggest you to take a look at the code examples on the page.
In both of your approaches i believe second approach is quite better because Turning on/off GPS is a quite expensive operation in terms of battery usage.
GPS’s battery draining behavior is most noticeable during the initial acquisition of the satellite’s navigation message. Acquiring each satellite takes 12 to 30 seconds, but if the full almanac is needed, this can take up to 12 minutes. During all of this, your phone is unable to enter a deep sleep. A-GPS (Assisted GPS) partially solves this, by sending the navigational message to your mobile device over your cellular data network or even Wi-Fi. As the bandwidth of either of these greatly dwarves the 50bps of the GPS satellites, the time spent powering the GPS antenna or avoiding deep sleep is greatly reduced.
Referred from this.
I think the most battery-efficient way would be to poll the GPS location with app A normally, and in app B, use LocationRequests and use setPriority() with PRIORITY_NO_POWER. As mentioned in the docs, PRIORITY_NO_POWER will make app B get updates only when another app gets GPS updates (in this case, app A!!). I haven't tried it, but it should work. It definitely saves you the hassle of an extra app :)
Some more info on Google Play Location Services here and here.
is it the same as OS gPS component will run once to serve all
One GPS serves all.
There is no half GPS saving half the power.
But there are other location providers like cell tower and Wifi locationing which uses less power.
But if you need GPS it is absolutley no difference how many apps uses the GPS service.
If GPS is enabled it uses full power.
For the sake of compatibility and function I would suggest having a third process or program which reads and outputs GPS data, as multiple processes polling data from GPS is less efficient.
It would also be faster to have those two apps read the output of a single GPS tracking app and not needing individual components in each app to do so.
For the sake of power the GPS will use the same level of power regardless, though if it's polled more often due to two applications using it then it may use more - though the amount is likely to be minimal unless there are constant requests for location.
Though this may not be the question it would be most power efficient to have the third application poll GPS at specific intervals and the applications may read from its output rather than search location every time.
Second approach seems to be more appropriate but not sure about battery drainage.It depends upon how you implement it.
Also I would suggest try to use passive providers.Refer following link help it works :)
http://fypandroid.wordpress.com/2011/04/11/298/
Related
I'm building an app that track user movement. I found on the net and I'm still blocked about how to get a reliable user location.
For that purpose, I started by use the GPS_PROVIDER to get user location every minutes. But that drains a lot of battery.
Now I'm using NETWORK_PROVIDER which have better yield on battery, but as per my understanding, is not really accurate.
So firstly, I want to know to deal between usage of those providers to have good yield regarding battery consumption and user location accuracy.
Secondly, I read there (Significant Motion) that:
At the high level, the significant motion detector is used to reduce the power consumption of location determination. When the localization algorithms detect that the device is static, they can switch to a low power mode, where they rely on significant motion to wake the device up when the user is changing location.
Does it mean that this sensor is already used by GPS_NETWORK or that applications have to implement the described behavior?
Thanks
The link you provided (significant motion) relates to accelerometer, which you shouldn't be conncerned much when implementing location tracking.
What you probably need is Fused Location Provider API from Google Play Services, read more here: https://developer.android.com/training/location/index.html. It automatically merges data from GPS and Network providers, also synchronising access to location information between applications. It gives you fairly simple configuration options (how accurate location do you want? How often would you like to get updates?), and Play Services framework takes care of providing you with location in very efficient manner.
Since this is pretty extensive topic, I'll just refer to you documentation: the link above specifically this section. You should find plenty of tutorials too.
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'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.
I've been looking everywhere for an example of code that is a Service that update a web server on the users location. this is made almost impossible because of the use of the word 'service' as it is used in the context of location service, for example 'googles location service'. please can anyone point me in the direction of an example where a SERVICE gets the location and does something with it. I can send it to a web service so I'm not asking for that but I just want to know if there is a way of every certain amount of time and distance a service will update the web server?
Look at Android docs about obtaining user location.
You will have to make several decisions:
How accurate do you need your updates to be?
How often do you need them?
This greatly affects device's power consumption. Personally I loathe the apps that prevent full sleep and have GPS constantly turned on - this drains the battery in a couple of hours.
I highly recommend you look at this blog post: A Deep Dive Into Location. There is a link to a great example app.