Develop Reference

How much energy does Activity recognition API consume exactly?

I know that everyone keeps saying it's low but is there a way of getting real numbers instead of just saying "low" ? Like Fused location provider, it officially says it consumes 7.25% per hour if it's updated every 5 seconds in high accuracy mode. Why can't I seem to find any official given percentage about activity recogniton?
I need a documented result because I'm writing a scientific article and I can't simply use the term "low" energy consumption. If such estimation isn't provided in the official Google I/O does that mean that I'll have to just test it myself ?

Yes. You have to test it yourself. For activity recognition there's a lot of things in play, for example: hardware available to the API, not all device has all the sensors supported in Activity Recognition.

I've done several experiments in which I bypassed the battery and measured the power being drawn on a few devices, and I can tell you that even the same sensor draws a different amount of power on different devices. To complicate matters even more, some devices have a hardware FIFO, which saves power on these devices compared to those that don't, and it looks like ActivityRecognition API may be taking advantage of it on these devices.
I would recommend you choose a few different devices and just run some power experiments on them. Make sure you keep track of the API level used, since the hardware FIFO was only exposed in API 21+. Also, keep in mind that ActivityRecognition goes into a lower power state if it is still for too long, so find a way to keep it moving.

How to check processes and services consuming lots of battery

I have created an app which consuming 48 percent of battery in some device which is highest in power management task, but in some device its 5-6 %, i am running a service in background all the time which fetches the latitude and longitude and send it on server if user is logged in. but i have checked also check by logging out from app it still consumes 48 percent.
to fetch latitude and longitude o am using fused location api.
So please tell me how to resolve this issue of battery consumption in some phone and how to check which process and service is draining battery.

I agree with Lonni that the issue is the lat/long fetch. Given the scale of the power consumed, 48%, it's unlikely to be the GPS circuitry itself. I figure it's the CPU. Mobile processors are very power efficient unless they are kept active. Let me explain. An active proessor is the most power hungry device on a mobile device. So how can a processor be the biggest power hog while also being "power efficient"? By the processor being "power efficient", I mean that when the processor isn't doing anything, it goes into a very efficient lower power state where its power consumption can be over an order of magnitude less than when in the active state.
My guess is that you are keeping the processor in an active state. What you want is to keep the processor as idle as possible.
Here are my recommendations:
Use the longest interval possible between lat/long fetch. A common mistake is that more checks mean better response, but unnecessary checks generally don't improve response and just keep the processor active and consuming power for no good reason.
Never poll! Polling keeps the processor active which consumes power for no good reason. Put the processor to sleep.
Use interrupts to processes events. System libraries, such as sleep(), put the processor in an inactive state, and uses an interrupt to wake the processor back up.
Don't write your own routine if a library routine already exists. The OS/library writers are very aware of the importance of power efficiency and have written their code to be as efficient as possible.
Make your code run as fast as possible. Fast means more idle time, which drops the processor into a more efficient power state. For example, if you can get along with a lat/long check every 60 sec, and you can get your processing done in 10 sec instead of 30, you have 50 sec of idle vs 30 sec.
Use a good optimizing compiler and good optimized mobile libraries if possible. Good compilers create more efficient, faster running code. Good libraries not only run faster, they use power efficient techniques.
Use a thread pool if you are using a lot of threads. Creating and tearing down threads is costly.
Make sure you check your API specs on your devices. I can imagine that some OSs/drivers, e.g. GPS, will require the device to be explicitly turned off, while others will do so implicitly.
Here's some more information: Battery-safe coding
Aside: I already see the thought bubble: "Why are some devices using less power than others?" Some libraries are really smart, and anticipate bad programming practices and do workarounds. Others are dumb. The same with the OS, system libraries and thread scheduling.

