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.
Related
I'm using accelerometer and gyroscope in my Android app. I want to profile my app for its power consumption. Lets say the app, read these two sensors every 100 millisecond, add all its three axis (x,y,z), and store them in a file.
Now I am not sure if these two sensor are always on or not ? If yes, then most of the power consumption will come from how I use or process these sensors' values in my app. So I have the following questions.
Are these two sensors always on or active ? (If so, any reference).
What does then the register and deregister does ? If they are always on,
then it won't make any difference to deregister them, at least in
terms of power consumption.
Background or reasoning behind these questions:
Gyroscope consumes more power than accelerometer (based on my analysis, its 4-6 times higher). Now if these sensors are always on then I can use them both in my app because my app is not the reason for the power consumption caused by the active status of these sensors. My app will be responsible for the power consumption due to the way I use these sensor values, and how often I read them. However, if these are disabled or off (consuming no power at all), then I have to make a careful decision if I want to use them or not because when I register them, then I am also increasing the power consumption due to their active status in addition to the processing their values.
Mostly as addition to the answer from Andriy Omelchenko with some more links:
1.
This is broadly and "manufacturer independent" documented in Androids Architecture Documentation in the Sensors Section. Specifically that Accelerometer and Gyroscope are handled as non-wakup sensors which report events continuously but may not wake up the SoC.
So yes, you can assume these 2 sensors are always on.
2.
Furthermore the documentation states: If an Application needs the data in background, it needs to hold a Wakelock - probably the Partial Wakelock which will keep the system from going into low power/sleep mode - such that events are processed and delivered without being dropped. Obviously this will drain the battery faster.
You could imply that registering/unregistering may have a low effect on power as long as you don't keep a Wakelock.
But in general you shouldn't assume it is useless to register/deregister sensors for power optimization - except one-shot sensors. Not only because of the power used for processing and delivery of events to apps and the possibility of keeping the system from its sleep. It is a Framework recommendation and these are normally not without cause like the use of register with report delay to make use of batching if possible. The impact may change with different hardware or other factors.
It could also be a funny bug source if - for example - you assume that data is provided depending on the Wakelock: The documentation only states that for non-wake-up sensors the driver is not allowed to hold a Wakelock and the sensor shouldn't wake the SoC. Meaning your app could be processing events in the background or not depending on device, system, installed apps and so on.
From Official site: "Always make sure to disable sensors you don't need, especially when your activity is paused. Failing to do so can drain the battery in just a few hours. Note that the system will not disable sensors automatically when the screen turns off."
"Are these two sensors always on or active?" - seems this question has no general answer because it depends on hardware. Actually accelerometer and gyroscope has low power consumption, but they support by OS may consume more battery.
"What does then the register and deregister does ?" - eliminates power consumption for data processing from them.
The accelerometer and gyroscope are not always on. That would be crazy - absolutely anything that draws power in a mobile device is put into a low power mode where-ever possible (no application is currently requesting it). Hence the need to register / deregister.
There isn't a strict specification to require this from hardware manufacturers, because this is a common sense optimization to increase battery life.
my client wants an application which essentially uses all these all the time i.e. in a background service:
- network/wifi
- location service
- BLE scanning
Which means this has a big effect on the battery life. According to my measures it can lower your battery more than 10% per hour this way.
What would be the best way to lower energy consumption, and which one of the three services would consume the most power? The location service only gets updated if the user location changes significantly (can happen while travelling), and there is constant client-server communication going on in the background.
And the whole idea is that BLE is constantly scanning. What would be the best way to handle this situation?
Why would you need to be constantly scanning? A better solution would be to scan for short time intervals (for example 2 seconds) every 5, 10, 20 or more seconds. You get the idea.
I highly doubt that the available devices would change faster than this and if they do, you most likely won't be able to connect to them.
I am eager to know how ActivityRecognition which is in GooglePlay Services works?
I think activities are recognized by accelerometer data.Is it right?.Please give me the details how it goes?
I was looking for this answer also and your post was one of the top results on Google. I did a little more digging and found this https://developer.android.com/reference/com/google/android/gms/location/ActivityRecognitionApi.html which says:
The activities are detected by periodically waking up the device and reading short bursts of sensor data. It only makes use of low power sensors in order to keep the power usage to a minimum. For example, it can detect if the user is currently on foot, in a car, on a bicycle or still.
It doesn't explicitly say which sensors it uses, but we can safely assume that accelerometer is one of them. Since it says sensors (plural) it evidently uses others. But since it says low power you don't have to worry about it using GPS or anything like that. However, it does say that it wakes the device up which would bring it out of its super power saving mode. So, even though it is low power you still may not want it running every 5 seconds all day long. The documentation further down says:
A common use case is that an application wants to monitor activities in the background and perform an action when a specific activity is detected. To do this without needing a service that is always on in the background consuming resources, detected activities are delivered via an intent. The application specifies a PendingIntent callback (typically an IntentService) which will be called when activities are detected. See the documentation of PendingIntent for more details.
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!
I need to implement location-based service. I don't need fine location, so no GPS is needed.
Easiest would be to start listening for locations updates at app start, and leave it ON:
mLocationMgr.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 10000, 100, mPendingIntent);
Since I don't need much accuracy, I set max frequency of updates, to 10s, and 100m instead of default 0, 0.
When we think location, we think battery drain, but I guess this is a shortcut and that only GPS really drains the battery. I think that such a use of network provider wouldn't drain the battery. Any thoughts?
Your 100m distance filter will do little for you from a battery drain standpoint. That will only control how many times your PendingIntent gets executed due to fixes.
Your 10 second time value might be used by the OS to control power usage, but there is no guarantee. And, with that low of a value, it seems highly unlikely that it would be used. Every hour, maybe, but not every 10 seconds.
The bigger thing is that you will be needing to keep the CPU powered on all the time. And, since you're using the PendingIntent flavor of requestLocationUpdates(), I am guessing that you plan on collecting data for a long time.
If you only have COARSE permission, Android hopefully eschews the WiFi hotspot proximity detection, which will save a bit of power.
On the whole, the network provider will consume less power than will the GPS provider. "Less" is a far cry from "little". On a Nexus-class Android device, GPS + CPU gives me a few hours battery life (as determined by using Google Navigation). I would expect network provider + CPU to last a few hours longer, but that's about it, because the CPU is a fairly significant battery drain in its own right.
My bigger concern is:
Easiest would be to start listening for locations updates at app start, and leave it ON
This sounds like you aren't actually planning on removing your location updates. This is a really bad idea, with any sort of provider (except maybe the passive provider). Please have a more concrete plan for when you are registering and removing the updates. In particular, make sure the user has the ability to control when you are consuming battery to this degree.
There is a topic about this included in the Android Developers Guide. I would recommend that you take a look at the code examples on the page.
This is what they mention regarding conserving battery and various parameters.
Adjusting the model to save battery and data exchange
As you test your application, you might find that your model for
providing good location and good performance needs some adjustment.
Here are some things you might change to find a good balance between
the two. Reduce the size of the window
A smaller window in which you listen for location updates means less
interaction with GPS and network location services, thus, preserving
battery life. But it also allows for fewer locations from which to
choose a best estimate. Set the location providers to return updates
less frequently
Reducing the rate at which new updates appear during the window can
also improve battery efficiency, but at the cost of accuracy. The
value of the trade-off depends on how your application is used. You
can reduce the rate of updates by increasing the parameters in
requestLocationUpdates() that specify the interval time and minimum
distance change. Restrict a set of providers
Depending on the environment where your application is used or the
desired level of accuracy, you might choose to use only the Network
Location Provider or only GPS, instead of both. Interacting with only
one of the services reduces battery usage at a potential cost of
accuracy.
Basically, consider reducing the frequency of the updates you request or the length of time you request them. This is like golf, the less locations you request the better. Consider the following use case:
In the example the application waits until the user performs an action that needs a location and then stops polling once the location data is no longer needed.
While polling constantly would allow the application to have a location ready at an instant notice its simply not worth the wasted resources, to mitigate the delay when requesting a location you can use getLastKnownLocation (String provider).
Edit:
There is a way to determine power usage for the various LocationProviders!
Calling getPowerRequirement () on a LocationProvider will return one of three constants.
int POWER_HIGH A constant indicating a high power requirement.
int POWER_LOW A constant indicating a low power requirement.
int POWER_MEDIUM A constant indicating a medium power requirement.
To make your code more readable look into using meetsCriteria (Criteria criteria) in any boolean checks to make your code more readable.
I would use this to determine what method your application should use for the lowest power cost, Also you have the benefit of supporting devices that have different power requirements for providers.