yashsingh1/xdaforums huggingface dataset:
[Galaxy S II General] AndreiLux:
Did you advance on the MHL driver?

Also, this is supposedly the AOS changer: https://github.com/arighi/linux-gt-i9100/commit/efc29b1d4e0e3451f0b9a0654fae31869905eb26

While it seems to have its advantages, I don't know to what magnitude, I'm not familiar with the Linux kernel enough, but it just looks that he's just removing the workload from being registered by the system.
[Galaxy S II General] Entropy512:
MHL - Between UCKJ2 hitting for the Infuse (finally, Gingerbread bootloaders - and yes, I still do some low-level dev for my old device), a motherboard upgrade, and trying to help the T989 community get root, I haven't gotten much done this week.

As to that commit - I'm fairly certain it's not - it may affect AOS, but I know that arighi's patches to go from .7 to .14 apply cleanly without that commit applied, and just applying those patches changes AOS significantly. Also, I'm not on my usual kernel dev machine to check, but I'm fairly certain I have that patch committed to a branch and it didn't affect AOS - at least not in the significant way that .14 changes things.
[Galaxy S II General] ram3n:
Thanks for your advice dude !

The fact is that I've already checked and haven't any serious wacklock to explain this drain... Dee sleep is BTW working very well, no wifi, BT or whatever on.

So very strange, don't you think ?

I've just "calibrated" my battery and see if it'll be improved soon.
[Galaxy S II General] AndreiLux:
Btw, I did another idle run, this time on just 3G/H and I'm getting approximately the same drain. Maybe 0.15%/h more. And this is on a *bad* signal of 2 bars (103-107dBm) most of the time.
[Galaxy S II General] TheFluffyOne:
I did a somewhat unscientific test last night by charging the phone to 100%, rebooting, and then going to bed. This morning, after 8.5 hours, the phone was at 78% remaining battery (about 2.6% drain per hour) and had a very interesting wake pattern shown in the standard battery usage app.

Looking at /proc/wakelocks, PowerManagerService was showing as awake for 262 minutes whilst the screen was off. Out of the ~510 minutes the phone was supposedly idle it was awake for over half that time (if I have understood the meaning of this all correctly).

This is with a beta 2.0 Siyah kernel, WiFi turned on, phone data turned off (I'm roaming at the moment). The phone would have automatically associated with the hotel's WiFi after the reboot. Sadly I didn't think to grab CPUSpy info or anything else useful.

The PowerManagerService appears to simply be the Android component that handles other applications' requests for wakelocks, so I guess -- based on some previous comments -- that it could be user-space apps that show up in /proc/wakelocks under that entry?

(Forum software has resized the grab of the ODS file to the point where it's just about legible with a magnifying glass, and I'm feeling too lazy to zip and upload the ODS itself.)

Edit: Decided to be less lazy and zipped up the dmesg (which it seems I grabbed without realising it...) and the ODS.
[Galaxy S II General] Entropy512:
Hmm, I'll try to review some of the more recent data collected when I can, but that's a good theory on PowerManagerService.

For many people, they see no userspace wakelocks but PowerManagerService in the list.

For me, I see userland wakelocks but never PowerManagerService. My userland wakelocks are always the wakelock name preceded by [P] in the kernel wakelock list.

So it may be that depending on the exact framework, in some cases, PowerManagerService tracks each wakelock internally and holds a single kernel wakelock, releasing it only when all upper-level wakelocks are released. On other phones like mine, PowerManagerService may take a wakelock request and pass it directly to the kernel, tracking it separately from all other locks.

So on my phone (And probably any I777 regardless of kernel), /proc/wakelocks gives you all the info you need for a total wakelocks picture. On most I9100s, the framework may hide detailed info from the kernel, so a total wakelock picture requires looking in two places - /proc/wakelocks for kernel locks and BetterBatteryStats for userland locks. (Probably no need to use BBS unless PowerManagerService is high on the ****list.)
[Galaxy S II General] AndreiLux:
Just ask a i777 user (or yourself) to dump his wakelocks file using the Perception ROM since it's i9100 based, and then you can confirm that it's coming from there.
[Galaxy S II General] TheFluffyOne:
An even more unscientific test last night (since I was only able to charge the phone to 81% before I gave up and went to sleep) resulted in a 3% drain in about 7 hours; so that's about 0.43% per hour.

The main difference (other than the partial charge) was that I turned off WiFi. I won't bother posting screengrabs/wakelocks etc. for this since it's not really a direct comparison with the previous run, but suffice to say that PowerManagerService registered less than 3.5 minutes of wakelocks during this period.

If we assume that WiFi itself is a very minor drain (based on Entropy's observations), then the difference is likely to be due to one or more applications behaving differently when they don't have a data connection; recall that cell-data is disabled whilst I am roaming, so without WiFi I have no active data connection.

The symptoms do seem to fit with the idea that it's user-space apps causing the drain, and with the amount of crap I have installed on my phone that's a definite possibility. I'll do some better tests over the weekend and see if BBS can highlight the culprit.
[Galaxy S II General] Userius:
Well, I guess I'll paste some distractions here to :)

I'm running not rooted stock I9100, radio: XXKI1, pda: XWKI4. As I said, not rooted, still original stock rom, updated via KIES. And of course some apps installed, including the infamous skype (although skype is killed and did not respawn - I've check that every time in task manager). Yesterday I've charged phone up to 100%, manually killed everything I could using stock task manager, switched off wifi and data, forced 2G. Over night it drained at approx 0.42% /hour which is unlike I've ever seen on this phone. Normally it would do 1% - 2%. Today I've switched on wifi and after that again killed everything I could with task manager. It began to drain at approx 14% /hour (no, I'm not playing angry birds while taking stats :) It is draining at that rate with screen off, when it is supposed to be idling. Dmesg is showing some weird thing:

