[HTC Sensation] Skipjacks:
More on wakelocks! (Everyone, try and contain your enthusiasm. I know we all get a little excited when we're talking wakelocks.....I mean what a thrilling topic!)

So Tobitege and I figured out how to kill those battery draining Google Services wakelocks. (They are battery draining. I don't care what anybody says. They drian during sleep, which is why the battery drops quickly during the first few minutes of use after a long sleep period) If you don't know what I'm talking about, see this post...that will bring you up to speed.

So that's done. (At least for people who have no need for GTalk and Gnow)

But that pesky Android Alarm Manager (And not ActivityManager-Sleep) is still keeping the phone awake nearly 70% the time. (It was 98% of the time before I killed he Google Services wakelocks)

After extensive testing on this issue, I THINK this is a fix for the CM team becuase I THINK (I don't know) that something in the Android framework-res is starting like it's supposed to but not stopping like it's supposed to.

I've frozen just about all but the most essential apps needed to run the phone normally, disabled events and processes within the Android System frameworks-res....nothing has any effect on the Alarm Manager. It still keeps chugging away driven by Android System.

This could also mean that I've just reached my personal limitation of what I understand about this stuff (and quite frankly I think we crossed that brigde about a day and a half ago....) so someone else with a deeper knowledge of the Android framework-res might be able to make more sense out of it.

I've included the dumpsys of my alarm stats. If you can make anymore sense out of it, knock yourself out. I'd love to hear what you think, and maybe I'll learn something in the process. (I will start out by saying that I noticed how intensive Go Launcher, T Mobile's My Account, and Jorte Calender are)

I did find this line to be particularly intriguing

663 alarms: act=android.intent.action.TIME_TICK flg=0x40000014

That's a lot of alarms 1 process. That might be normal for all I know because it updates every minute.

My guess is that one of these alarms below is waking the device to perform some internal maintenance action like it's supposed to, but isn't releasing the wakelock after a set preiod like it's supposed to. That's my guess.

129304ms running, 40 wakeups

1 alarms: act=android.intent.action.DATE_CHANGED flg=0x20000014

663 alarms: act=android.intent.action.TIME_TICK flg=0x40000014

31 alarms: act=com.android.server.action.NETWORK_STATS_POLL flg=0x14

77 alarms: act=com.android.server.ThrottleManager.action.POLL flg=0x14

30 alarms: act=android.appwidget.action.APPWIDGET_UPDATE flg=0x14

7 alarms: act=com.android.internal.policy.impl.PhoneWindowManager.DELAYED_KEYGUARD flg=0x14

1 alarms: act=com.android.server.NetworkTimeUpdateService.action.POLL flg=0x14

3 alarms: act=android.content.syncmanager.SYNC_ALARM flg=0x14

To someone who understands this better than me I might be talking nonsensical gibberish. I welcome someone to explain that to me. (The best way to learn you're doing something wron gis to have someone who understands it tell you you're wrong)

The full dumpsys of the alarms is atatched if anyone wants to try and figure it out.

Incidently the battery life is good on stock battery WITH the wake locks. If the CM team can get rid of the Android wakelocks the battery on Bruce's builds might last until the next passing of Haley's Comet. :good: