yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] alexinna:
Review hike that is responsible for 430 wake-ups

Google maps/location services (post #3 describes what to do)

Review other Google services such as Gallery/Picasa and see if you can sync manually

Wi-Fi is On and running all the time. It causes wlan_rx_wake locks.

Below 2 are kernel wakelocks that you need to pay attention as well:

"modem_usb_gpio_wake" (): 21 m 23 s (1283 s) Cnt:(c/wc/ec)1641/7/1641 2.8%
"modem_usb_suspend_block" (): 14 m 45 s (885 s) Cnt:(c/wc/ec)1853/0/0 1.9%

but I'm not familiar with them. Probably you need to check in kernel thread. Good luck!
[BetterBatteryStats] gogol:
chamonix,

I think now I understood what you mean with the lost ref.

When I unplugged, the BBS has REF1.

When I rebooted after that, that REF1 was lost.

That's why the "Since un-plugged" ref got messed up.

But, that should not matter, because there are other refs like Since Charged, Since Screen Off (not Since Custom Ref).

Probably the Since Charged was lost as well due too reboot? Or all refs are reset after reboot?

I see this as a bug, because user would think Since Charged is just a "time" reference, it should only be reset after charged.

Well, I will wait for the next BBS update and then continue.

Note: As of today, it is working as expected. However, the phone was just of the charger. I will not reboot and see how it goes.

Thanks and have a nice weekend :)
[BetterBatteryStats] mmm286:
Hi.

Could you help me to analyze my batterystats log?

Many thanks and sorry for my english
[BetterBatteryStats] Karpfenhai:
Looks good so far, 42 mins overhead in total, 20 are caused by juice defender, get rid of it.

Could you grant root to bbs to see what alerts are causing your phone awake?

Edit, your device isn't rooted, what a pity, for the experia there are nice undervolt mods, give it a go!

Also next time provide a clean idle dump, this one contains mixed usage.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] mmm286:
Many thanks for your help
[BetterBatteryStats] honest1212:
Thanks a lot. Informed the developer of hike about wakelocks.
[BetterBatteryStats] Rob2222:
Have you found out, why the wakelock part in Tasker since-screen-off dumps is still missing even on RC3? (case4 sent via PM)

At least for me. Do you get wakelock entries in the dump when creating a since-screen-off dump via tasker?

This specific problem persists even after clearing the double-installation.

BR

Robert
[BetterBatteryStats] itchn2go:
No References Created....

what prevents references from being created? I cannot create any references (boot, charged, unplugged, custom) therefore i don't get stats. I got stats on V 1.9.2.1 but nothing after.
[BetterBatteryStats] chamonix:
Release 1.10

It's here, it's fresh...

Changelog won't tell you anything you don't already know except one little thing. Go check yourself
[BetterBatteryStats] chamonix:
Only a logcat can help. Check logging in advances prefs and provide a logcat with a dumpfile.
[BetterBatteryStats] chamonix:
I made a attempt to solve this but tbh I have to do some more testing
[BetterBatteryStats] Людмила:
Подскажите что жрёт батарею
[BetterBatteryStats] Людмила:
Tell me where it goes battery
[BetterBatteryStats] Rob2222:
But you can reproduce it at least and didn't need more files for that case? :)

BR

Rob
[BetterBatteryStats] mariotme:
Loving the new thingy chamonix ;)

Thank you!
[BetterBatteryStats] chamonix:
That dumpfile shows

Awake (): 38 m 7 s

Screen On (): 34 m 52 s

so your dump is not very speakiing

Please read the FAQ on how to provide an idle dump
[BetterBatteryStats] chamonix:
Yes, I just have to see if it's still there in 1.10 as I tried to fix it but didn't reproduce after that. I'll reopen the bug if it happens again
[BetterBatteryStats] Stileth:
Hmm, don't know what else have you changed from RC3, but all I am getting now is the computing dialog and FC.

Ok, after 2-3 restarts of the app it seems to settle down and started to work.

Odoslané z GT-I9100 cez Tapatalk 2
[BetterBatteryStats] chamonix:
Can you please provide a logcat?

Edit: anyone else having that problem?
[BetterBatteryStats] Stileth:
Here you go
[BetterBatteryStats] alexinna:
Dump file was not generated correctly (Kernel Wakelocks section was not generated). Please plug/unplug again and post new dump file.