<7>[ 4676.681136] tspdrv: ImmVibeSPI_ForceOut_AmpDisable (0)

<7>[ 4677.874505] tspdrv: ImmVibeSPI_ForceOut_AmpEnable (1)

and wake locks are dominated by something called "main", although svnet is also "something else" (check attachments).

Frankly, I'm not shouting "help", as I'm planning to root this thing soon and going medieval on all the bloatware and all. Just thought it would be interesting to compare how completely untouched stock rom (with a few apps) behaves :)
[Galaxy S II General] Entropy512:
Good idea there - will try to get to that this weekend.

Sounds like a classic example of an app driving data to the phone when data is available - in many cases, the app itself won't show up as a heavy user of battery, but the network traffic drives up AOS.

You were sorting/looking at the wrong column. total_time includes wakelocks held when the screen was on - which we don't really care about. We want the sleep_time - wakelocks held while the screen was off. Key here is that, like every other dump I've seen, "main" only has total_time, and has zero sleep_time.

Your top wakelock holder is PowerManagerService at 12 minutes of sleep_time - while it isn't yet confirmed, there is mounting evidence that this consists of all userspace wakelocks "blobbed up" together. Use BetterBatteryStats to find details on these.

deleted_wake_locks is also high - this one is new for me

svnet is next up - your device spent 10 minutes wakelocked handling radio-related stuff

Looking at your CPUSpy screenshot, your deep sleep percentages are pretty good, EXCEPT: Your phone spent a good amount of time maxed out at 1.2 GHz. The time in this state is pretty close to the amount of PowerManagerService wakelocking you have. My suspicion is that whatever app is holding a wakelock is also causing the CPU to crank to full speed while the wakelock is held.

As to the ImmVibeSPI stuff in dmesg - you've clearly got haptic feedback enabled and were touching keys quite a bit prior to taking the dmesg. :)
[Galaxy S II General] TheFluffyOne:
12% in 7h16m last night from a full charge, which is about 1.7% per hour. PowerManagerService accounted for around 74 minutes of wakelocks during that period, with svnet-dormancy and svnet coming in at 22 minutes and 18.5 minutes respectively.

BBS shows WifiService as the primary wakelock holder at 53 minutes, with NetworkLocationLocator at 12 minutes.

The various pieces of information suggest to me that it's probably Latitude that's causing all the wakeups on my phone, so I'll disable that and repeat this again tonight. Not exactly an Earth-shattering revelation, but maybe the attached will shed some light into what PowerManagerService represents in /proc/wakelocks.
[Galaxy S II General] goat_on_boat:
For what its worth - i never had these issues on KH3 and older kernels (ie: Speedmod T27). Awake time would almost always = screen on time :)

