yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] nm8:
Hi Op

I don't know if this is related, but since I installed 1.13.2 last night, I am unable to record phone calls. I get a message saying media scanner is running...
[BetterBatteryStats] bso44:
I'm getting this same partial wakelock. Any help?
[BetterBatteryStats] TheMysteriousOne:
When I set a custom ref, I still see the G+ wake lock from before.

http://db.tt/lpahlXTq

The awake time is lower than the G+ wake lock time.
[BetterBatteryStats] chamonix:
Thanks for the feedback. The version is rolling out on gplay and will hopefully stop the crashreports
[BetterBatteryStats] chamonix:
Well that has certainly nothing to do with BBS. Mediascanner unmounts the sd so if your call recording save to the sd that would be the problem. Mediascanner is a process that indexes media files. Its runtime will vary depending on how many files/directories it has to index. A corrupt partition is also known to cause mediascanner looping forever
[BetterBatteryStats] brunek:
I saw the file attachment was bad..Here it is again..
[BetterBatteryStats] Nightshadow931:
I'm still getting FC's.

Here's a logcat

http://db.tt/x6oqCfX8
[BetterBatteryStats] kofe:
Hello everyone!

I kindly request your help, please!

Can someone tell me if this stats are related to the modem that is not suitable to my country?

Or there is another problem that i need to fix?

I am running XXEL4 modem and ril, and I live in Romania, Europe, and I am on Cosmote carrier.

Running CM 10.1 temasek's unofficial latest nightly + latest temasek's kernel on my I9300.

Any help would be great, and I thank u in advance.

Have a nice day!
[BetterBatteryStats] michael-oc:
Any idea what is causing the Wakelocks for internal.telephony.gprs-reconnect.0?

Gprs is disabled, could not find any helpful info.
[BetterBatteryStats] chamonix:
1.13.4B1 with refactored database connection/locking. Please test if you have had FCs previously. I will not release any new fix to gplay until I have valid test feedback
[BetterBatteryStats] Nightshadow931:
It still FCs here.Do you want another logcat ?

EDIT: After clearing data, and plug/unplug my phone from charger, it seems to be fine.

However, I get this message sometimes still

Selected 'from' or 'to' reference could not be loaded.Please refresh.

But everything shows fine though, no FCs so far.

EDIT2 : Now it FC'd again.

Here's another logcat.

https://www.dropbox.com/s/xxhnhaxxsugygt7/logcatt.txt
[BetterBatteryStats] Nightshadow931:
You should let your phone to 'sleep' for more time, like few hours.

And you should grant BBS superuser permissions.Go to settings -> advanced -> root features and tick it.
[BetterBatteryStats] chamonix:
My answer was not a joke either: on android/linux the internal counters are frozen while the phone is plugged. If your is plugged then the message is logical and fine, if your phone is not plugged but BBS still shows it is then there is something wrong with the state that comes from the kernel
[BetterBatteryStats] matthew_goodman:
Thanks for the reply. I have now give the app root permission. How long should i leave it before uploading the logs again
[BetterBatteryStats] eushaun99:
At least 4 hours.
[BetterBatteryStats] Karpfenhai:
A certain period, let's say 3-4 hours, get a fresh reference before starting, just plug the charger a few seconds.

Tapatalked from my Galaxy SII
[BetterBatteryStats] chamonix:
I is so annoying that I can not reproduce. I have been doing a lot of reading and there are a l of mentions of that problem as well as many different possible causes, event android version dependent ones. A contentprovider seems to be the way to go so another complete refactoring is waiting for me.

