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.
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.