yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] dpaine88:
Thanks for the advice man. I downloaded your WiFi app.

The autostarts thing seems to have helped a bit. I only need it for Navigation, Maps and Local so it doesnt look like those will be effected by autostarts.

---------- Post added at 10:34 PM ---------- Previous post was at 10:27 PM ----------

Just turned off the Traffic card, think this might help since it came up very often.
[BetterBatteryStats] NunoPitbull:
Can anyone reply to this please?:)
[BetterBatteryStats] hx179:
hi guys,

i'm posting here because i don't find anything else on google... so you're like my last resource :)

last days i was thinking that i may suffer of battery drain, so i installed this wonderful app.

after some days of use ad tweaking, i find that after 17 hours on battery, i have two wakelocks:

- DPRAM, 52m 37s, 7533/96/7533

- MultiPDP, 42m 15s, 462/0462.

it's obvious that it's something about the internet comunications because when i go into airplane mode the two wakelocks don't get bigger.

when i go on wifi, the DPRAM one goes on to... process, i don't know the tecnhical term.

so, what can i do?
[BetterBatteryStats] Karpfenhai:
Hey there,

Multidpd is background data traffic.

Dpram, hmmm, this indicates the driver for the dual-ported ram, which is more tricky indeed, but since this is somehow related to the modems RIL,i would suggest to ensure the ril matches your current baseband, try getril from market to compare.

Anyway, both WL are related to traffic, so bring it down and the wl will decrease.

We need a dump!

Good weekend. :D

Tapatalked from my Samsung GT9100
[BetterBatteryStats] alexinna:
Yes dump would be nice. Just follow instructions from the post #1.
[BetterBatteryStats] kevindd992002:
Oh ok. I thought you were using an s3 as well. Anyway, what is the normal battery life of the s3?

Also, is it recommended to charge the battery of smartphones to full 100%? I read somewhere in these forums that it is optimized to charge it to 95% only.
[BetterBatteryStats] hx179:
first, thank you very much :) :) :)

second, unfortunately getRIL doesn't work on my phone, i have a samsung galaxy w.

third, this ril/baseband problem could come from the fact that i have upgraded the kernel (only the kernel) of the phone?

I have a stock rom, but i have flashed the kernel of the next version... today i keep the phone as is to provide a clean dump tonight, tomorrow i'll try to update the baseband.

thank you very much, good weekend :D
[BetterBatteryStats] bete69:
thank you

thank you
[BetterBatteryStats] Karpfenhai:
Nope, the kernel should not have any inflow on the modem, but it contains the wifi drivers.

Let's see what your dump will tell us.

Tapatalked from my Samsung GT9100

---------- Post added at 10:21 AM ---------- Previous post was at 10:19 AM ----------

Indeed, charging to 95% only will save your overall battery life, you will be surprised how far it will grow further after unplugging!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] willembos:
I've been using CM10 for a while and I get a better battery life than on my stock rom. However I thought that my battery life can always be improved. So i left my phone at night unplugged for about 8 hours and I saw in the betterbatterystats app that the Google location service was waking my phone frequently. I turned the location service off and ran at night again the app but I still see that my phone wakes up.

Can you guy take a look at the dump file and see if my battery life can be improved?

Sent from my HTC
[BetterBatteryStats] Stileth:
Willembos, try to restart your phone and check again.

Odoslané z GT-I9100 cez Tapatalk 2
[BetterBatteryStats] NunoPitbull:
So I installed this program because I though that the pre-installed App(Holo Locker) was causing a battery drain problem. But as I installed this program, Holo Locker doesn't even shows in process/alarms. So I don't know. Then I noticed in about 6hours, the App Tasker used 337 wakeups.

Can you tell me why Holo Locker or other processes like Holo Notifier/Holo Launcher aren't seen by this program, and if in fact Tasker is the cause of my battery drain? (before it didn't battery drain though).

I attached the Dump Files.

The normal Dump File is since I unpluged untill before i went to sleep.

The Dum File with a (1) at the end its since i unpluged untill I wake up(just now).

Thanks! I really need some help. Aw and a side question, what means the detailed text on Process Tab? The Uid, sys, Us etc, what those means? And what means the blue bar and red bar? Thanks!
[BetterBatteryStats] GoJo ^^:
ccc71.bmw.pro might be it indeed, gonna check how to change refresh rate, not sure i can... i have it on other device and no issues... the other apps are checking every 5min and it's my choice (on all device, no pb) ;)
[BetterBatteryStats] yungskeeme:
After turning off the location settings my stars are better.Haven't been on the phone much but can get more screen time