That being said - i will do some more testing on KI3!
[Galaxy S II General] Entropy512:
I'll look at your attachment in detail tomorrow, but - from a few reports I've seen, Latitude can be very detrimental to battery usage, increasing drain 2x or more if you're in a low-drain situation like myself or post-Skype Andrei.
[Galaxy S II General] TheFluffyOne:
I set Latitude to not post location updates, and that didn't really make much of a difference. Possibly it is still waking to request locations of other people, so I have now logged out of Latitude completely and will try again...
[Galaxy S II General] Entropy512:
Andrei, you might want to include some of the later discoveries (e.g. this is often caused by bad apps using lots of data, etc.) in the first post.

An update on an experiment in progress - I'm in the process of doing a binary search on the patches from .7 to .14 (patch halfway, test, patch halfway in the direction the test results indicate) - the AOS behavior is not changed in .10, patching up to .12 now.
[Galaxy S II General] AndreiLux:
I wanted to rewrite the whole thing anyway, don't worry. But I'm still waiting on you/Gokhan to find exactly that .14 change, well actually only on you, since Gokhan said **** it :p

I'll do it in the next few days. By the way: that commit by Arighi does affect some thing and I'm 75% sure of it: there's 2 changes of behavior; one is the lowering of the events/0 process to single-digit seconds in CPU time, but with still high suspend, and the other is the .14 patching also decimating the suspend process from the list. Right now I'm still on a .7 kernel but with the arighi patch and experiencing the first behavior.
[Galaxy S II General] Entropy512:
Will take a look into that... I have been looking through arighi's patches and was starting to play with them, then I kind of went down the AOS/drainhunter rabbit hole.

I just realized I can run a controlled test that will identify drain differences between configurations by pinging the phone at a controlled rate.

I think part of the reason Gokhan said "**** it" is because he tried originally to patch from .7 to .14 and failed, so instead he ported the Samsung drivers to .14.

arighi managed to get a proper .7 to .14 patchset that I can use.

Also Gokhan uses Subversion for his revision control, which is IMO far less flexible/powerful than git. git is the first time I've ever really "gotten" branching/merging. There's a reason why Torvalds hates CVS/SVN with a passion and wound up going and writing his own tool from scratch... Well multiple reasons I'm sure. :) git makes it VERY easy to just quickly pop in then revert a patch to do a binary search from .7 to .14. Actually I probably should have used "git bisect" - which automates the searching. :)

Edit: Pingdrain makes testing this SO much quicker. Doing a last test on .12 to confirm, but it looks like the change happens when going from .11 to .12

Confirmed .12 is the change. AOS was up at 86%+ after one hour of pingdrain with .11, was down at 25% after an hour of pingdrain with .12. Drain seemed about the same in %/hour, but I really need to run overnight to be sure.
[Galaxy S II General] TheFluffyOne:
Well, with Latitude disabled, PowerManagerService wakelocks were down to 2.5 minutes in a 10 hour overnight period.

Very useful information in this thread that allowed me to figure it out, so thanks guys!
[Galaxy S II General] AStartsev:
I'm remove /system/app/Talk.apk and bug is gone :D
[Galaxy S II General] lokhor:
In BetterBatteryStats there is a partial wakelock record or ActivityManager-Launch. It only has 1m58s of time but the count is 458 which seems especially high. Is this normal?
[Galaxy S II General] Entropy512:
That's surprising - usually, Talk is the one IM app you can count on to NOT drain your battery.

Some wakelocks can fire many times but at extremely short amounts of time - for example in one of Andrei's dumps, there was something with a count in the tens of thousands - but total time of 1-2 seconds.

Also, one key thing is - in /proc/wakelocks, if it has low or no sleep_time, it doesn't really matter.
[Galaxy S II General] lokhor:
OK so you're saying its nothing to worry about?

I don't get very good (in my opinion) battery life but I can't see anything that is causing a lot of wakelocks and I only have Gmail, Twitter and Viber using push notifications.

Edit: forgot to add the following:

My battery usage shows after 9h30m:

Display 50% 2h15m51s usage

Android OS 29% 1h1m43s

Battery @ 34%
[Galaxy S II General] g2tl:
2.25 hrs of display time in 9.5 hrs is something like whipping out the phone for 5 minutes of use every 20 minutes. So that's not exactly a light use case.

