[Galaxy S II General] Entropy512:
It's a myth. AndreiLux keeps harping on CPU power usage when he forgets that other components in the system use power.

Statistics from the Infuse, which has a similar sized battery:

In airplane mode, with the cellular radio completely shut off - almost no drain at all. Maybe 5% per day.

In normal operation, with moderate signal - around 0.8-1% per hour drain

In normal operation, with extremely weak signal - around 1.5-2% an hour

Deep sleep percentages and clocks used change minimally - 93-95% deep sleep in both normal operation cases. Yet despite CPU power-on times changing insignificantly, battery drain is at least 50% higher in the weak-signal case. Proof that CPU usage in this regime is NOT the dominant consumer of power, but the radio is. Android OS usage in these cases is low - single digits. Cell Standby is the #1 user of power, as it should be. 60-70% in moderate signal, I've seen it as high as 80-85% at my desk at work where signal is extremely weak.

The SGH-I777 achieves similar battery life to the Infuse - less than 1% per hour in moderate signal, a bit over 1.5% per hour when in extreme weak signal. Again - signal strength results in a significant delta in power consumption, which is expected as the power amplifier must crank up the transmit power to handle the near/far problem at the tower. (If all handsets transmitted at the same power level in a CDMA-based system such as UMTS, near handsets would "drown out" the far handsets. As a result handsets are kept in a strict power control loop to ensure that the receive signal strength of all handsets is approximately the same at the tower. The higher the RF path loss, the higher the required transmit power to maintain the power control loop.)

Despite this, prior to the fix for the Android OS reporting bug in 2.6.35.14, Android OS would show 50-60% power usage, whether in moderate or weak signal, with nearly identical deep sleep percentages to the Infuse. So how is it that Android OS constantly reports the same percentage of power usage, despite deep sleep percentage not changing, but drain changing consistently with signal strength? Simple - it's a display-only bug. The fix in 2.6.35.14 makes the I9100 and I777 behave consistently with other Samsung devices, in terms of properly reporting radio power usage as the #1 consumer of battery in moderate to weak signal idle situations where deep-sleep percentages are in the mid-90s.

On my last test run with a 2.6.35.7 kernel, in over 10 hours of idling, events/0 and suspend process usage was one minute each. That's it - so these sure as hell weren't contributing to Android OS being 40% of drain, higher than even Cell Standby with battery drain less than 1% per hour.

So this is clear evidence you don't really know what you're talking about. The CPU architecture of our phone is very similar to that of its predecessor - no major power consumption miracles here, other than minimum frequency with most kernels being twice that of its predecessors. I'm having trouble finding information on the process feature size of each CPU, but I'm fairly certain Samsung didn't do a process shrink between the S5PV210 and the Exynos 4210 - evidence contributing to this is the fact that for each clock frequency supported by the two processors, core voltage is the same. If there were a process shrink, core voltages for the 4210 would be lower. So the only real differences is we've got a second core to potentially eat power - without a doubt it's not going to be a major improvement from its predecessor in terms of CPU power.

But then we get to the rest of the system, which you've been completely ignoring. UMTS radio technology is fairly mature, there haven't been any major breakthroughs in handset power amplifier efficiency for a long time. A UMTS radio is what it is and there is little one can do to significantly reduce power consumption other than reduce its on-time (Fast Dormancy - which all evidence I've seen states is not supported by AT&T in the United States, another contributor to radio power consumption being dominant, at least for my use cases.)

Unless Samsung has made massive breakthroughs and has figured out how to break the laws of physics either by eliminating RF path loss (we'd have heard about this - 5 bars anywhere?) or increasing transmit power without increasing transmit PA power consumption (perpetual motion machine? sign me up!) - the radio is the dominant user of power in the 1% per hour battery usage regime. Yet, prior to the 2.6.35.14 reporting fix, the CPU would be reported as the dominant power consumer.

So the reporting bug, and it IS a reporting bug only in many cases, is fixed. The question is:

In cases of real, actual battery drain (multiple percent per hour idle usage), does battery stats report correctly now? Unfortunately, a side effect of the reporting bug being fixed could be that real cases of CPU drain could be hidden - it's hard to tell when it's clear that the old behavior blamed Android OS for power it wasn't consuming at all.

More evidence you're talking out of your ***. So, our fuel gauge driver has no way to measure current drain (actually, it is buried in the fuel gauge chip but not enabled in our kernels - check max17042-battery.c in newer Linux kernels for some neat stuff), but battery monitor widget somehow pulls current drain statistics out of its ass? WORTHLESS.

"battery properly calibrated" - more evidence you don't understand what you're talking about. Our fuel gauge's predecessor chipset (the one used in Galaxy S devices), the MAX17040, was specifically designed and marketed not to require calibration. (That's the disadvantage of coulomb-counter type fuel gauges like those used in HTC devices...) Now, while the MAX17042 does have current measurement capabilities, in our devices these are not enabled. The fuel gauge hence behaves similarly to a MAX17040. You don't calibrate these, except with two methods:

1) Battery pull

2)

echo "1" >/sys/class/power_supply/fuelgauge/fg_reset_soc

There is nothing else writable in our devices within the fuel gauge driver - it can be reset and that is it. No way to upload battery heuristics to it, therefore just like first generation GalaxyS devices, batterystats.bin does nothing in terms of state of charge measurement. Yet you talk about calibrating your battery?

In short - if in a situation of weak to moderate signal, with drain on the order of 1% an hour, if Android OS is getting reported as higher than Cell Standby, it is a reporting bug, plain and simple.