Here's the dump

http://db.tt/C3vxzHrx

from my HTC One XL using Tapatalk 2
[BetterBatteryStats] kevindd992002:
Why is this?
[BetterBatteryStats] Karpfenhai:
Don't bother to read some pages back, there are also some links.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] kevindd992002:
Do you mean "DO read some pages back" ?
[BetterBatteryStats] chamonix:
Teaser
[BetterBatteryStats] dpaine88:
Sweeeeeeet
[BetterBatteryStats] chamonix:
Widgets

I have had a few complaints about widget(s) not working properly but the feedback was somehome unspecific about the exact problem. If someone who reads this could take some time to describe the problem in details it would help me to fix it in the next release. What I am interested in:

- what widget(s) have the problem

- is it a problem of them not being updated or is it a problem of data not being displayed (in that second case is the data available in the app)
[BetterBatteryStats] vasilisf7:
Why do i get NO OR UNKNOWN SIGNAL100%

AND NO DATA CONNECTION 100%

PLS HELP!

Sent from my GT-I9300
[BetterBatteryStats] kevindd992002:
This is when packet data is disabled.
[BetterBatteryStats] vasilisf7:
Thx.. And what do i have to do?

Sent from my GT-I9300
[BetterBatteryStats] nobnut:
Hmmmm interesting.

Sent from me to you using stuff
[BetterBatteryStats] ejstubbs:
Thanks, I'll look out for that (or should I uninstall my Market version and download the one from the link on this thread?) and get back to you.

Thank you!

I thought I was understanding this this but now I'm not so sure...if I set it to anything other than "on battery", it just shows "-0.0%" for every process. That can't be right, surely?

Another thing: the process sorting seems to go awry at times. This list doesn't seem to be sorted by wakelock time or quantity:

or am I misunderstanding how it's supposed to work? (Not at all unlikely.)
[BetterBatteryStats] ejstubbs:
Well, I tried K-9 mail and, rather unexpectedly, it seems to be a whole lot worse than the stock Defy email client. With the stock client, ProviderThread had 24s of wakelock, with a total of 16 wakelocks set, in 1 h 7 m. With K-9, a number of different processes all with the "com.fsck.k9.K9 Mail" UID totalled 185 wakelocks for 46s of wake time in 1 h 8m. The awake time was a

lot

more than the screen on time as well, and the current draw reported by Battery Monitor Pro was more than twice the 25mA that it reported with the stock email client.

I'm back on the stock email client for now...
[BetterBatteryStats] sowen222:
I haven't seen a problem with K9 on my Sensation, plus I would say that K9 has significantly better functionality than the stock mail client. I'm willing to pay a bit of battery-life for that :-)
[BetterBatteryStats] chamonix:
I haven't fixed the constants yet and will keep you posted when I have. at that time you can install the test version from here without removing the version from the appstore as they are separate packages.

As per the display in process and the sorting: you have found a bug, thank you!

I'll probably release this week end for as many of those changes as possible for the timebox.

edit: bugs are #31 and #32
[BetterBatteryStats] chamonix:
that's a point but I still hesitant to do realtime tracking of the stats because that may cost. But instead of keeping it theoretical I could try to add something for us to do some testing. I will have to study how to a lightweight comparison of wakelock status (I need that for the widget anyway) and implement some sort of warning system. I won't be realtime though as there is no way to check stats except polling.

I added a feature to describe the concept (#33)
[BetterBatteryStats] chamonix:
could you tell a little bit more about your settings:

imap or pop3

how many accounts

push or poll (if push what keep-alive, and if push how many directories)

I have found k9 to be quite expensive under certain conditions but eg reducing the number of dirs to push (inbox makes sense, any other makes no sense in my case), using high keep-alives and reducing the number of accounts reduces the wakelocks dramatically.

A little bit of tweaking the conditions for sync to happen (only if autosync) may also help.

After some tweaks I am pretty happy with k9 using imap and a mix of push and poll hourly and would not want to lose it because of its features.

t

That's of course true for me and may not apply to you.

Note: I found that k9 did not play well with any 'power control tool' as long as that tool was not turning off auto-sync and k9 being set to only sync if auto-sync was on
[BetterBatteryStats] chamonix:
I guess the list of apps behaving well with tools try to control data is very short. See this morning's post about patterns related to that matter. In order for those tools to be a real benefit I believe it is required to standardize a mechanism to tell apps when they can use data and when not. That would be comparable to a scheduler that would dynamically handle alarms to maximize the number of processes to be served in a certain timeslice. There are strategies for that but it's heavy stuff.
[BetterBatteryStats] ejstubbs:
IMAP

Two

Poll, 15 minute interval (same as the stock client). It seemed to be the polling that was causing the wakelocks.

I did notice that it seemed to be polling the Drafts folder as well as my Inbox, but I couldn't find any way to configure it not to do that. I don't know what "keep-alives" are - is it another configuration option with K-9?

I don't use autosync (as far as I know).

All I really want from an email client is to be able to check new emails and occasionally reply to those that can't wait until I can get to a "proper" computer. I don't know what K-9 offers over and above that.

Nah, I don't use anything like that.
[BetterBatteryStats] nobnut:
Good Man!
[BetterBatteryStats] sowen222:
Thanks to BBS :D I discovered that the LocationFriendService was a major offender, keeping my phone awake for long periods (an hour or more) at night, despite turning off all data connections... Disabling Latitude is not an option, because my partner and I make quite a lot of use of it, and it's one of the things that makes my phone a smartphone for me. And I don't want the hassle of logging-out at night then logging-in again in the morning (however if I could automate it, I would).

Well, I appear to have a solution to this issue. In Latitude, I went to "Suggested Friends" and removed all the suggestions, then logged-out and logged back in again. Now the LocationFriendService is down towards the bottom of my wakelock list. :-)

Hope this works for others, and I'll post again in a day or two if there are any changes.
[BetterBatteryStats] carlos67:
@Nobnut / Chamonix

When the phone is in deep sleep, what speed is the processor running at?

If you use SetCPU and set it to 200~1400MHz, will it run at 200MHz when in deep sleep or can it run lower in deep sleep?

My question is related to wether it is wise to have screen off profiles of say...200~500MHz with conservative governor for screen off. Will this keep the CPU higher than it would like when in deep sleep?

Do you guys run profiles for screen off?
[BetterBatteryStats] ebliss:
I have screen off profile in setcpu. deep sleep is still possible when phone is not charging.
[BetterBatteryStats] chamonix:
Is there a reason for the cpu to run at all in deep-sleep? I would say no as there is nothing to process so I would expect the registeres to be saved somewhere and the cpu being shut off (compare to in-memory hibernate on a pc).

I someone with more hardware or kernel knowledge is willing to explain to me why I am wrong and that I a naive userland dev please feel free, I like learning new stuff.

when you say profiles I assume you mean setcpu profiles. I run none but jse setcpu only to limit my max freq to 800 with conservative governor. No OC, UV or other experiments. Personally I find limiting the cpu when screen is off is a bad idea because my feeling is that limiting the processing speed would generate longer waiting times and so longer wakelocks.
[BetterBatteryStats] ejstubbs:
I've got a few more oddities, if you don't mind:

1) I understand about not using the "back" button if you want to keep the custom reference. If I've been off doing other things and then return to BBS by long-pressing the home key and selecting BBS from the list, it does indeed remember the custom reference. If, however, I go in to the app drawer and click on the BBS icon, or if I have the icon on the home page and click on that, it gives me the "no custom reference set" warning.

2) When it gives me the "no custom reference set" warning, the display still seems to be based on some kind of reference point, usually further back in time than "last unplugged" but not as far back as "since charged" (which we know on Froyo is something different anyway).

3) Sometimes the display does not re-draw fully when you come out of the preferences screen. Usually I get the two option bars but no data underneath. This seems to fix itself if I pop in to the help page and back out.

4) I've no clear idea exactly what sequence of actions I had followed before this one occurred, but the other day after running BBS for quite a while and having set a few custom references during that time, I hit the back key to come out. Instead of exiting the app, the dispay re-drew with data based on an older custom reference. I hit the back key again and another set of custom reference data was displayed, based on another, yet older custom reference. I ended up having going back through about six screens of data, each based on successively older custom references, before the application finally exited.

Actually, I could almost see that last one as being a feature, if it could be reliably reproduced... :)
[BetterBatteryStats] chamonix:
very interesting finding, thanks for sharing.... testing
[BetterBatteryStats] nobnut:
Hi Carlos,

As Chamonix said, deep sleep is a separate 'cpu state' below 200mhz. I would also agree totally with avoiding setting screen off profiles. There is a risk that you might prevent your phone from sleeping in certain instances by doing so (dependant upon your kernel, governor used, even ROM potentially in the case of init.d scripts seeking to control sleep/screen off behaviour).