Also v 1.10 just got release. Please upgrade and use it.
[BetterBatteryStats] chamonix:
I can't see any callstack / FC in the log. What I see on the other hand is that you have root options enabled and are using the watchdog. Have you made sure that both alarms and network stats have been granted root? The log suggests a timeout waiting for su rights on network stats.
[BetterBatteryStats] Stileth:
Well it was message like application stopped responding and just option to close the dialog not the typical one where you have the report button. Yes as soon as the pop-up appeared I have granted the root although it took several seconds for it to appear. The 1st time I opened it after install I hit update button and it started to calculate. After around minute of doing nothing just calculating I tried to close it with back button, menu, home button till it finally closed with the above mentioned application is not responding window.
[BetterBatteryStats] gauv20:
Hello,

I have made a fresh install and I have installed just a few applications.

Is this dump file fine ? Do you have any advices ?

Thanks !

http://pastebin.com/3eTdf3Qx
[BetterBatteryStats] alexinna:
Starts fine for me but I'm not rooted. Will provide more output soon.

P.S. Nice new icon!

---------- Post added at 04:17 PM ---------- Previous post was at 03:57 PM ----------

Getting negative "since" value again even after plug/unplug.
[BetterBatteryStats] LuffyPSP:
nice. lucky i was kinda not lazy this morning when i found out this app.
[BetterBatteryStats] iRide113:
Hi, I was wondering if anyone can tell me if what I got going is good or bad? Not really sure how to read and comprehend the numbers... :cool:

And sorry for the large images... the XDA app wont let me post the other way.... :cool:

But thanks!!!

Sent from my Cappy; using my fingers to push some buttons.
[BetterBatteryStats] chamonix:
Good job! I'll add the details to the how-tos
[BetterBatteryStats] f_padia:
cool. thanks. another suggestion is to display the total time on since charge. Without this as a reference its difficult to make a meaningful analysis of the time spent in wakelock for each app/process.
[BetterBatteryStats] chamonix:
I'd be happy to look into it if you could provide a logcat
[BetterBatteryStats] nikzDHD:
Nice defiantly need this, will try it out and report my findings.
[BetterBatteryStats] chamonix:
With "time on since change" do you mean the "Other Usage" I added last night to 0.5.0 or is it something else?
[BetterBatteryStats] dryhte:
Ok, so, not that I'm complaining (1d7h11m on battery, battery level 41%) but I see in this app under Wakelocks: DataTracker-FD (Dialer) 1h and a bit.

Is this normal behaviour? (the next biggest wakelock count is AlarmManager with 7m)

thanks for your opinion
[BetterBatteryStats] mindwalkr:
awesome app!! Thanks man, it works well so far on my Nexus S :)

Why is it not on the market by the way ? It's too awesome not to be there!
[BetterBatteryStats] chamonix:
What I like about it:

- graphical representation colored bars

- complete in terms of functionality (sensors and GPS present)

what I like less about it:

- main views show only graphics no figures (I'm a figure guy) and those are hidden in detail view

- not an open source project

- it has the same bug nobnut discovered in "network usage" and that bug was not found/communicated (that confirms that there is a bug in 2.3+)

- seems not really an active thread in terms of using the app to solve real life problems
[BetterBatteryStats] danimihalca:
Hi. This seems an interesting application. How do I get that graph on the screen?
[BetterBatteryStats] chamonix:
Let's start with the 4 highest wakelock durations in you list; I believe they are all realted to the first "syncmanagerhandlesyncalarm". That service is documented here (http://www.kiwidoc.com/java/l/x/android/android/9/p/android.content/c/SyncManager) and is responsible for updating the accounts you have under Settings -> Accounts and Sync.

This value seems pretty high to me and I'd suggest that you go through your accounts to check to what apps they belong, if you need them to sync at all, how often the sync and what data they sync.

I'd be happy if you could report your findings back.
[BetterBatteryStats] chamonix:
I've never heard of that DataTracker-FD. Even if your battery life seems pretty OK I'd look into it. I suggest you scan your apps / services and try to find some more details about that app. NExt would be to decide if it's usefull and if yes try to change its behaviour
[BetterBatteryStats] chamonix:
Still a few things to sort out and some profiling to do but it will definitely go there.

Thanks for the encouragements!
[BetterBatteryStats] nobnut:
DataTracker-FD is I believe fast dormancy. Find the 'secret' codes for your device to turn FD off.

*#*#9900#*#* on an SGSII.
[BetterBatteryStats] R3wt3d:
This app is very good. I was using battery mix but I am going to switch to this app only once I am satisfied with my setting

Can u describe what all the datas mean in the list and selection? still j.have no clue what "last" akd "current" means, "sys" "usr" "start" is etc.

I freezed many app that was running in background like maps with bloatware freezer but still have like 40mA using...

Thanks to nobnut aswell for the app name!

Sent from my SC-02C
[BetterBatteryStats] nobnut:
Last - last service/app to run

Current - currently running apps/services

Sys - System app/service

Usr - User apps/services

Start - Number of times the app/service started (potentially waking the phone up from sleep etc)
[BetterBatteryStats] f_padia:
I haven't installed 0.5 yet but I don't think other usage is what I mean. All I mean is to display how long the phone has been running on battery. For example if something has had a wakelock for 1hr since charged, this would be bad if you have only been on battery for 3hr. But if you had been on battery for 36hr (highly unlikely I know) it wouldn't be too bad. So all I mean is to display how long since your last charge. Does that make sense?
[BetterBatteryStats] nobnut:
I think you mean how long since the device was switched on. How long since last charge is already included in 'since charged' and 'since unplugged'.

Sent from my Motorola StarTac using Voodoo
[BetterBatteryStats] nhshah7:
very excited to try this out. thanks for all teh hard work :)
[BetterBatteryStats] nobnut:
I understand, thanks. But it does cause partial wakelocks (for some people - myself being one) which is not good for battery life.

