yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] chamonix:
Thanks for the feedback, I'll look into those issues.

A backport of the graph is afaik not available but it is indeed a good idea. As the source are available and I plan to do more stuff on graphs I may give it a try.
[BetterBatteryStats] chamonix:
Confirmed: leaving with 'back' does not trigger the method saving the state. Good catch!
[BetterBatteryStats] chamonix:
lol I feel weird talking to myself ;)

An update from what I found out (and learned something at this occasion).

Andoird's life cycle of apps allow to save the state of an app for future use and I make usage of this to save the "custom ref". Now there is a difference between onSaveInstanceState and persisting data because the latter involved database / properties that are not that good for persisting object-trees. I use onSaveInstanceState to save the objects (stats) to a Bundle object and this Bundle object is handed me back when the main activity (screen) is called again.

So far so good except there is a specialty with the "back" button because in term of life cycle it means terminate, I won't come back. Because of this sepcific semantic the state is not saved and here we are.

Basically the app behaves as Android was designed except I feel that is crap because you can't tell a user how to use the "back" button and thus it's behaviour should be transparent and orthogonal and it is not.

Ideas to solve this:

1- handle the "back" button and save the state anyway (if possible) and so breaking with the Android state concept

2- persist state to the database and by doing so be able to save/restore what I want when I want

3- find a "cheaper" way to implement the "custom ref" in order not to save the whole object tree

3- is my favorite because I need that for the widget also (it would be too expensive to store huge object structures when the phone is turned on/off).

As I want a quick fix though I an trying to go for 1- for now and force the state to be saved on "back". As I don't know in how far I can do this the solution may go from "are you really sure you want to quit? You will lose your custom ref" to being transparent to the user (I hope for this one).
[BetterBatteryStats] chamonix:
Ok now it's time to go to bed.... I just hacked option 1. and it seems to work.... elegant is it is seamless for the user as I handle "back" as "home" and by doing so force the lifecycle to do what I want :)

Too tired not to do any mistake publishing it so I will test a little tomorrow and publish 0.8.3 here for a test run.
[BetterBatteryStats] chamonix:
Release 0.8.3

me again :)

Version 0.8.3 is out (no market yet). Could you guys please test the 3 fixes. If everything is fine market will be release in the evening.

Have fun!
[BetterBatteryStats] ebliss:
Just tested, #20 bug resolved.
[BetterBatteryStats] nobnut:
Hi,

Thank you for the latest update. My test results agree with Ebliss above:

#20 - fixed

#21 - see attached screenshot... I am running 200dpi

#22 - still get error popup (but not every time :confused:)
[BetterBatteryStats] thekayman:
Hey .. for me DHD

the back button doesnt seem to exit the app as when I hit back and then go into the app again it it has the last screen and not my startup pref

also weird thing I noticed is if I open the app from a shortcut on my homescreen (second page) and then hit back it takes me back to my homescreen (first page) where as other apps take me back to where I was.

Also when I set a custom ref and hit the back button I dont get the prompt you were talking about and when I go back into the app I have to hit menu > refresh to get results so I guess that means it isnt exiting the app.

ohh and if I kill the app with task manager and then open it again it doesnt show my startup pref's
[BetterBatteryStats] peterbonge:
For #21: I don't see any changes on my Nexus S (240DPI). The graph/line is still too small.
[BetterBatteryStats] chamonix:
What you detail is exactly the result of the workaround: the back button does not behave as you are used to. The reason is something I can not handle in a better way right now: back means the app is being ended and any state deleted, including the custom ref.
[BetterBatteryStats] chamonix:
Are you running 0.8.3 and if yes could you please provide the logcat with the canvas sizes?
[BetterBatteryStats] chamonix:
I don't want to enforce the 'back' button workaround as it is inconsistent with the android concepts but would like to hear your opinion (vote) for keep the behaviour or apply the workaround. Vote is valid stating at 10 votes
[BetterBatteryStats] ithehappy:
@Chamonix- You could try to release a Trial version on Market. It should give the user a chance to see what they are getting for this price.

Regards.
[BetterBatteryStats] nobnut:
And how would this differ from the XDA version?

Sent from my Motorola StarTac using Voodoo
[BetterBatteryStats] ithehappy:
There are plenty of members outside XDA!
[BetterBatteryStats] nobnut:
I follow you now!