I'm currently testing a script which sets the governor to conservative and other profiles at screen off. During screen on I run at either 1.6Ghz or 800 Mhz depending on what I am doing (both with the ondemand governor). Early results tell me three things:

1. It is all a load of balls as you'd need a supercomputer and an atomic clock to tell the difference in battery usage between the script and just letting it sleep in ondemand

2. It is all a load of balls because I can't tell the difference and I'm bored with testing this rubbish

3. Sod it! I've given up testing this rubbish and am just going to run with ondemand at all times and switch between 1600 and 800 manually as and when I want to.

I have attached a screenshot showing 'deep sleep' as a separate cpu state. Before anyone asks, the reason that my phone shows no deep sleep is that it has been plugged in since being switched on.

In short, my advice would be to remove the screen off profile :)
[BetterBatteryStats] nobnut:
Confirmed as not working for me on an HTC Flyer, SGSII, Motorola XOOM and Nexus S.

EDIT: My evidence is that FriendService is still listed as the #1 partial wakelock. I sign out of Latitude and hey presto, it's gone.
[BetterBatteryStats] carlos67:
That is what I meant to ask. Indeed, does the CPU need to run at all when in deep sleep? It would be nice to know this. If it IS the case that it does not need to run, then having a screen off profile would prevent deep sleep because you are forcing the processor to run at 200MHz minimum, rather than 0MHz thus using more power in screen off.

Does anyone (kernel developer maybe) know about processor behaviour during deep sleep?

Edit:

HOWEVER! in SetCPU when you look at the time in state pie chart, it doesn't have a 0MHz category at all. So maybe this answers my question that the minimum CPU speed is after all, 200MHz.

Anyone got any further theories on this?

Edit 2:

Just a thought - maybe the kernel/SetCPU doesn't allow the processor to go below 200MHz, even though it is capable of doing so. If it did go below, then surely the device would not be able to wake from deep sleep. Hmmmm, interesting.
[BetterBatteryStats] nobnut:
Yes, have a look at my post above, it is a separate cpu state.

Our posts may have crossed.

EDIT: Not the case otherwise deep sleep wouldn't be possible. It would be locked at 200Mhz minimum.
[BetterBatteryStats] chamonix:
because you had wifi on maybe? RIL does not deliver any valid connection info when Wifi is turned on
[BetterBatteryStats] vasilisf7:
So if i have Wifi on it will give me this redding? Sory for the noob Q

Sent from my GT-I9300
[BetterBatteryStats] NunoPitbull:
Anyone can asnswer me on this please: http://xdaforums.com/showpost.php?p=31581263&postcount=8571

Thanks :P
[BetterBatteryStats] chamonix:
Both readings look the same to me:

Since 14 h 3 m 34 s
Deep Sleep (): 10 h 41 m 46 s (38506 s) Ratio: 76,1%
Awake (): 3 h 21 m 49 s (12109 s) Ratio: 23,9%
Screen On (): 2 h 26 m 1 s (8761 s) Ratio: 17,3%
Phone On (): 16 m 37 s (997 s) Ratio: 2,0%

45 minutes awake in 14 hours.

The main causes for awake / wakeup are:

"DPRAM" (): 19 m 44 s (1184 s) Cnt:(c/wc/ec)9422/16/9422 2,3%

That's the dram device driver and is kernel related. Consult your favorite kernel thread to see if there is omething that can be done about it

StartingAlertService (com.android.mms.Mensagens): 6 m 32 s (392 s) Count:294 0,8%

It seems you have recevied a few MMS during this reading. Each MMS causes an awake and some overhead because of the way they are fetched

AlarmManager (Sistema Android): 2 m 38 s (158 s) Count:2930 0,3%

There were quite a lot of wakeups caused my alarms:

net.dinglisch.android.taskerm (): Wakeups: 675
Alarms: 619, Intent: net.dinglisch.android.tasker.ANOFFCHECKORUM
Alarms: 56, Intent: net.dinglisch.android.tasker.ALARUM

You should check the tasker doc or use the search to find more about what profile is causing this
[BetterBatteryStats] NunoPitbull:
So the problem is that Dram? I'm using CF Root b83... If i change kernel I don't have the ext4 access :x
[BetterBatteryStats] chamonix:
It is not THE problem but one of the causes of drain. You should take that info to your trusted kernel dev.
[BetterBatteryStats] hx179:
curious.

i'm on Holo launcher, and i see this high DPRAM thing too.
[BetterBatteryStats] Karpfenhai:
Sven, maybe its not only related to the kernel? In this case it seems related to secril, maybe its the same what we usually know as secril_fd? But to be honest i don't have an educated clue..