Still, if your brightness was at or near the lowest, didn't listen to music at all, and didn't have any apps going awry, your battery life could be better.
[Galaxy S II General] lokhor:
I listened to around 30 minutes of music using PowerAmp.

My brightness was at 20% the entire day and a lot of the screen usage was eBook reading with black background + white text.
[Galaxy S II General] Entropy512:
Basically, if you're using the phone and the screen is on, all bets are off. It's next to impossible to do proper scientific tests of drain in those scenarios. However, your available screen-on time is going to be severely reduced if the idle (screen-off) drain is high.

So to really be sure, you need to do a screen-off idle test overnight, so just before you go to bed:

Charge phone to 100%

Reboot (to reset wakelock timers)

Reset timers in CPUSpy

Put phone down and go to bed

When you wake up:

Drain should have been at most 1-2% hour in moderate/low signal

Drain should be around 1%/hour in moderate/high cell signal

Drain should be less than 1%/hour if wifi sleep policy is "never" and you have a working wifi access point at home

Deep sleep percentages should be:

88-92% in very weak signal

92-95% in moderate signal

95% or so in strong cell signal

95-97% if on wifi with wifi sleep policy of "never"

If deep sleep percentages are much lower than this, pull /proc/wakelocks as covered earlier in this thread and post here.
[Galaxy S II General] AndreiLux:
I still don't agree with the cell signal drain, that or we have different interpretations of what a good or bad signal is. I've tested it a week ago after that low drain Wifi 24h test and remained on 3G under the same conditions and had it drain only slightly higher, ~0.3% for Wifi and something like 0.4%-0.45% for 3G per hour. Again this is on what I consider to be a "average to bad" signal since it's on about ~2-3 bars (bars are irrelevant on the international version since they're on a misleading logarithmic scale; average -103 dBm and -18 asu if we want to be correct). On 2G/EDGE I can barely differentiate it from Wifi drain, but there I do have a good signal of ~75dBm.

I'm doing an extended run with more or less real use; I'm 45 hours in now and battery is at 74%, with about 2 hours of FM radio playback, half an hour of screen on, a couple of short phone calls, some messaging, and some chatting, alarms going off and so on, and doing the commute to campus. Deep sleep is still at 97%. (FM radio works in deep sleep, or atleast CPUSpy reports it as deep sleep, it might be some other low power state). I started not to bother with the Wifi anymore and just let it on regardless if I'm in range of one or not, idle drain is irrelevant and I bet it wastes more power if I start switching it manually every now and then.

Also I do not understand your varying deep sleep percentages dependent on cell strength, in my testing there was no change in % from Wifi to 3G to 2G, and I don't see how it would change in a controlled test like this were you stay in the same location and the only reason I can imagine for it to wake up is when it searches for new cell towers, and I don't even know if that's the case, you should be more informed in that matter. One could do a controlled test where we clear the stats as before and then drive around the city and countryside for an hour to see what the effects of cell hopping are.
[Galaxy S II General] luizlee86:
What? How?

Sorry! My english is not that good... I swear I read this whole thread, but I dont know if I missed something. How did you get 74% of battery after 45 hours?
[Galaxy S II General] Molitro:
Hell, Andrei, is that with the stock 1650 battery? Because I still can't understand why I have pretty much twice that drain with nothing waking my phone when it shouldn't be awake.

That 74% seems pretty impossible.
[Galaxy S II General] lokhor:
Ok I'm going to do a full charge before bed tonight then take it off the charger and leave Wifi on overnight.

I do have a question about what gets lumped in with the Android OS Process though - does media playback usually make it increase? I would've thought there would be a Media Server process or something showing up for my music playback, but there wasn't.
[Galaxy S II General] AndreiLux:
I'm not doing anything special. And yes, it's still with the 1650mAh battery, although I also have a 2000mAh one but I only used that one for a grand total of half a day (and I don't like the added 1mm), ironically when this whole discussion about Skype and so on unraveled.

That's with Siyah 2.1b12, 850/850/875/975/1075/1200mV for 100 to 1200MHz, ondemand, no profiles, KI4 modem. Still with the old good Congition 1.5 KH3 ROM with loads of stuff and services that one doesn't need killed off.
[Galaxy S II General] luizlee86:
Hm... I´m still with Siyah 2.0. Didn´t know about 2.1. Flashing right now.

I´ll do the overnight test and see what happens.

One more thing... I know it has been told that using ATK is useless or worst. What do you think about it? There is a thread saying that ATK is really helpful on increasing battery life on Gingerbread.

Thanks!
[Galaxy S II General] AndreiLux:
ATK is a piece of ****. That was used on old phones with less memory and having a lot of apps opened slow them down a lot, we don't need to kill anything on the S2. If you have some apps going rogue in CPU use or network usage, better figure those out yourself, ATK won't be very useful. In my opinion it even kills the battery more to have that running.
[Galaxy S II General] Molitro:
Hell, I'm using almost the same configuration except for the rom (which shouldn't have a noticeable effect), and don't have many services running.