Sent from my Motorola StarTac using Voodoo
[BetterBatteryStats] chamonix:
jp.naver.line.android (): Wakeups: 704
Alarms: 704, Intent: jp.naver.android.npush.intent.action.SUBSCRIBE
Alarms: 0, Intent: jp.naver.android.npush.intent.action.UPGRADE

Means that line has fired 704 alarms in 6 hours. That's approx. twice per minute. Either that is bad design or there are settings allowing you to "slow" that down
[BetterBatteryStats] chamonix:
That depends on your device but has nothing to do with BBS. Please take that to Q&A for your phone
[BetterBatteryStats] chamonix:
In a nutshell you have following causes for wakeup you should look into:

neldar.bln.control.pro (): Wakeups: 804
cloudtv.hdwidgets (): Wakeups: 316
com.rageconsulting.android.lightflowlite (): Wakeups: 307
[BetterBatteryStats] reflexr:
Any Update soon?

Gesendet von meinem Galaxy Nexus mit Tapatalk 2
[BetterBatteryStats] chamonix:
Release 1.8RC7

New release is up. There are no fixes in this release, just more logging.

The logging aims at pinpointing the discrepancies occuring sometimes where obviously the times shown are larger than the timespan since the reference.

After reading tons of logs I am convinced that the substraction of "current" from a reference is not the problem but the data taken as reference itself.

For people having problem with the "since screen off" reference: please make sure that you have enabled "Screen off" in the "Watchdog settings" prefs and check if the service EventWatcherService is running. If this service is not running no "since screen off" reference will be saved. If we confirm that I may have to switch from STICKY to foreground service to make sure no agressive memory management kills it.

For people finding inconsistencies in the times I need at least following info:

- what stat/stat type had the problem

- what discrepancy was observed

- at what time did you observ that

- a logcat

- BBS dump showing the discrepancy
[BetterBatteryStats] chamonix:
Every time someone asks for an ETA the release date gets pushed by 5 days :P
[BetterBatteryStats] torchedlh:
Okay, i'll update my kernel and give it a shot.