Stolen from another thread:

Quick writeup (in order): - onedram_open(): Open /dev/dpram0 - dload_read_dbl(): Read /dev/bml9, 0x5000 bytes - onedram_phone_pow_on(): ioctl 0x6fd0 (DPRAM_PHONE_POWON) - dload_uart_init(): open /dev/s3c_serial0, 115200 - dload_hdlc_init(): init some data related to hdlc parsing - dload_packet_init(): init some packet struct - nop_req() - onedram_phone_image_load(): ioctl 0x6fd1 (DPRAM_PHONEIMG_LOAD) - onedram_nv_data_load(): load /efv/nv_data.bin 0x80000 bytes, ioctl(fd, 0x6FD2 (DPRAM_NVDATA_LOAD), buf_with_nvdata) - onedram_phone_boot_start(): ioctl 0x6fd3 DPRAM_PHONE_BOOTSTART

onedram_nv_data_load() reads the nvdata and passes it as a param along with the ioctl, the nop_req is sent over the uart.

The baseband firmware itself seems to be read by libsecril, but not used (?) - the kernel driver contains code to read bml too when DPRAM_PHONEIMG_LOAD is issued.

So maybe an incorrect ril causes the issue?

Tapatalked from my Samsung GT9100
[BetterBatteryStats] dmulligan:
I was just looking at the partial wake lock info for my tablet and I wanted further information about one. This one was not known to BBS so I tried clicking and long clicking on the wake lock hoping that I could either launch a Google search to find out more.

Please add the ability to copy wake lock information to the clipboard and/or launch a Google search with the same information.

I have the paid version of BBS from the play store installed if that masters.

Thanks,

David
[BetterBatteryStats] chamonix:
Interesting idea: https://github.com/asksven/BetterBatteryStats/issues/274
[BetterBatteryStats] chamonix:
Expect 1.11RC1 in a few
[BetterBatteryStats] jjwatmyself:
Hey, any chance the dev can comment on this please?

http://xdaforums.com/showpost.php?p=31447187&postcount=8446
[BetterBatteryStats] chamonix:
missed that one, thanks for the reminder. The gap is present on any device because it's a placeholder. if you compare the "other" view to the "partial wakelocks" view you will notice that that gap is populated. As all views use the same layout (I personally hate changing proportions when switching views). So as a matter of fact that's by design.

Now I am ready to take up as a change request to make the delimiter between the list entries (you will see it clearly if you hide the graph bars in prefs) more prominent.
[BetterBatteryStats] jjwatmyself:
Changing the delimiter sounds ideal. :)
[BetterBatteryStats] chamonix:
Release 1.11RC1

Next version is up. One new feature: package info screen with perms (notice the drawer with extensive details when clicked) and services started from a package. Time reference has been merged back from 1.9.x so please test intensively, calculations are very tricky but I hope this resolves negative and inconsistent values.

All changes as always in the release post #2
[BetterBatteryStats] chamonix:
Anyone else? two more votes and we are in
[BetterBatteryStats] jjwatmyself:
I'd like to vote twice please. :D

But in all seriousness, the existing delimiter looks about one pixel tall and is not a high contrast color, thus difficult to see by design.
[BetterBatteryStats] chamonix:
I agree but it's the default from holo dark and a matter of taste. Changing it should be like a line in an XML
[BetterBatteryStats] alexinna:
I'm not sure I fully understand how the end result will look like. Can you please provide a sample screen print?

Thanks.
[BetterBatteryStats] RovG:
:thumbup:
[BetterBatteryStats] mariotme:
x2
[BetterBatteryStats] Karpfenhai:
I have no issue with the current delimiter but I'm ready to see a fresh version.

New version works good so far, lets see

whether the "no screen on time after full charger issue" persists after next charge.

Thx Sven!

Update,i didn't reboot after upgrading nor did a replug, but it seems since boot is now a mixture between the former missing since unplugged values and the real since boot:

Since charged does still not show some values:

Not sure if this might be useful to you..

Tapatalked from my Samsung GT9100
[BetterBatteryStats] chrone:
Just tested on the official English MIUI ROM 2.9.14 and this app xould not read any stats. Perhaps different kernel configuration. :)

Sent from my Galaxy Nexus
[BetterBatteryStats] alexinna:
After upgrade BBS didn't show correct values until I plug/unplug. After that I didn't see negative values but need to watch for some time.

Rebooted the phone BBS correctly fallback to "since boot". So far so good :)