My best guess is that the constant fetching of long and lat is draining the battery. If i remember correctly what I did a few years ago with positioning that was the case.
I would say that you should try and see the refresh-rate you want to have of your coordinates. Maybe it doesn't need to be refreshed more than 5 times per minutes. In that case you would save a lot of calls to the fetching of the coordinates and surely save your battery.
As for why it is different on some devices, I'm afraid I have no idea. Maybe the version of android used?
Edit: I don't know if Eclipse can do that and I don't think it can.
However, you may want to check this paper: http://www.usenix.org/event/usenix10/tech/full_papers/Carroll.pdf

Android FusedLocationProvider and battery life

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.

How is it possible that Google Fit app measures number of steps all the time without draining battery?

The Google Fit app, when installed, measures the duration you are walking or running, and also the number of steps all the time. However, strangely, using it does not seem to drain the battery. Other apps like Moves which seems to record number of steps pretty accurately declares that it uses a lot of power because of it constantly monitoring the GPS and the accelerometer.
I imagine several possibilities:
Wakes up the phone every minute or so, then analyses the sensors for a few seconds and then sleeps again. However it seems that the records are pretty accurate to the minute, so the waking up must be frequent.
Actually turns on the accelerometer all the time, and analyzes it only after the accelerometer measurement data buffer is full. However I think the accelerometer has a small buffer to store the latest measurements.
Use GPS to estimate the number of steps instead of actually counting it. However this should not be the case, since it works even indoors.
The app still feels magical. Counting steps the whole time without perceptible battery drain.

Thanks for asking this question!
Battery is one of our top most concerns and we work hard to optimize Google Fit's battery usage and provide a magical experience.
Google Fit uses a mix of sensors(Accelerometer, Step counter, Significant Motion counter), Machine Learning and heuristics to get the data right. Our algorithm is pretty similar to your 1st option plus a little bit of magic.
We periodically poll accelerometer and use Machine Learning and heuristics to correctly identify the activity and duration.
For devices with hardware step counters, we use these step counters to monitor step counts. For older devices, we use the activity detected to predict the right number of steps.
Our algorithms merge these activities, steps and sometimes location to correlate and further increase accuracy.
We do not poll GPS to estimate steps or detect activities.
-- Engineer on Google Fit Team.

On some very recent phones like the Nexus 5 (released in late 2013 with Android 4.4 KitKat), there is a dedicated low-power CPU core that can serve as a pedometer. Since this core consumes very little power and can compute steps by itself without the need for the entire CPU or the GPS, overall battery use is reduced greatly. On the recent iPhones, there is a similar microcontroller called the M7 coprocessor in the iPhone 5s and the M8 in the iPhone 6.
More information here:
https://developer.android.com/about/versions/kitkat.html
http://nexus5.wonderhowto.com/how-to/your-nexus-5-has-real-pedometer-built-in-heres-you-use-0151267/
http://www.androidbeat.com/2014/01/pedometer-nexus5-hardware-count-steps-walked/

having a 3 year old HTC OneX I can say that THERE IS NO DEDICATED HARDWARE, Google Fit just uses standard sensors in a very clever way. I come from Runtastic Pedometer: there is a clear battery consume when in use, it would be impossible to keep it on all the time as it needs the full accelerometer power. On the other side, if you stand still and shake the phone Runtastic will count the shakes, while Google Fit apparently does nothing... Still it works perfectly when you actually walk or run. Magic.

Google fit try to learn use pedo step pattern and try to create its own personal walking patterns and its clusters. This eliminates the need of having huge mathematics calculations on receiving sensor data every time. This makes Google fit more power efficient compared other software pedo apps. Having said that, there is compromise on accuracy factors here. Between power-accuracy trade off, google seems to be more aligned towards power factor here.
At this moment the most power efficient detection happens Samsung flagship & its other high end models. Thanks to Samsung's dedicated hardware chip! No matter how power efficient your software pedo algorithm be but its hard to beat dedicated hardware unit advantage. I also heard about Google's bringing dedicated hardware unit for Ped upcoming nexus devices.

