i have added a feature in my app that uses the proximity and accelerometer sensors (the second is to detect shakes). This is implemented in an always running service (if the user selects it of course). But I fear for the battery usage that my ap will have. I have NOT used any wake locks but i still get readings even when screen is off as i can see in my logs. The question is: what of the following is true?
The two mentioned sensors are activated anyway by android system
the whole time (in which case me collecting the readings as well
does not affect battery life...i guess).
Android system turns these sensors off most of the time (in which
case me keeping them always on through my service affects battery
life)
If (2) is true: Is it possible to implement my own sleep cycle for the sensors or will the whole toggle process make things worse?
Amount of power taken by sensor varies from sensor to sensor, and device to device.
On average, your most power hungry sensors are the GPS, accelerometer and gyroscope. Leaving them On all the time will reduce the battery faster.So you should pause the sensor when the device is where-ever not necessary.
After that, the light sensor and compass are much less battery intensive, but if you use them for long enough even they'll affect battery life.
besides this you can test your app for sometime how much it takes, or you can use getPower () to return the power in mA used by this sensor while in use.
There is no exact method for this actually.If your app have to use the sensor then use it when its needed.
thanks
u can reduce the power consumption by reading the sensor's value at some competitively larger time like 50ms,
i.e. any android cell read the data at 5ms or 10ms depend on brand of cell phone and we can manually reduce that time to 50ms to 70ms.
it would increase the battery life and won't affect on process as well.
thank you
Related
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.
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.
I have an application which calls sensorManager.registerListener() for the accelerometer, gyroscope, and magnetometer, which registers all sensors for the handler and they are each set to SENSOR_DELAY_NORMAL. This works fine with no issues the vast majority of the time.
However, when looking at some logs I noticed the accelerometer would seemingly randomly change is frequency from roughly 179ms (which seems the be the average SENSOR_DELAY_NORMAL on my phone) to about 20ms.
After doing a fair amount of digging and testing, I found the cause to be when the phone is shaken rapidly. When this happens all other sensors will maintain their ~179ms rate, but only the accelerometer will increase its rate to ~20ms. After some period of time the rate will eventually decrease from ~20ms back to the set rate of ~179ms.
I'm not sure how long it takes for it to return to the ~179ms rate, I've tried uninstalled and reinstalling the application and if enough time has not passed yet the accelerometer will still be firing events at ~20ms.
I wanted to see if I could resolve the issue but un-registering and re-registering the listener at the correct rate when this happens, however the accelerometer will keep going at ~20ms irregardless of what I reset it to. I did find out though that I can unregister the accelerometer listener, and that seems to work, but it doesn't solve my problem.
Anybody know why the accelerometer listener would change its rate at which it's firing, and how I might be able to resolve this?
The delay that you request Android for is only a suggested delay. Android system and other applications can change this. Source
The reason why this can happen is quite simple -
There are only limited number of physical sensors available on the device, 1 accelerometer, 1 magnetometer, 1 gyroscope
Say your application, registers for all events from accelerometer every 100ms.
Another application, requests for all events from accelerometer every 10ms
Now since there is only one sensor and there 2 different needs, Android enables the accelerometer to provide the data at the lowest of all delay requests made by all the apps and then Android reports all events at this delay frequency only.
In this case, it is up to the application developer to disregard events when they are in excess to what is required.
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 am developing a GeoFencing Android App that notifies user whenever they are close to a certain region (similar to Start Monitoring for Region in iOS).
I know I can use AddProximityAlert in Android but I am concern about the power consumption as I will add around 50 geo points.
The question is: would the power consumption change on adding more points ? or it will stay the same regardless how many points I added ?
You'd have to make tests to know for sure :-) But my understanding is that the LocationManager checks periodically the current position (one "expensive" GPS check every 4 minutes if screen is off, more often if it's on, couldn't find how often) and then compares the location with all the registered center-points. So the power consumption, GPS-wise, is limited, and after that it's just "normal" CPU consumption created by checking an array of points.
HTH
I haven't done any tests before but I think the power consumption depends on hardware refreshing rate. You can set up a comparison test with no geo-point and multiple geo-point. You may need to stand still to ensure the same GPS visibility. And use some power consumption tool, such as Battery Historian, to evaluate the power consumption.