Unfortunately, keeping wifi off is not really an option as i have little/if any cell phone reception in my office :(

Thanks!
[BetterBatteryStats] Tungstwenty:
And don't forget the baby elephant that also dies (unless 100 likes are collected in FB of course)
[BetterBatteryStats] nam3less:
It appears in my case that the reading that gets shown is "Since Charged" despite having "since unplugged" selected. The way to fix was to switch to any other reading "Since ______" then back to Since unplugged.

Seems like the since charged isn't reading my charging correctly (i.e. phone may never charge to 100% during the evening) or is getting displayed when i don't want it to be displayed. this occurs on the first time I open up BBS after unplugging my phone. After that, it seems to work just fine, showing the "Since unplugged" time rather than the "since charged" time.

Linked is another log cat. Due to the above I mentioned, where I changed from since unplugged to since charged and back again, the BBS dump shows correct info for my RC6 test. Attached is my RC6 dump with correct info and my RC5 dump with the incorrect stats displayed. The same behavior was in both. You can also see some negative battery % lost and mv lost numbers.

These are just the observations i made. I will run another test with RC6 and hopefully get you a correct dump file from that. Then install RC7 so you can get the additional logging.

Log cat: http://dl.dropbox.com/u/13641148/LogCat_Default_Sun0715_140522.txt
[BetterBatteryStats] camspy:
I'm attaching new dump file. It says in BBS that location service is still using a lot of percentage. Lightflow seems to have less usuage now. Do you see anything that is making troubles?
[BetterBatteryStats] EH15:
Can you explain in more detail? I'm not really familiar with this stuff.

I know BLN and Lightflow keep the device away when I have notifications, but shouldn't it go back to sleep once I clear the notifications? And the cloudtv.hdwidgets is actually a clock widget. Why is it causing wakeups from a widget?
[BetterBatteryStats] chamonix:
The problem with your BLN is not that is keeps your device awake but the fact, that it wakes it up (804 times during the reading, that is far too often).

About cloudtv: you are right, a widget should never wake your phone. Except if the dev uses RTC_WAKEUP alarms to do some stuff and in your case that is what happens.

I have no insight in the source of those tools but from their behavior they are doing stuff they are not supposed to.
[BetterBatteryStats] Simba501:
It may not be as bad as it appears. If he's using BLN Pro and has the blinking option enabled, it will appear that it is causing a large number of wakeups. Each blink event is registered as an alarm (every blink on, every blink off) when the device is already awake anyway. Reducing the duration of BLN notifications will lessen wakelocks from it. Alarms will always appear high if blink is enabled. Haven't tested it, but I don't think static is any better on battery.
[BetterBatteryStats] chamonix:
I'd like to see the code on that and see for sure no RTC_ALARMS are used to process that as, as you say, the phone should be already awake. A thread with waits to process something like a sequencer would have been less drastic, together with a walkelock for the time the sequence is executed would have been the pattern I'd have chosen to implement BLN (cf. LedEffects for raph e.g.)
[BetterBatteryStats] p107r0:
next project perhaps?
[BetterBatteryStats] Greedyfly:
Would someone please take a look at my BBS here? I am getting some okay battery but I just know I could get more. I am running the Omega ROM with the newest version of the Siyah kernel.
[BetterBatteryStats] Simba501:
An example. While blinking occurs, BLN is an active wakelock. When static is enabled, you see the number of alarms coincide with the number of notifications.
[BetterBatteryStats] melvinaury:
I attached the logcat, I always has too much battery waste in Android OS. This for 4 hrs disconnected, without using the phone.
[BetterBatteryStats] xelra:
I won't recommend you to not use gmail sync and stuff, since you probably want that.

Anyway, your result is quite good. Don't get too obsessed. More than 90% is deep sleep.

If you want to push it further you should maybe have a look at your espn app.

I'd also get rid of the GO stuff.

The single thing that isn't right per se in that reading is the NetworkStats wakelock. It should only last for a very short time.

Maybe do a

adb shell "echo 8 > /sys/module/xt_qtaguid/parameters/debug_mask"

adb shell cat /proc/kmsg | grep "qtaguid"

and go with that to your ROM or kernel development thread.

I don't think you need to look into getting another baseband, since you had relatively good signal. I think the high cell standby usage comes from NetworkStats. But keep that in mind, too.
[BetterBatteryStats] maatae:
Hello,

First time user here. Does anyone have time to take a quick look at my dump? I just left it on (after I turned off all my apps) while I slept for around 8 hours (with wifi on).

I'm not quite sure but I do see maps being active for an hour on partial wakelocks? I don't really know what's good or what's bad. If you need more information please let me know.

Thank you!

edit: also, don't know if this is relevant but I think I lost about 3% during that time
[BetterBatteryStats] xelra:
You have wakelocks from Kakao Talk, wifi and location services.

WhatsApp is very battery friendly. Maybe you want to switch.

Go into system settings and turn everything off under location.

That might cure the wlan wakelocks, too.

So do another reading after that. The sledgehammer method would be to just turn off wifi.

Personally, I save much more battery on wifi.

You are not rooted, so we can't look at the Alarms. But my guess is that we'll see only KakaoTalk there anyway.
[BetterBatteryStats] mammenj:
My battery discharges most when not in use (ie. overnight) about 50% over 8 hrs with on phone use at all.

I have attached a bbs dump, if anyone can give some hints to improve battery when in sleep would be greatly appreciated.

@BBS Dev, please obsucate all personal info in the logs such as email id, twitter id, etc. Thanks for the great app.:good:
[BetterBatteryStats] yhrn:
The kernel wakelock suspend_backoff is keeping your phone awake all the time and this one seems to be a bit mysterious. If you have Chrome installed you can try this: http://xdaforums.com/showpost.php?p=28676218&postcount=24. Otherwise try to turn off your phone and pull the battery for a little while and start it again and see if it goes away.

I'm sometimes getting suspend_backoff and I just tried the Chrome-related workaround but it's too soon to say anything about whether it worked or not.
[BetterBatteryStats] Tungstwenty:
suspend_backoff is triggered whenever there's a rapid succession of sleep-wakeup-sleep transitions in a short period of time (10 occurrences within x ms IIRC). When that happens, SB makes sure the device is continuously awake for a bit instead of alternating a lot.

The KWL count indicator could give a hint about the source of those continuous wakes, but not a definite answer because it doesn't show their time distribution.

Therefore, it could be Chrome but also something else - you need to narrow it down.
[BetterBatteryStats] mammenj:
I will try the chrome workaround and report back. thanks.
[BetterBatteryStats] Greedyfly:
Anyone?

Additional information here.

http://xdaforums.com/showthread.php?p=28732761#post28732761
[BetterBatteryStats] yhrn:
Hi,

The dumps you have posted are way too noisy, i.e. you have used the phone too much during the period covered by the dump file. Please start by reading the OP on how to produce a useful dump file and post back if you still need help analyzing the result.
[BetterBatteryStats] EH15:
Here is another BBS dump for me. What's the main culprit here?
[BetterBatteryStats] Karpfenhai:
HD Widgets, general Sync and exchenge are your mail culprits:

*sync*_com.android.calendar_Account {name=*********@gmail.com, type=com.google} (com.google.android.syncadapters.calendar.Google Calendar Sync): 29 m 26 s (1766 s) Count:304 2.7%

AlarmManager (Android System): 21 m 41 s (1301 s) Count:9597 2.0%

MAIL_SERVICE (com.android.exchange.Exchange Services): 7 m 8 s (428 s) Count:226 0.7%

SyncLoopWakeLock (Android System): 4 m 15 s (255 s) Count:11297 !!! 0.4%

Disable all sync in the first place, check with care, what do you really need?

Use K9 and set it to pull for your mails, Calendar sync suits perfect manually twice a day per example.

Set HD widget to a lower update rate or screen on only if possible.

Come back afterwards with a fresh (IDLE!) Dump. (read OP for this)

Good luck!

PS, try Phenomenal kernel, disable autobrightness, use only lowest level in indoor circumstances.
[BetterBatteryStats] munkimatt:
Hi all

Hoping someone could take a look at my log for me. I've been very happy with the battery life on my SGS3 until 2 nights ago when it dropped 40% overnight! I've attached my logfile from a 2 hour period this morning.

Thanks in advance!

Matt
[BetterBatteryStats] c_shekhar:
Excellent application indeed... How could it miss my eyes????

my falicitations to the developer.....

c_shekhar
[BetterBatteryStats] nam3less:
Hope you didn't miss me too much :)

This is for RC6. I'm installing 7 now and will test again.

Log cat link (didn't clear since yesterday so some info may be the same): http://dl.dropbox.com/u/13641148/LogCat_Default_Mon0716_105725.txt

Attached are the BBS dump and screenshot.

EDIT: Another observation. Rebooting after unplugging seems to fix the issue and show the correct "since unplugged" time rather than since charged. Rebooting also fixes the over 1 day since charged time and shows the since charged as of whenever I unplugged in the morning. however, it shows incorrect deep sleep as deep sleep since reboot, or unplugged. Attached are those screens as well.

Let me know if there are any problems with viewing any of this or if there is something else you want me to try. Testing RC7 now, like I said. Will post when I replicate the issue.

Happy debugging. :D
[BetterBatteryStats] chamonix:
Here's the good news: based on your observations and one some testing today I think I was able to pinpoint the problem we have with the inconsistent data showing higher values than the "since" time.

I am able to reproduce that every time by doing the following:

- set my prefs to "since unplugged" and "other"

- close BBS "Settings - Apps - BBS - Force close

- Open BBS -> Values are wrong (deep sleep shows it systematically)

- Switch to another "since"

- Switch back to "since unplugged" -> Evrything is fine

This leads me to the conclusion that there is no bug in the way refs are substracted nor a bug in the reference that is retrieved but "only" a refresh problem. I will now go through the code and see if there is - on first load (=onCreate) - a sequence problem causing the refresh to occur based on the wrong values
[BetterBatteryStats] nam3less:
You beat me to my edit. See my edit as well for a few more observations. Reboot seems to fix, but shows incorrect deep sleep for since charged and no deep sleep at all for since unplugged. Furthermore, the since unplugged doesn't refresh after a reboot but I have to change to a different measurement and back to get it to refresh. In my case, I chose since charged and then back to since unplugged.
[BetterBatteryStats] chamonix:
Thanks! Your observation that a reboot changes things are consistent: on boot (BroadcastHandler) the serialized references are deleted (voided). That's the main difference as after that on the first call of StatsActivity.onCreate there is no data from the references anymore. I will dig into the code now but I bet the problem will be:

when created the spinners for stat / stat type are populated and linked to the Adapters. After that the selection of the spinners is set to whatever was defined in prefs. This change is supposed to be processed as a user interaction, causing the underlying data to be updated. Now for whatever reason this sequence is broken, causing the spinners to be updated while the underlying data is still populated with default data instead of the data corresponding to the (now) selected spinners.

I'm going offline now and will try to define a set of breakpoints where I can see the error in the variables before starting to fix things (that's the same procedure as for tuning: first define a baseline, then make changes and compare to the baseline)

Edit: I guess the baselining will take longer than the fix
[BetterBatteryStats] tgeske88:
I am having extremely bad battery life, so downloaded your app. I am not sure exactly how to read these stats, so here is a copy of my log/screen shots. Before installing all my apps and other stuff I was only loosing less than 1% an hour on stand by. Now after having all my stuff on here I'm loosing like 8% an hour, yikes! Please advise, thanks in advance

Here is a link to some screen shots-

https://www.dropbox.com/sh/a4jbff68oydzuef/0HbsTMsV4V
[BetterBatteryStats] t00dy:
LocationManagerService

hy, i have similar problems with LocationManagerService!!!

The long wakelock of LocationManagerService is not always present...it seems it happens randomly. But when it happens, you can only get rid of it by resting the phone!

I am attaching here-PWL and here-Alarms the screenshots (i know it's not of any use, but this is the only thing i have). I will make a BBS dump when this happens again.
[BetterBatteryStats] chamonix:
I have found the issue for situation causing the initially displayed data being inconsistent (see my post above).

The reason for those who are interested: the initial (asynchronous) reading of the references was not guaranteed to be finished at the moment where the views were intially updated, causing the reference to be incomplete. The more frequent the widget updates are the less this error occurs (as the data is also required and the load triggered from there).

The fix is to make that initial load synchronous: 3 lines of code. RC8 coming in a few.
[BetterBatteryStats] chamonix:
Release 1.9RC8

New RC is up, check post #2 for changelog. Hopefully now we have a permanent fix for data inconsistency showing when initially starting BBS.

Happy testing!
[BetterBatteryStats] chamonix:
Sorry but I won't do thread hopping and getting the info together for you. Please post a description of the problem, you analysis as well as proper dumpfiles here and you will get all the help you need
[BetterBatteryStats] chamonix:
You've earned a KB entry for this one, thank you!
[BetterBatteryStats] chamonix:
Looking at the DHCP wakelock count you may have a problem related with the wlan_rx wakeups and you wifi sleep policy, leading your driver to get loaded/unloaded at every awake. That may be a cause for suspend_backoff
[BetterBatteryStats] chamonix:
Please repost a "since unplugged" dumpfile after plugging/unplugging and leaving your phone alone for 4-5 hours. The data attached is not conclusive
[BetterBatteryStats] chamonix:
The screenshot suggests that you suffered from the "refresh" bug fixed in RC8. Please make sure to update and provide a dumpfile so we can look at the big picture.

A few hints about location:

- make sure the caching in Maps is only for wifi on

- turn off wifi when you don't use it
[BetterBatteryStats] chamonix:
As you don't have maps and the problem persists you should try to find the apps requesting for permissions:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

This can easily done by inspecting the XMLs or using a tool like permissions.
[BetterBatteryStats] andry23jsv:
Hi, I need your help please!!

I installed eBuddy XMS as alternative of Viber (doesn't works in JB).

I noticed that: when eBuddy XMS is open (I mean when I'm writing or reading a message with it or when I don't swipe it in multitasking to close it), the corresponding item in BBS is increasing its time and percentage.

But when I close it (swipe in multitasking) the time in BBS is stopping!

Is it normal? If not, how I can stop this?

I attach the dump..

Hope in some help :confused:
[BetterBatteryStats] Sincitybronze:
Chamonix, is there a reason the title of this thread is still v1.8.1?
[BetterBatteryStats] chamonix:
Yes, the current version 1.9 is release candidate and so not release yet. I don't want to draw to much attention to keep the circle of tester small
[BetterBatteryStats] chamonix:
Please read the first posts about how to provide a proper dumpfile please and repost when you got there