But I reached that same 74% pretty much in half that time, with a very similar use...

I don't know, it's very strange.
[Galaxy S II General] Entropy512:
It's useful for killing rogue wakelockers that you just have to use for some reason. For example, if you wanted Facebook access in early 2011, you HAD to have a task killer on hand. Fortunately, Facebook has eliminated their major wakelock issues.

As to dependency on signal strength - it's partially due to radio power usage, but also due to data speeds.

Lower signal strength = slower data = more time spent awake handling data transfers. When my deep sleep percentages drop on weak signal, the kernel wakelocks aren't going up much - but my userland sync wakelocks do.

As to deep sleep percentages and drain varying between wifi and cell radio - you forget that 6 second svnet-dormancy wakelock.

I have three basic "testbed" configurations (two of which are the same location with different settings:

At home, wifi off - this is the "moderate signal cellular radio" test case, I usually average around 95% deep sleep percentages here

At home, wifi set to "never sleep" - 97% or so deep sleep percentage

At desk at work, no wifi available for "personal devices", extrmely poor coverage, and I rarely use the phone because I'm usually sitting down in the lab. - despite the very low usage, deep sleep usually is down around 88-92%.

Admittedly, there is a possibility that it may partly be my email traffic being higher during the day than late at night, causing more data and more syncs...
[Galaxy S II General] AndreiLux:
That's what I meant, there is no way in equivalent use, and I stress again, we're talking overnight use here as everything else is silly to compare, even with the 6 second delay (i didn't forget it), there's no way such a big percentage difference can be had. We're talking about dozens of kilobytes and no major data transfers being done, so speeds are also irrelevant to have such an impact over that big of a period.
[Galaxy S II General] Entropy512:
Well, cell vs. wifi is only 2% delta in the moderate-signal case. In general (yes, unscientific), my battery life always gets significantly worse when in poor signal.

One thing for sure: If running a controlled drain test by forcing AOS to skyrocket using the following technique overnight with wifi sleep policy set to "never sleep":

ping -i 5 <ip address of phone>

there is NO discernible difference in CPU percentages and actual drain between .7 and .14

See attached zip - both were almost exactly 8h40m, both drained from full to 64% in that time. One was .7, one was .14. CPUSpy frequency statistics were almost identical.

What is strange is that it looks like the phone decided "oh I'm already awake, may as well do some ****", which drove svnet radio management wakelocks way up. It looks like for every time the phone woke for ANY reason, it poked at the radio, and stayed awake for the svnet (not svnet-dormancy) wakelock - the wakelock count for svnet is 6436, and the total number of "wake" wakelocks was 6355. I think the delta is due to an attempt to collect netloc data.

In the process of analyzing the update3 sources. No obvious power management improvements I can see yet, your battery improvements may due to Siyah having 100 MHz support (see my CPUSpy stats - in my case, only half of the time was spent in "accelerate to wait" state.)
[Galaxy S II General] AndreiLux:
Yes, I figured out myself 2 weeks ago that .14 was just placebo/just change of statistics, that's why I updated the thread with that info/assumption. :p

That made me laugh. But it's seriously a problem, it's doing the MHL routines every time it wakes up, now you found out it does something radio related... Did you kill the network lcoation service yet?

I've been running 100MHz for ages, so that's not it. I'm just quoting what a lot of people were reporting since KI3 came out (of which update3 is based from) and it was reported for about a month that there were improvements, I've got no data to back it up, but that's a whole lot of people who are wrong then. It know it doesn't matter much in real use, but Quadrant doesn't just consistently jump 1000 points without tangible reason, so there must be some changes there.

If you're still working on finding the AOS changer, that'd be nice. Reverting the change is more than useful. I'm also going to rewrite the OP.