EDIT: My logcat goes nuts every 30 seconds with FD enabled :(

Do you work for Nokia Siemens Networks? ;)
[BetterBatteryStats] chamonix:
Here's what I am using:

<supports-screens android:anyDensity="true"
android:largeScreens="true" android:normalScreens="true"
android:resizeable="true" android:smallScreens="true"/>

obviously this is what is supposed to work but isn't so it's on google's side what seems to be confirmed:

http://xdaforums.com/showthread.php?t=1228172

I hope google gets this sorted...
[BetterBatteryStats] MPKO:
No i dont, but i see you understand my point :-)

It would be better to recommend something like this... there is a way to check if the network is "well behaving" for smartphones. You disable the fd with code *#9900# and then do e.q. browsing and immeaditly go to *#1100# to see the "rrc state". If it takes long time, more than 10s to go to idle state, then it is better to enable fd.

Best combination would be that you would see rrc state to change from "dch to fach to pch in 5-10s time. In this case it is better to keep fd disadled. NSN is the only mobile network vendor supporting network controlled fd and cell pch state which are really good for the battery life.

Cheers!
[BetterBatteryStats] nobnut:
Yes, as I suspected.

By the way, did you hear about the new Google uniforms?

Remind you of someone?

#justsaying
[BetterBatteryStats] nobnut:
Good advice!
[BetterBatteryStats] chamonix:
The recommendation is in relation to a problem with a specific wakelock, not a general one. In other words if there is no wakelock problem there is no need to disable FD. When for whatever reason (poor RIL implementation, no support by carrier, standard that is not a standard or has to many custom implementations) the phone misbehaves in regards to FD in such a way, that is does not go to sleep when it's supposed to I think it's fair to suggest a workaround.

In other words I think we all agree: if it works don't fix it ;)
[BetterBatteryStats] nobnut:
I agree that we should agree, as I believe that we are basically in agreement... which is a shame as agreeing is totally against my personal philosophy:

Never, ever conform :p

EDIT: The first $500 going to charity tomorrow. Let's get to 1,000 Market downloads soon!

Thank you for supporting this great app everyone!
[BetterBatteryStats] MPKO:
I woud say that you have been misreading the stats if you think that fd implementation is causing wakelocks. Fd implementation is only measuring the data inthe ue buffer. When some application has triggered some network acticity, the ue fd implementation is only measuring the data buffer size. When fd realizes that there is no data in the buffer it sends a command to baseband to send rrc connection release message towards the network. So fd happens always AFTER the acticity triggered by some misbehaving application. So i think you didnt find the root cause, you only make it to disappear from your stats.

Cheers!
[BetterBatteryStats] Optic2:
Been messing around with BBS today. Here are a few of my highest partial wakelocks.

AlarmManager

Android System

31m 35s (1895 s) Count 901 4.3%

GTALK_ASYNC_CONN

Google Services

3m 30s (210 s) Count 20 0.5%

I don't even use GTALK, and its frozen.

Checkin Service

Google Services

2m 12s (132 s) Count 386 0.3%

Any ideas on how to reduce?
[BetterBatteryStats] chamonix:
I think we basically agree. What I uderstand from what you say is that there is no reason why FD is something that should get out of the radio module / modem / RIL as FD is some sort of handshake between the radio hardware and the network.

Am I correct till there even if I'm sure I didn't use the right terms.