It would seem like the solution would be device dependent, with devices where a co-motion processor or "wimpier" core is available for low power operations, that it would default to this once the buffer is full or similar condition. With devices where a low-power core is not available, it seems like waking the device could trigger a JIT operation that would/should finish by the time the app is called.

While the Nexus 5 does have a dedicated "low-power" pedometer built in. It isn't as "low power" as you might think.
My Nexus 5 battery life was decreased by about 25% when I had Google Fit Activity Detection switched on.
Also, the pedometer doesn't show up in the battery usage stats. Presumably, because it is a hardware thing.

I don't know for the other phones out there, but Google Fit was really draining my battery life on my Nexus 5. Disabling it definitely improved my battery life.

Energy consumption of smartphone components

I'm looking for a list of all the components and their power drainage on an up-to-date smart phone.
Accelerometer, gyroscope, magnetometer, etc.
Display
WiFi
Bluetooth
GPS
CPU
Camera
Microphone
etc.
Preferably in mA so it can be easily compared to the battery's capacity (usually specified in mAh).
The Sensor's power is actually available via the SDK and can also easily figured out for most devices on AndroidFragmentation. However what I'm looking for is comparable data for the other hardware components to consider their efficency.
Bonus: Will a request for less frequent updates of a Sensor decrease energy consumption of the Sensor, as it returns only one value for getPower()?

There are a couple of detailed studies that I am able to find on this.
A study from the USENIX meeting in 2010 which studies various components of a smartphone (except the camera)
Another study from the Hotmobile mobile computing workshop 2013 that has more information on cameras and displays.
Reference 1 especially seems a great starting point.

I'm looking for a list of all the components and their power drainage on an up-to-date smart phone.
That is impossible to answer.
First, different devices will use different varieties of these components, with different power characteristics.
Second, many, if not most, of those components will have no published power statistics, or the specific components themselves may not be knowable without a complete teardown of a device.
Will a request for less frequent updates of a Sensor decrease energy consumption of the Sensor, as it returns only one value for getPower()?
That will depend on the sensor. Some sensors are effectively always "on" (e.g., ambient light sensor), courtesy of the OS, in which case the only incremental power drain for your use of that sensor will be in passing that sensor data to your process. Other sensors might not be regularly used by the OS, meaning that your request for events from that sensor might turn it "on", resulting in power drain from the sensor itself in addition to supplying you with that data.
It would be truly wonderful if all Android devices were instrumented in the way the Qualcomm MDP is, so that we could get fine-grained power detail for our apps and their usage of various components.

There was a Google I/O session on this very subject a few years ago; you can see the video here and slides pdf here.

I know it's against the rules to plug your own startup, but what you're asking sounds exactly like what we're working on.
There's an Android performance monitoring tool called "Little Eye Labs". It shows real-time power consumption of an App as it runs on a phone. It currently only supports CPU, Display, GPS, Wifi and 3G, but you'll be able to get the instantaneous power consumed (in mW) by these components.
/end of plug
Note that there's no real way to get this information directly from a device, so the best you can do is model the phone, gather device resource consumption, and model power usage.

Display is the most power consuming part of the smartphones; accounting for up to 60% of total battery life (Can draw power up to 2W). There is a book called Green IT and its Applications; you can read it online in Google books.

On any modern Android, go to Settings > Battery (sometimes Settings > About > Battery). You should see a graph of power drain over time, as well as how much was used by what component.
Although consumption varies a lot based on usage patterns, in my experience the top consumers are display, radio, and CPU. I have not seen sensors rank high in energy use on any of my devices, in the absence of bugs. The link provided by Yusuf X places game sensors above CPU.
For more information about optimizing battery use on Android, see Reducing the battery impact of apps that downloads content over a smartphone radio and Optimizing Battery Life.

There is an app called PowerTutor that it does some battery consumption measurements for every phone component and for every process. The code is open so you can pick up some ideas from there. Note that this app was optimized for Google's phone, especially for the Nexus One.