Energy vs power

Measuring how much power goes into a mobile device with a battery, requires a special setup, full automation and a lot of discipline when coding the test cases for it to be right. It cannot be easily done manually ad hoc by testers at home. It is also a metric that has a lot of potential for noise/error. This is not an ideal situation for Nexus 7 testing, and developing a stable solution for this problem is taking time and effort. For the time being, an easier method to measure energy drawn for a device can be used.

Tracking how much battery charge, as a proxy for energy, is required for doing some activity is easy to do. With the advantage that the error that the fuel gauge chip (battery chip that provides this metric) has is less than 5%, so it is very accurate. The battery holds charge so if we measure power we need to integrate it over time to get energy (complicated calculation for testers doing manual testing at home), hence it is easier and more accurate for the layman to measure charge directly if there is a way to get that value.

When we talk about battery life on mobile devices, what we care about is the energy that certain task consumes to do a particular task. We care about the amount of energy spent by downloading/reading email (energy that drains the battery).

Cases of study


  1. The device needs to be unplugged from the mains or any USB power during the testing. The battery is the one providing information regarding drained energy, so the device needs to be feeding from the battery.
  2. The test case needs to be long enough so that the draining is significant (minimum amount of battery that has to be drained to be able to dismiss any quantization error). The test case needs to be short enough not to cause a major change in voltage.

How to do it?

  1. Take four measurements: cat /sys/class/power_supply/battery/{charge_now,voltage_now, capacity, energy_now}
  2. Run your test for X seconds (TBD)
  3. Take the four measurements again: cat /sys/class/power_supply/battery/{charge_now,voltage_now, capacity, energy_now}
  4. The delta between the initial charge and the final charge is the amount of charge drained. Assuming linearity of the voltage throughout the test, the energy consumed is:

Δcharge * (Vend + 0.5 *|Vstart - Vend|)

Or alternatively: Eend-Estart (All the stats will be gathered to be able to verify all the values are sound)

charge_now is in μAh, voltage_now in μV.


For quicker draining of the battery, a dd was used, with data points being taken every half a second:

dd if=/dev/urandom of=/dev/null bs=1M

stdbuf --output=0 ./measure -i 500 | tee voltage.log

The measure script and a script to explore the accuracy of upower can be found here:

We are looking into making UTAH able to keep track of these stats when running tests on the nexus, so that energy consumption can be looked at when needed. Aside from this, specific test cases for energy consumption will be put in place and charted accordingly, the semantics of these being discussed at the moment. UTAH should only capture energy readings when the battery of the device is discharging and have a warning in place for when the values are not to be that good (outside the 20% to 85% battery capacity).

What next?

Utah supports taking measurements whilst tests are executing already.

New utah feature to be discussed: to be able to run a test case for a given amount of time, then stop it. Can we use timeouts for this? Should we call this kind of feature something different? In this case the test wouldn’t fail when hitting the “timeout” but pass and measure engergy consumed during the whole period. Use case: “random browsing during 1 hour”, “playing videos during 5 hours”, this would be “endurance testing” or soak testing.

QATeam/AutomatedTesting/BatteryConsumption (last edited 2013-06-17 06:04:18 by gema)