Assuming yes there is still a but: the effect of FD obviously crosses the boundaries of the radio modules by having side effects into the userland (term for whatever happends above the kernel). Now the reason why that happens is not clear to me neither as I don't see and reason for that but the fact is it does. As we don't have the sources of the RIL (afaik) we can't check on that.

Now what has been found (and that is not by us) is that side effect (I can only speculate here but I guess the state about that "handshake" is propagated to the userland) generating wakelocks. As nobnut already stated that behavior can be observed in logcat where bursts of entries are observed. Those may come from a bad implementation or there is a purpose, or we think e talk about the same thing but the term FD is being misused.

To sum it up whatever samsung or google (I don't know if this problem is specific to sgs2) has implemented on top of FD or around FD is causing partial wakelocks. A workaround (not solving anything except geting rid of the wakelocks) is to turn what android calls FD off. The footprint of this workaround in terms of battery life is positive and it has also been noted that there is a dependency to the network providers (and/or their support of FD) as the problem does not occur for every user.

To make a parallel as we had the discussion about Juice Defender: JD does nothing wrong by turning off data when it is not used. The problem is that no app is able to deal with that because they rely on data being on. Result: apps cause huge and frequent partial wakelocks trying to use data and failing (with timeout and retries) causing high battery drains. Now JD is not the caue of the wakelocks but the reason, the cause is the app holding those wakelocks for no reason.
[BetterBatteryStats] mattdub1:
thanks again for the help, i already removed my sense account which is why i thought this was so weird that it was possibly syncing with sense... i am going to try rebooting and see what happens tonight i guess. Were the other processes running anything to worry about? such as whatever *vibrate* is when i don't use a vibration for ring or text , or what about alarmmanager since it had over 2000 ?
[BetterBatteryStats] chamonix:
1. GTALK_ASYNC_CONN != google talk app so there is no contradiction there. Unfortunately we have not found any good explanation for this behavior and there is no source to study

2. AlarmManager: well known candidate. It is not possible to find the cause with android means as there is no API to query AlarmManager for its active alarms. The good news is there still is a way to find out. Serach the thread for "sysdump" and you will find a few really good and detailed descriptions on how to proceed and what to look for.
[BetterBatteryStats] chamonix:
I hope that you get rid of the hotspot by clearing the account. Once this is done you will find a completely different picture and maybe also more candidates. In your case thegap between the first and the second drainer is so high that it's absolutely the right procedure to first focus on that one and to proceed in iterations (see the basic rules from the how-to).

I'm impatient to read how things are progressing
[BetterBatteryStats] mattdub1:
thanks a bunch, you guys have been a great help and i wouldn't be able to trouble shoot this without your app and your support
[BetterBatteryStats] t0ph0id:
My main wakelock that I'm trying to fix is AlarmManager, I've searched the thread for that which led me to sysdump, searching the tread for that isn't giving me many results.

Please could you link the advice given to reduce AlarmManager to the first page somewhere as it seems a lot of people have this same problem.

And thanks for this awesome app!

Downloaded the XDA version but then bought the market version to support you.
[BetterBatteryStats] nobnut:
This post will help you out. If you disable reminders in your calendar, AlarmManager partial wakes will drop... unless you need reminders however.

It also gives an example as to why I ditched BLN. Not worth the aggravation in my opinion.
[BetterBatteryStats] nobnut:
Hi Chamonix,

It has been a while since I saw you mention this. I'm not looking for an ETA or anything, just wondering if you are still tinkering with the concept? :)
[BetterBatteryStats] nobnut:
AlarmManager, yes. The time awake isn't too high but the number of wakes is excessive. See the preceeding posts for some help.

You are also signed in to Google Latitude, and the friend finder service is causing you some trouble. If you want it enabled, you will just have to live with it. However, if you don't need the friend service, just sign out of Google Latitude.

Also, if you look back over the last few pages, you will see some inofrmation relating to 'CSPush', raised by a fellow HTC user. This is more than liely caused by you being signed in to the HTC Sync service. I would suggest that you 'remove' this from within Settings > Accounts & Sync. You can easily re-add it when you want to download something from HTC Hub. If you leave it signed in, it will play havoc with your battery ;)

From your 'Services' you can see that these apps just run and run, even when you don't need/want them to. E.g.

com.htc.htchubsyncprovider (com.htc.htchubsyncprovider.service.WDMService)
Active since: 10 h 26 m 50 s
Last activity: 39 m 42 s
Crash count:0
[BetterBatteryStats] sowen222:
Thanks for the response.

I use HTC Sync because they promise a backup service at some point, but also a tracking service in case I lose my phone. I'll take a look at whether I really need this.