I really appreciate you taking the time to test and report!
[BetterBatteryStats] brunek:
Can someone help.. how do you solve baseband_xmm_power? It is in kernel wakelock,while in partial wakelock there isnt any significant wakelock.. It starts when i disable wifi and make a fast reboot,over night,and it can`t go into deep sleep. In the morning when I reboot phone, turn on wifi it normally goes in deep sleep and the wakelock stops..:confused:
[BetterBatteryStats] rignfool:
I blamed my calendar widget... and it went away...
[BetterBatteryStats] dEris:
Hope you know you cannot attach a text file in Tapatalk. Reason why some people just paste it.

[DEVICENEXUS⁴] [ROMXYLON] [KERNELMATR1X] [RECOVERYTWRP]
[BetterBatteryStats] chamonix:
The reading took me longer than the coding and I really hope I did things right. Please test if you were still having the FCs and report what android version you have had the FCs on
[BetterBatteryStats] Osyx:
You can at least use hide spoilers;)
[BetterBatteryStats] brunek:
Can someone help me please??I posted 2 times and nobody cares..:laugh:

Is the attachment ok or I have to do something else? My battery is getting on my nerves and if someone doesnt help me soon my phone will have a fight with my bedroom wall!:D
[BetterBatteryStats] Nightshadow931:
Looks like you did it. :)

No FC's anymore. :good:
[BetterBatteryStats] n3gkiwi:
Got a general question. Do alarms really matter? I mean if your partial wakelocks are okay and your Awake/Screen On ratio is okay, does it matter if some apps have high alarm counts in BBS?
[BetterBatteryStats] poo706:
Great information, thanks! I got Autostarts, grouped by application, and expanded Google Services Framework. I was surprised to see so many triggers! Am I focusing on just the After Startup triggers, or all of them?

[poo]
[BetterBatteryStats] chamonix:
Considering that on each wakeup your phone stays awake multiple seconds and that that time is not accounted (all) in the wakelock time wakeups can have a huge impact yes. Compare it to powering your engine on and off for five minutes compared to letting it run for 5 minutes. The first would be far more consuming
[BetterBatteryStats] miten_sheth:
Any help for the non rooted s3..

Heres the dump..

http://db.tt/W7fsphGW
[BetterBatteryStats] tramp20:
Hi chamonix,

I was always happy with all versions before 1.13.

Yesterday I made the market update to 1.13.3.0, had some problems with the stats not shown. So I deinstalled BBS and did a new installation.

This morning after a night with flightmode on my battery had only 34% (usually 98%).

The culprit was BBS :(

I downloaded a v1.12 to use this version now.
[BetterBatteryStats] groaner:
Thanks!

I looked at the Wifi settings and it is not checked ie, it is off.

is there another place I need to look?

Where did you see that info in the log, so I know how to identify it?

Also if I look at my Battery Usage screen I can see there that the GUI is not showing WIFI as having been on since I left home (i turn it off at work)

Thanks alot!
[BetterBatteryStats] chamonix:
In your previous post wifi was on over one hour and the time wifi was on plus the time your screen was was equal to the awake time. This reading looks different. Could you please post the stats for this reading or retake one and post both infos
[BetterBatteryStats] Entropy512:
There are no wifi problems in the GS2. The wifi chip works as intended - if a unicast packet comes in, an interrupt is fired. Unfortunately on the GS2 takes longer to resume from suspend than its predecessors (the radio interface hardware takes a while to wake up), so a periodic wakeup due to an incoming packet has an unusually high penalty. The "accelerate to wait" behavior of the Sleep of Death patch doesn't help in this regard.

The wifi chip isn't to blame because it's doing exactly what it's supposed to - if you receive a packet addressed to you, you have to handle it. The root cause (an app driving excessive data usage) is where the blame lies. It happens more often on wifi because a lot of apps are programmed to be less careful about data usage on wifi.

Skype is a notorious example of this - On cellular data it's a moderate drainer, but on wifi, frequent incoming UDP packets keep the device awake.

For more, see http://xdaforums.com/showthread.php?t=1290020

Unfortunately in its current state, BetterBatteryStats is useless for troubleshooting problems like this, as it only shows userland wakelocks. If a user is experiencing kernel wakelocks such as:

svnet-dormancy (Cellular data, any data transfer has a 6 second wakelock penalty)

wlan_wake (Incoming packet caused the wifi chip to fire an interrupt)

fuel_alerted (this one IS a kernel bug in the fuel gauge driver)

It will not ever show in BetterBatteryStats

As a result, over in the I777 forums, I no longer recommend that users install BBS, and instead go straight to dumping /proc/wakelocks. On the I777, this file shows the complete story because PowerManagerService passes partial wakelocks down to the kernel individually. On the I9100, PowerManagerService lumps all userland wakelocks into a single kernel wakelock so there's still a use for BBS on that device if PowerManagerService shows a high sleep_time.
[BetterBatteryStats] groaner:
I just thought of something. Are any of you using a launcher, like Launcher Pro?

I do and wonder if that could lend to battery drain somehow.
[BetterBatteryStats] :
A little, but not nearly enough to explain your drain.

Sent from my MicroTAC 9800X using speech to fax modem
[BetterBatteryStats] nobnut:
There is no difference between these two statements, they are both correct and say fundamentally the same thing.

...which is the purpose of BBS and a purpose which it fulfils very well.

...which is fine as far as it goes but doesn't take account of the whole picture. As you have said and also as Chamonix has previosuly stated in this thread, the activities which you refer to are not covered by BBS. But this does not mean that BBS is not useful for the purpose for which it was designed. It's not for me to say, but possibly Chamonix intends to add in this functionality in the future.

I follow your argument and understand, but by recommending to people that they do not install BBS is potentially depriving them of the facility for which it was designed and does deliver.

In short, yes, you are quite right but by not installing BBS and providing their dump, I777 users are able to capture partial wakelocks but are by definition unable to extract the other benefits afforded by BBS. I.e. What is the harm in doing both?

Following this line of 'logic', an analogy might be that as wifi (or wlan as it should be referred to) is known to prevent sleep in certain apps (e.g. Skype), users should never use wifi. This is quite clearly a non-sensical argument as wifi provides other benefits to users which outweigh the 'cost' of preventing sleep in Skype ;)

As BBS has no 'footprint' and does not in itself cause any detrimental effect on battery or device performance, why not use it? It provides countless benefits other than the one to which you quite correctly refer... even though it wasn't designed for that purpose.
[BetterBatteryStats] chamonix:
Thanks for the precisions. I guess we are saying the same thing but you certainly expressed it better ;)

I will look into retrieving info from proc as I see that info as a complement to the info provided by the battery service (userland) but I don't see it as a replacement (battery service delivers time info about Wakelocks as well.

The use case I will work improvising as a feature is for the case the total awake time is much higher than the partial wakeLock sum and for that cases (EG phone does not sleep at all) : retrieve the relevant info from the kernel. Whether wakeLock dumps or other PM logs will help me there is not clear to me yet so I am grateful for any hints in that direction

[edit] there is still something puzzling me:

The behavior you describe is a wakeup on some interrupt and my understanding is that this is to be expected when the wifi policy is set accordingly. My observation is that since 2.3.5 and under certain conditions wifi would still wake up even if the policy is set in such a way it shouldn't
[BetterBatteryStats] nobnut:
Indeed, therefore it can be said that the SGSII does have a wifi 'bug'.

Rhetorical question... is it wifi causing the wake, or the rogue app causing wake when wifi is available? (Chicken and egg)

Either way it doesn't really matter as the root cause lies within the app, or can at least be controlled from there.

Moral of the story? Switch off wifi when not being used, or don't use the app.

Simple.
[BetterBatteryStats] :
Following up. Set all emails to "push" last night. I didn't edit the times for what's peak, and what's not however. I'm unsure if push on off peak hours ~= push on peak hours.

Either way, nothing to confirm my original hypothesis. The ActivityManager-Launch count is much higher however.

Picture and attachment = email push
[BetterBatteryStats] nobnut:
Your findings are totally consistent with my previous findings. I wasn't able to find a single email client that would allow push with something resembling a healthy wake count.

I've read lots of posts in this and other threads from people claiming otherwise, but there is no substance to these claims. I've tried (almost literally) every email client under the Sun and one day they will behave... the next day the partial wakelocks go absolutely nuts.

On a side note...

This is a good example of what made me fall out of love with Android and move to WP7 (which I love now more than I ever did Android), namely:

1. Inconsistent background service handling / irrational, inexplicable and uncontrollable periods of battery drain (and not just relating to push email services - location based activities is another example - fast dormancy issues is another)

2. The total fragmentation of the Android OS across manufacturers, device models and device types (phone/tablet) - now catastrophically ruined by the advent of ICS which will 'dumb down' the tablet experience and 'compromise' the phone experience

3. The pathetic attempt at an AOSP style/theme by Google (hideously ugly, whoever made it needs to be taken up to the roof of their headquarters and thrown off)

4. Butt ugly manufacturer themes (e.g. TouchWiz) with the possible exception of HTC's Sense (if you like that sort of thing)

5. Non-compliance with GPL requirements (almost every manufacturer dragging their heels until the last possible moment to release, at some point in the past)

6. The real killer for me though is the bare-faced hypocrisy shown by Google and manufacturers alike. Welcoming community development? Balls. Why the invalidation of warranties for Bootloader unlocking? Why prevent movies from being rented/downloaded from Market on rooted devices. There are other ways in which copyright could have been protected. Two-faced? I'd say so. Besides, the day that Samsung gave SGSIIs to the CM team, the Tab 10.1 to Supercurio etc is the day that I lost interest. It is great for the development of Android, don't get me wrong and I have total and utter respect for all Devs. The fun is taken out of it for me now. It's like stealing a car to joyride, just to be told that the owner of the car doesn't mind and wants you to go as fast as you can...

Time to get out of the car. It's just become boring.

My list of woe goes on but I can't be bothered to type anymore as I am sure people won't even want to read this.

JFTR - I still have all of my Android devices but the only ones I use are tablets (until Windows Phone 8 arrives - which I hope is before they get ICS)
[BetterBatteryStats] :
My battery drain with WiFi on, and push enabled, was the same as my normal drain. I wasn't expecting that; I assumed I would wake up to much less battery. My typical night time set up is email set to manual, and I normally run a screen off/wifi off policy. I do my best to keep apps in check however, so I'm sure that goes a long way towards limiting wakelock(s).
[BetterBatteryStats] nobnut:
If you can replicate that every day, you are doing well. Under those circumstances I would often find that if left asleep for 5-6 hours, 9 times out of ten, at some point (during the push hours with wifi on), the phone would wake every 45 minutes or so and stay awake for up to 10-15 minutes). It was always email related and drove me insane.

This was with the SGSII and other devices, across loads of different ROMS.

Bah.
[BetterBatteryStats] :
I have no doubt that I have now jinxed myself :eek:
[BetterBatteryStats] groaner:
Just a quick update

The blue blocks and dips are from me doing some browsing and updating this thread from my phone.

Obviously the 1% per hour wish its not happening. (see attached in the thumbnail)

This is before, when I was down to %50ish percent after 9 hours. 25% difference but still will not be the 4 days that some are reporting.
[BetterBatteryStats] crypticc:
Google + which wakes up to sync even if to go back to sleep when the service realizes it its set to not sync? Facebook chat which enabled itself by default. also similar wake up device to find no sync is needed.

Calendar notifications remains my biggest killer?
[BetterBatteryStats] TECK:
Why would you want to disable this? It is saving you battery if your network support it... and Bell does.
[BetterBatteryStats] XlAfbk:
Got a little problem here I can't figure out. Idle consumption is quite high lately with usually no unusual wakelooks. Logged it tonight and during the first half battery drain is okish (not good but better than it usually is these days around), but at some point I woke up and opened Talk to read a msg I had received. From there on it's straight downhill.

But in logcat and dmesg I can't find any hints to Talk keeping the phone awake. Instead it's full of identical entries (60 of them to be exact), quoted below.

extract from BetterBatteryStats:

===========
Other Usage
===========
Awake (): 4 h 32 m 8 s (16328 s) Ratio: 52.4%
Screen On (): 10 m 39 s (639 s) Ratio: 2.1%
=========
Wakelocks
=========
GTALK_ASYNC_CONN (Google Services): 19 m 53 s (1193 s) Count:22 3.8%
Tasker.UserAbsentWakelock (net.dinglisch.android.tasker.Tasker): 3 m 34 s (214 s) Count:712 0.7%
CustomWeather (com.palmarysoft.customweatherpro.Palmary Weather Pro): 1 m 35 s (95 s) Count:4 0.3%
AlarmManager (Android System): 1 m 7 s (67 s) Count:1988 0.2%

dmesg:

<6>[16329.551592] PM: suspend of devices complete after 130.135 msecs
<6>[16329.551916] PM: late suspend of devices complete after 0.306 msecs
<6>[16329.552000] PM: early resume of devices complete after 0.058 msecs
<6>[16330.015486] fsa9480 7-0025: dev1: 0x0, dev2: 0x0
<6>[16330.016050] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling
<6>[16330.016159] [ wm8994_samsung.c (wm8994_resume,3389) ] wm8994_resume..
<6>[16330.016171] [ wm8994_samsung.c (wm8994_resume,3391) ] ------WM8994 Revision = [3]-------
<6>[16330.016487] PM: resume of devices complete after 464.425 msecs
<4>[16330.020120] Restarting tasks ... done.
<6>[16330.027077] wakeup wake lock: mmc_delayed_work
<7>[16330.027405] Universal : Card status 1
<6>[16330.029158] [ wm8994_herring.c (wm8994_configure_clock,1146) ] USBOSC Enabled in Sleep Mode
<6>[16330.029168]
<6>[16330.029538] dai_active 0, IISMOD 00000000, IISCON 8050ce38
<6>[16330.029685] Inside s5p_i2s_resume..@559
<6>[16330.029954] suspend: exit suspend, ret = 0 (2011-10-29 07:11:31.513873957 UTC)
<7>[16330.030291] save exit: isCheckpointed 0
<7>[16330.030876] save exit: isCheckpointed 0
<6>[16330.031089] PM: Syncing filesystems ...
<7>[16330.031332] save exit: isCheckpointed 0
<7>[16330.031911] save exit: isCheckpointed 0
<4>[16330.032106] done.
<4>[16330.032298] Freezing user space processes ... (elapsed 0.01 seconds) done.
<4>[16330.049071] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
<4>[16330.064777] Suspending console(s) (use no_console_suspend to debug)
<6>[16330.066396] [ wm8994_samsung.c (wm8994_suspend,3371) ] Codec State = [0x0], Stream State = [0x0]
<6>[16330.193234] [ wm8994_herring.c (wm8994_configure_clock,1149) ] USBOSC disable in Sleep Mode
<6>[16330.193244]
<6>[16330.193353] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling
<6>[16330.193376] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling
<6>[16330.193395] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling
<6>[16330.193416] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling
[BetterBatteryStats] crypticc:
Which ROM? Which kernel? Some devs have talked about and fixed a wifi wakelock I think in 3.0 sources
[BetterBatteryStats] Domoo:
I normally freeze BBS when I'm not using it. No point in leaving it on if my battery life is good.
[BetterBatteryStats] bso44:
Ever since the update, I'm not getting any stats and this error is coming up:

"Selected 'from' or 'to' reference could not be loaded. Please refresh."

I tried refreshing but still getting the same error.
[BetterBatteryStats] xpanmanx:
+1.

I'm also seeing, "Device is plugged in: no stats" and no graphs.

I've attached a logcat of a usb connect/disconnect/reconnect session in the hopes it will help to kill this problem dead.
[BetterBatteryStats] eushaun99:
"Device is plugged in: no stats" is because your device is charging, therefore BBS is not collecting any data.
[BetterBatteryStats] bso44:
FYI, I force closed Better Battery Stats and cleared data in the app manager and got my stats back.
[BetterBatteryStats] It_ler:
Looking good IMO.

Please provide an idle dump of about 4 hours next time to have more reliable results.

Some apps causing alarms on your phone:

Google quicksearchbox

Exchange

Facebook

You should disable/freeze those apps you don't need every day, greenify if possible or at least change settings to disable all auto-updates/refreshes.

Good luck !
[BetterBatteryStats] xpanmanx:
Haha, I wish it were that easy. No, sir, my E4GT has been unplugged for at least 15 minutes and BBS stubbornly says, "Device is plugged in: no stats".

I've cleaned the connector with compressed air, and I've plunged it out with a plug soaked in DeOxIt. The connector is clean. The cable is disconnected. The OS shows unplugged. But BBS insists it's plugged.
[BetterBatteryStats] eushaun99:
Did you try clearing the app's data?
[BetterBatteryStats] xpanmanx:
Thanks for the idea. Tried it, didn't work. :(
[BetterBatteryStats] Karpfenhai:
Could you disable rootfeatures in bbs and see whether it turns back to normal?
[BetterBatteryStats] chamonix:
BBS does not insist, it just gives the info back that it gets from the kernel. If you have a custom kernel and are sure that the connectivity is ok you should take this to the kernel dev.

Of course there is a workaround: stats while plugged can be enabled in the advanced prefs (at you own risk as not all stats are accurate while plugged / the kernel believes the phone is plugged)
[BetterBatteryStats] chamonix:
Have you updated to 1.13.4B2?

After a positive test that version is rolling out on gplay (as 1.13.4). I am on the train now and will upload tonight. The release will be the same code as 1.13.4B2
[BetterBatteryStats] chamonix:
If you read the source code you will notice that that advise can not help
[BetterBatteryStats] gjw00:
help with battery stats log

Hello

I am trying to determine what is causing serious overnight drain on my htc one xl

No major stuff being synched.

Flashed the AOKP jb build 6 ROM, and since then I am seeing 40-50% drain overnight.

I have the battery stats log attached.

Gps, Bluetooth etc is off
[BetterBatteryStats] Karpfenhai:
Pn544 points to near field communication, turn that off and provide a clean idle dump as stated in the op, turn on alarms within your dump next time.

Tapatalked from my Galaxy SII
[BetterBatteryStats] brunek:
I didnt touch my phone over night so I hope the results will be fine..:laugh:
[BetterBatteryStats] miten_sheth:
Anyone?
[BetterBatteryStats] Karpfenhai:
Your main Problem is Wlan, why the MMC cards appear no clue, maybe mediascanner after unplugging USB ?

Repeat the test with wifi disabled and ensure mediascanner is stopped, should be way better then, search the thread for advice how to tune Wifi.
[BetterBatteryStats] xpanmanx:
No joy.

---------- Post added at 06:15 AM ---------- Previous post was at 06:10 AM ----------

Yes, with plugged stats enabled, I have data.

I'll take this to the kernel devs, but I believe we're still waiting for the OEM source to drop. Until then there are limits as to how much they can do.

I'm curious: Anyone else in here running GB27 on their E4GT?