[BetterBatteryStats] ejstubbs:
At the risk of sounding like a stuck record (reference feature #30 which you have now given us, yay!) if you could allow the data to be sorted by time or by wake count, that would be highly useful. The output from dumpsys is all over the place.

On which subject, here's some alarm stats from my phone from the other night:

Alarm Stats:
net.rgruet.android.g3watchdog
66ms running, 1 wakeups
1 alarms: act=net.rgruet.android.g3watchdog.ACTION_MIDNIGHT_REACHED flg=0x4
com.motorola.PerformanceManager
25ms running, 1 wakeups
1 alarms: act=com.motorola.action.PHONE_READY flg=0x4
com.motorola.blur.service.storagemon
1213ms running, 0 wakeups
23 alarms: act=com.motorola.blur.service.blur.Actions.CHECK_STORAGE_USAGE flg=0x4
android
102790ms running, 11 wakeups
1 alarms: act=android.intent.action.DATE_CHANGED flg=0x20000004
471 alarms: act=android.intent.action.TIME_TICK flg=0x40000004
46 alarms: act=com.android.server.ThrottleManager.action.POLL flg=0x4
1 alarms: act=com.android.service.Watchdog.CHECKUP flg=0x4
7 alarms: act=android.appwidget.action.APPWIDGET_UPDATE flg=0x4
3 alarms: act=android.content.syncmanager.SYNC_ALARM flg=0x4
com.motorola.blur.datamanager.app
36ms running, 0 wakeups
1 alarms: act=com.motorola.blur.datamanager.app.checkin.timeout flg=0x4 cmp=com.motorola.blur.datamanager.app/.DataManagerCheckinService
com.motorola.blur.contacts.data
18ms running, 2 wakeups
2 alarms: act=com.motorola.blur.contacts.ACTION_START_PHOTOSERVICE flg=0x4
com.motorola.blur.service.blur
7110ms running, 55 wakeups
55 alarms: act=com.motorola.blur.service.blur.pm.alarmintent flg=0x4
com.google.android.gsf
5147ms running, 47 wakeups
16 alarms: flg=0x4
1 alarms: act=com.google.android.intent.action.GTALK_RECONNECT flg=0x4
30 alarms: act=com.google.android.intent.action.GTALK_HEARTBEAT flg=0x4
com.iba.ussdchecker
117ms running, 1 wakeups
1 alarms: act=SEND_USSD_INTENT flg=0x4
com.android.vending
59ms running, 0 wakeups
1 alarms: act=com.android.vending.FORCE_UPDATE_CHECK flg=0x4
org.jraf.android.nolock
403ms running, 33 wakeups
33 alarms: flg=0x4 cmp=org.jraf.android.nolock/.NoLockService
com.motorola.batterymanager
540ms running, 1 wakeups
1 alarms: act=com.motorola.devicestatistics.APP_STATS_ALARM flg=0x4
3 alarms: act=android.intent.action.batteryprofile.CHK_ALRM flg=0x4
1 alarms: act=android.intent.action.batteryprofile.DATA_ALRM flg=0x4
8 alarms: act=com.motorola.batterymanager.wlmonitor.CHECK_STATUS flg=0x4
1 alarms: act=android.intent.action.batteryprofile.DATA_CHECK flg=0x4
com.keramidas.TitaniumBackup
538ms running, 1 wakeups
1 alarms: act=com.keramidas.intent.action.SCHEDULE_NEXT_WAKE_UP flg=0x4
com.motorola.blur.service.search
647ms running, 0 wakeups
1 alarms: act=com.motorola.blur.service.search.SCHEDULED_INDEXING_ACTION flg=0x4

What's the difference between 'wakeups' and 'alarms'? 471 alarms for android.intent.action.TIME_TICK looks like a lot compared to everything else but I don't know whether they are actually badness.

At any rate, I assume that the 103s of wake time for com.motorola.blur.service.blur.Actions.CHECK_STORAGE_USAGE are not good. Unfortunately I'm no nearer finding out what caused that.

I've also been tracking down processes which keep coming back to life after being killed, using Gemini to examine and (carefully) disable autostarts. There are some apparent oddities in there (as in: why did they need an autostart at all?) and some that clearly just never want to die. Market seems to be the worst offender, with a list of autostart triggers as long as your arm. I wouldn't be surprised to find "On Second Thursday Of A Month With An R In Its Name" in there somewhere. It seems to be basically impossible to get the thing to stay dead. Not that it seems to do much most of the time - at least based on its CPU usage - but then why does it need to run at all?

---------- Post added at 05:50 PM ---------- Previous post was at 05:49 PM ----------

Is something useful supposed to happen when you tap on a process in the list? I know on the old (Froyo) Battery History it would give you the time that the process had been active (CPU time, or time that it had set a wakelock, depending on what statistic you had requested.). One of the good things about BBS, though, is that it gives you that information right there on the main page. Tapping on a process isn't supposed to achieve anything AFAIK - although I agree FC is not good (not that mine does it, it just ignores it).