I've found
several
different
SO
posts
on conserving battery life with Android's
FusedLocationProvider API.
What I'm looking is a way to intelligently select the most location accurate provider, given the state of the host's battery and some knowledge of the power drain of each one (e.g. something like this). In other words, if the battery is nearly dead (for some predetermined value of "nearly"), the service would ideally know to avoid GPS, since that burns a lot of power, and instead use either CellID or WiFi. But I don't see anything in the FusedLocationProvider documentation along these lines.
Is there a way to do something like this with an existing API call, or would I need to roll this myself? Thanks in advance for any pointers.
The screen uses the most power.
if user is on long strech of straight high way you only need to monitor accelerometers and dead rreckon position.
Related
What is the best way to log GPS position (or data, to analyze) that wouldn't consume whole battery in few hours on Android? Is there some special way? Some of the tracking software available on market claim to be optimized for low battery usage.
No matter what exact approach to the code you use (e.g. service, some library, or code your self, etc, etc)... it will ALWAYS narrow down to one question:
How much resolution and how often updates are you requesting?
That's because no matter how it's coded, it will always relies on the same sensors (the GPS, wifi n tower triangulation) that is attached to the same physical hardware, and same battery.
So, general tips for better battery life is to get positions less often, to be ok with less accurate positioning, etc.
The Google Location Services (available on any device that uses Google Play) is a great time saver and it's also a very well optimized piece of code. If you want some example on how to use it feel free to check this app I did in a boring Sunday afternoon:
https://github.com/budius/photogpstag
https://play.google.com/store/apps/details?id=com.budius.photogpstag
In that I optimized for a person walking and taking photos, meaning every 3 or 5 minutes would be a good enough position and have a good lasting battery.
You can grab the source code and change the request parameters to higher accuracy/more often updates and see that the battery drain will increase.
I am trying to get the user's speed from their Android device, but which is the most reliable way to do it?
There is the location.getSpeed() function that uses GPS; is this a reliable way to obtain the speed? Should I instead calculate speed manually using GPS coordinates obtained? Or is there another way that I'm missing to accomplish this?
IMO, best current approach on Android is to use Location.getSpeed() along with the Google Services Location API and the fused location provider. Then, reality-check this value against Google Play Services Activity Recognition.
The fused location provider integrates some other on-board sensors to tweak location data, which is better than GPS alone. Then, check the ActivityRecognition.getMostProbableActivity() method. If the DetectedActivity is type STILL, your true speed is probably equal to 0. If its ON_FOOT, it's probably a low speed (e.g., 1 m/s). If its ON_BICYCLE or IN_VEHICLE, you're probably fine relying on the speed output obtained directly from Location.getSpeed(). You'll also want to check the DetectedActivity.getConfidence() value too, and set your own threshold for a confidence level you feed "confident" with :) when relying on these values.
I'd also definitely suggest that you do NOT simply average sequential positions to get an average speed between two position (if you do this, it needs to be an average over a large number of positions). In my benchmarking on mobile devices (see my dissertation here, pages 105-106, and 137-138 especially), I've found instantaneous speed calculated by the GPS subsystem (which is typically based off of the Doppler shift of GPS carrier signals) to be far more accurate than the positions derived from GPS. 95th percentile of speed observed while stationary indoors (using assisted GPS only, no sensor fusion) was 1 m/s on a Sanyo Pro 200 I tested. I was able to filter out a significant number of position outliers using speed data (see page 137-138) in some intelligent energy management techniques I was evaluating. With sensor fusion, and activity recognition to help filter outliers, accuracy should be better than this on a similar device.
Finally, and I can't emphasis this enough, do you own testing on real devices, as many as you can get a hold off, and preferably the most popular models out there. Android has a variety of OEMs putting out devices, which will all have their eccentricities. Your best bet it to create a solution that targets the most popular models, acknowledging that it's unrealistic to get a solution working perfectly on all models.
It seems that the getSpeed() method is not always reliable, especially at low speed and when gps coverage is not optimal.
You can have a look at this question and this one which are both about alternatives for getSpeed().
The android developper page however says that you'll get better performance by using the Google Location API.
So it appears that the choice is depending on the usage of your app: if you target slow displacement in area with poor gps coverage (walking in the wood), use your own implementation. Fast in area with good GPS coverage, use the Google Location API.
The best way for devices that are moving faster than walking speed, is to use directly the location.getSpeed().
For pedestrian, or other slow speed situations, this is not quite easy, maybe it is simply impossible to have a valid slow speed that is valid at the moment.
Some try to evaluate the history and do an averaging, or threshold based approach, this will improve for a specific application / usage.
But the simplest is to design your App to ignore low speeds.
Some links related to speed:
GPS position correction
Smooth GPS data
I need to get statistics about the battery in milliAmpere.
I've already found how to get the battery percentage and voltage but not the current.
There are applications like this that can do it but i wonder how.
Thank you
I believe the only way to get the current is via the logcat. The system will occasionally post it to there so you'll need to go back find the last update for it.
There is no way of measuring current drawn from within the system - this or any other app can only estimate it based on timing information and voltage discharge that the system reports. You are not likely to have anything accurate based on just that though - to have more accurate information you need an accurate device power model.
There is a nice article by the Android framework guys about how the power model is built (also applies to the built-in battery power monitor).
TL;DR
Measurement can be accomplished using a bench power supply or using specialized battery-monitoring tools (such as Monsoon Solution Inc.’s Power Monitor and Power Tool software).
Need to control what components of the device are active (screen on/off/brightness level, cellular/wifi/bluetooth radio, gps, CPU, etc.)
Based on those you build an energy profile similar to the example at the bottom of the page
There are also typical values in the table in the document. Warning: these are highly hardware-dependent
You can then apply the model by monitoring the state of the device and activities of applications (screen state, foreground/background, CPU/network use by an app, etc.)
This is a lot of hard work (sorry about that :) ), but there isn't another good way - it is actually an active research problem...
How to calculate speed without requiring GPS? I have heard of something called "sensor technology" but am not sure what that means. I am asking because I want to make an app, but I don't think it is battery efficient to use GPS, plus it is for a long-term project so I want the app to continuously run without having to manually turn it on or turn on GPS.
GPS is by far the most accurate way to do this.
You can get access to the accelerometers, but they are not remotely accurate enough for this type of application.
The only other way I can think of would be to get one of those bluetooth adapters that you plug into your car's diagnostic port, and get the speedometer input from there. Then, you're wasting power on bluetooth as well.
Just buy a power adapter for your phone to run on the vehicle.
I tried to measure the speed using Android's accelerometer sensor for an indoor-navigation project but that failed miserably. I intented to derive the current speed from the acceleration/deceleration over time and so in the end calculate movements along the X, Y and Z-axis, but that didn't work out at all. The accelerometer sensors of common Android devices are way too inaccurate for that kind of usage.
So, you will have to use GPS. To reduce battery drain, you can increase the intervals (time and/or distance) in which the LocationManager notifies your App. See the minTime and minDistance parameters of it's requestLocationUpdates() method.
Android allows you to use cellular phone antennas and wi-fi access point antennas as reference points to determine your current location without using the GPS (see: locationManager.NETWORK_PROVIDER).
Once determined your position in two different moments/points you can easily calculate your speed in your code.
I don't think one can calculate speed without the assistance of GPS. Speed depends on distance and time. I am not sure if we can calculate distance just like that.
Anyway look at http://developer.android.com/reference/android/hardware/Sensor.html
There we have different sensor types. Perhaps you can make use of one of those.
I think what you are referring to would be considered "dead reckoning" (http://en.wikipedia.org/wiki/Dead_reckoning) and is possible, but will lead to drift and incorrect speed information, especially if the user of your app doesn't have the device mounted securely to whatever is moving.
Would it be a valid use case for your app to go to sleep and turn off the GPS? You might be able to devise a way to turn the GPS back on when you bring the app out of suspension. If you need the location always, then GPS is your best bet. People understand that GPS based apps require power and will come up with a way to plug it in to use it long term.
Perhaps you should think about the use cases for your app and ask if people are willing to drain their battery power for whatever functionality you will offer.
Using acceleration and time you can calculate change in velocity but you don't necessarily know the starting velocity. Plus the accelerometer in an iPhone probably isn't accurate enough for this anyway, but it's not a bad shout.
all.i want to know the phone‘s electricity cost in my apps.but the BatteryManager
can't give the information.how can i get this?
This information is not available via the Android SDK, sorry.
The only way to really know is to hook up a power meter to your hardware to measure the current draw while your app is running. The battery stats in the UI computed from an approximation over time based on the types of things the application is doing.