Latitude is one of those features that makes my phone a smartphone ;-). I will leave that running, although I wouldn't mind being able to kill automatically it at night and re-enable it in the morning. Perhaps I need to root my phone after all.

I'll check out the preceding posts for AlarmManager. I don't have root, so I can't do a dumpsys, but I'll see what info there is.

The odd thing is that my phone is "Awake" for an hour or 2 solid before I wake up to use the phone. Can't think of what's causing it - I turn off all data-connectivity at night.
[BetterBatteryStats] alexinna:
Added BBS dump file.
[BetterBatteryStats] alexinna:
Overall result it's not bad (18% in 6+h with 1+h screen on). Map/location services is still waking up you device.

Also did you watch CloudTV during the dump period? Because if not this app has many wakelocks.

Ideally as post #1 describes idle is the best dump file for analysis.
[BetterBatteryStats] itchn2go:
installed new version 1.10 and still cannot create references therefore no stats (plugged & unplugged then rebooted). Alogcat attached. Like I said earlier 1.9.xx worked.

HTC Rezound on Venom ROM
[BetterBatteryStats] chamonix:
I/References( 4811): Create ref custom_ref at 24 m 56 s
I/References( 4811): Create ref since_unplugged_ref at 24 m 56 s
I/References( 4811): Create ref since_charged_ref at 24 m 56 s
I/References( 4811): Create ref since_screen_off at 24 m 56 s
I/References( 4811): Create ref since_boot at 24 m 56 s
I/StatsProvider( 4811): Retrieved ref: Reference custom_ref created 0 s (Wl: null; KWl: null; NetS: null; Alrm: null; Proc: null; Oth: null; CPU: null)
I/StatsProvider( 4811): Retrieved ref: Reference since_charged_ref created 0 s (Wl: null; KWl: null; NetS: null; Alrm: null; Proc: null; Oth: null; CPU: null)
I/StatsProvider( 4811): Retrieved ref: Reference since_screen_off created 0 s (Wl: null; KWl: null; NetS: null; Alrm: null; Proc: null; Oth: null; CPU: null)
D/memalloc( 123): ashmem: Freeing buffer base:0x44f6e000 size:3768320 fd:82
I/StatsProvider( 4811): Retrieved ref: Reference since_unplugged_ref created 0 s (Wl: null; KWl: null; NetS: null; Alrm: null; Proc: null; Oth: null; CPU: null)
I/StatsProvider( 4811): Retrieved ref: Reference since_boot created 0 s (Wl: null; KWl: null; NetS: null; Alrm: null; Proc: null; Oth: null; CPU: null)

Ok, that's pretty clear. I will add some logging to the serialization process of refs. It seems that something is going very wrong when writing the files (they get written so it's not a problem of permissions but rather of Java serialization. I may write a little test app for you so that we can try to narrow down the problem.

Edit:#261

Edit2: I can't see any WriteXXXReferenceService in that logcat. Could you please provide a logcat where you create a custom ref?

Edit3: nor can I see "Received Broadcast xxx" where xxx is one of ACTION_BOOT_COMPLETED, ACTION_POWER_DISCONNECTED

This tells me you haven't plugged/unplugged either, at least not in the timespan covered by this logcat
[BetterBatteryStats] JoshReuben:
+1

I powered off, counted to 3 and powered back on. Icon had changed to the cool new green battery and all working sweet. I'm really loving the update so far, nice jump over the previous one.
[BetterBatteryStats] chamonix:
A logcat with that would be great.
[BetterBatteryStats] mmm286:
Hi.

Could you analise my battery stats log?

Thanks and sorry for my english
[BetterBatteryStats] chamonix:
Since 15 h 1 m 15 s
Deep Sleep (): 13 h 9 m 24 s (47364 s) Ratio: 87,6%
Awake (): 1 h 51 m 50 s (6710 s) Ratio: 12,4%
Screen On (): 1 h 9 m 39 s (4179 s) Ratio: 7,7%

Awake - screen on = 40 minutes potential.

This one is repsonsible for half of it:

JuiceDefender.Service (JuiceDefender): 20 m 2 s (1202 s) Count:1761 2,2%

Drop JD, take another reading and post another dumpfile
[BetterBatteryStats] Charmacas:
Please remove this post!
[BetterBatteryStats] alexinna:
Can't provide logcat because I did plug/unplug after I posted BBS dump. Attached files reflect situation when "since" is not negative anymore but value is incorrect because it was negative to begin with.
[BetterBatteryStats] yahyoh:
WOW new builds rocks :cool:

thx@chamonix for all ur hard work

there is no problem with su permission loop like 1.9.2 :victory: