yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] Formhault:
Hello guys!

Hope you can provide some insight as to what ghost has been draining my battery overnight!

I did v7's tutorial for Amplify and Greenify (didn't try the PowerNap and AppOpsXposed things) some days ago. The ROM I have (Pure Nexus - Nexus 6) has been clean flashed less than 5 days ago.

So late last night I've been watching YouTube. For about an hour or so... Drained the battery from 100% to like 80% I guess. Here are a few screenshots of the Battery Stats reported by Android.

Aaaand here's a BBS log dump I took a few minutes ago. When I woke up the battery was at 25%. Now, it's at 20% already, and I haven't been doing much :eek:

Please, could you guys take a look and help me out? Thanks in advance!
[BetterBatteryStats] v7:
NETLINK (): 4 h 15 m 11 s Cnt:(c/wc/ec)237948/222319/0 30.5%

Seems like WiFi connection is causing the trouble.

Check your router.There are plenty of Kernel wakelocks.

__

v7

XDA Assist
[BetterBatteryStats] Formhault:
Thanks for chiming in!

What do you mean check my router? How? :eek:

I had channel set to 13 (2.4 GHz) up until a week ago when I set it back to auto (my 4-years old Lenovo laptop has a gorgeous WLAN card that some times forgets what channel 13 looks like... makes me feel like setting the damn thing on fire!). Also, I set channel width to Auto (20/40), instead of 40. Could that be it?! It's been set like that for a week yet this is the first time I wake up to a battery that's been drained ~50% or more over night :eek:

I set channel back to 13 and width back to 40 MHz. Like they were before.

I do plan on getting an AC (5 GHz) router in the next 12 months or so. Until then, I'll use this Huawei HG8245H my ISP gave me for free... Is the router bad or what? Lol.
[BetterBatteryStats] v7:
Sometimes router issues can cause trouble.Check this thread.Maybe this'll help :)

__

v7

XDA Assist
[BetterBatteryStats] nasenbaer2:
Hi,

can't get my Lollipop tablet into deep sleep mode at all - mostly it even runs at full CPU clock :(

Besides the normal Google framework stuff nearly nothing else is installed since the tablet is just a few days old. I already disabled as many Google services as I could find: e.g. location, sync etc are all set to off.

Yet my tablet stays in awake mode nearly all the time: Awake (Screen Off) (): 4 h 30 s 97,9%.

As a culprit I see two wakelocks: rtw_wifi_resume and otg_wake_lock, as well as the Android-OS task with the highest CPU usage and battery drain.

The tablet has no phone or GPS, just WLAN.

I uploaded two logs where I let the tablet idle, e.g. I didn't use it (sorry I'm not allowed to post URLs yet - please copy them):

textuploader.com/5812r

textuploader.com/58120

Thanks for your help!
[BetterBatteryStats] Adrianrff:
I second this request. Anyone?
[BetterBatteryStats] nasenbaer2:
Well I found the issue: my tablet will not go to sleep if any USB cable is connected. It does not matter if any device is connected or not. In my case I left the cable for the charger connected (the charger itself was not connected). Is this the default Android behavior or did the manufacturer screw up with their USB drivers?
[BetterBatteryStats] pure.by:
Hi everyone, sorry for the noob question, but it's not addressed in the OP or within the last 5 forum pages, so I ask.

Currently I have a payed PlayStore version installed as system app. I see that the free XDA beta version has more features, Doze statistics in particular. How do I correctly install this update?

I've downloaded and installed it, but it did not update PlayStore app, instead it installed as a separate app (so I got 2 undistinguishable BBS icons next to each other). Neither did the free XDA version ask me to install itself as a system app, so I'm not sure whether the statistics it was trying to gather were right and/or complete. So it didn't feel right to uninstall the PlayStore version and I have uninstalled the XDA version instead just to make sure everything works the way it did and I don't have 2 apps running doing the same job.

Is the install as system app restriction removed from XDA beta? Or does it somehow cooperate with the PlayStore system version? Why isn't there just a PlayStore Beta program for BBS so I can receive the beta updates the usual way without having to monitor thread and manually download and install the APK every time?

I'm a bit confused, thanks in advance for all the info.
[BetterBatteryStats] githyanki:
It is polling to see if you connected something to the USB cable you plugged in. The phone thinks you did it for a reason. Afer all, who would leave a cable plugged in for no reason?
[BetterBatteryStats] nasenbaer2:
Well I assumed an USB device would send a "device connected event" when plugged in (as well as a heartbeat while connected) instead of the host using polling. I thought the cable would just be a dumb extension for the port: as long as no device is connected an elec. circuit is not closed aka no elec. flow. Guess I was wrong there.
[BetterBatteryStats] ianmacd:
The XDA version is the current beta. As you have noticed, it offers a few significant advantages over the production release, which is the one available from the Play Store.

Until the current beta becomes the new production version (which is quite close now), you should remove the Play Store version and reinstall the one here on XDA.

BBS no longer needs to be a system app to collect its statistics. Just ensure that you assign it the required permissions as detailed elsewhere in this thread.
[BetterBatteryStats] pure.by:
Thanks for your reply! Things are much clearer now.

I have read a recent post by BBS creator that RC1 of the updated version can be expected within a week. Do you have any idea based on your previous experience how long it lasts lasts between RC1 and final version (in case everything works as expected)?

I think I'll just wait for the PlayStore version to get updated, no wish going through troubles of uninstalling a system app. Btw, great to hear it doesn't need to be a system app anymore, good for future ROM flashes.
[BetterBatteryStats] ianmacd:
No, I'm not sure how long it will be until 2.2.0 final, but if I were you, I wouldn't wait for it. There's nothing to lose by installing the XDA version of the app now. Then, when the Play Store version is updated, you can simply remove the XDA app and install the one from the Play Store.

Otherwise, the same situation is likely to repeat itself in the future. Some time after the new release on the Play Store, a new beta will appear on XDA and you'll be running old code again.

All in all, it's probably better to run the XDA version exclusively, since that one is always up to date.

I'm not sure why the developer has chosen this model, because it effectively discourages purchases of the app and obfuscates the fact that there are more up-to-date versions of the app available, but ours is not to reason why.
[BetterBatteryStats] 1Raiders:
Aside from your amazing app buddy... I think it's a great thing that you communicate your concerns AND it's very therapeutic for you??. Especially since you do this on your own time for free.

I really appreciate what you do and all other dev/themers and other users input in XDA?

Now back to the app.. I persoally don't use any graphs or xtra stuff like that.. Others may but thats just my 2 centsbud.

Thanks again! ?

E's MDK JDC S4
[BetterBatteryStats] Deni_NS:
Well first of all you are human. You have feelings and everything that is making us humans. We are humans too. So if you always need time... Take time. First family, regular job, then everything. We know (well I speak for whole xda members, but I know they surely share this) that you are trying your best and always you do your best. You bought me with " Do I feel bad when my users - paid or not - are unhappy? hell yea! " You are great man and you did BBS to be one of the most accurate apps for reading battery "problems".

Thanks again [MENTION=1330150]chamonix[/MENTION] and God bless you.
[BetterBatteryStats] v7:
[MENTION=1330150]chamonix[/MENTION] Great work bud :)

Thanks a lot for the update ^_^

__

v7

XDA Assist
[BetterBatteryStats] Adrianrff:
Hi. I'm getting very high readings for sensor usage (over 80%) in BBS.. I thought it might be Velis autobrightness, but I've since uninstalled it and still the same values. I have set Tasker to not monitor any of the sensors and deactivate any task that use them, still see the same. What I find really strange is that Gsam battery app doesn't report the same values, no were remotely close. I can't think of any other app that could be doing this. Is there's a way to find out what has been using sensors on my device? Idle drain is fine on my phone, but it almost never enters Doze and I suspect that's the reason why.
[BetterBatteryStats] githyanki:
So you have OK Google enabled? I had something similar with sensors and audio in keeping phone on. Disabled and all his now.

Also turn off tap to wake.
[BetterBatteryStats] Adrianrff:
No. It's enabled only inside the Google app. My phone sleeps just fine, that's not an issue for me, fortunately. I'm just puzzled by those sensor readings and by the fact that other monitoring apps don't register it. Only BBS.
[BetterBatteryStats] murti52:
Hi everyone, i know that kernel wakelocks are from kernel and it differs from kernel to kernel and device to device... I am using note 2 N7105 and agni kernel with it. The developer of the kernel is not actively online, so i won't be getting an answer there. So i hope i would get a general solution if any one has., As to how to remove the first 5 wakelock in the screenshot.. i am really annoyed with it.. is a log required?
[BetterBatteryStats] Portgas D. Ace:
Check this thread for a possible solution.
[BetterBatteryStats] chamonix:
Please post a dumpfile so that we can see the whole picture. Battery-monitor may be related to wake-ups and would be a symptom not worth chasing in that case.
[BetterBatteryStats] Sam Nakamura:
Mdm_hsic_pm0 is modem related, I god rid of it by changing the baseband

or at least it's less aggressive.
[BetterBatteryStats] Trak-X:
Congrats on your thoughts and new release.

For my apps i use ACRA with Acralyzer as backend. You just need to add it in the app and create your own server where logs are being received. Any crash will be catched and sent to the server without user interaction. Very usefull stuff.

Some more details :

http://www.acra.ch/

https://github.com/ACRA/acra

https://github.com/ACRA/acralyzer/wiki
[BetterBatteryStats] Mjduddin:
Try Fabric https://get.fabric.io it's also built into KA-Mod
[BetterBatteryStats] Perseus:
I know I can't help you with App Development. But I know whatever route you choose will be for the better! What you have described going forward, makes a lot of sense. Do please be kind and note that, paid users have come here noticed the beta updates and asked, when will this update make it to Play Store. So it might help if you make it abundantly clear on the Play Store that going forward only stable RCs will make it to Play Store. Just so they don't whine.
[BetterBatteryStats] sapphirecoupe:
Can this be installed directly over the paid playstore installation of BBS?
[BetterBatteryStats] mondohow:
No. See post #30837 two pages back.
[BetterBatteryStats] dreinulldrei:
Hi [MENTION=1330150]chamonix[/MENTION], hi community users,

I've been using this tool for a long time, and it's always been very helpful. Still, there's a case I haven't been able to solve. The device in question is a G800H by Samsung, also known as the dual sim variant of the S5 mini. It's been shipped with 4.4.2 last summer, and since then (November 2015) I've tried upgrading to 5.1.1 numerous times. Every time I upgrade I run into a major obstacle: after some hours, mostly over night when charging, the device no more goes into deep sleep. The lowest I can get is 300 MHz. So it's always on and drains the battery. I've really checked everything I can come up with. I installed different ROMs, I used the device rooted and unrooted, without Xposed. I've only installed a bare set of apps etc. - still it won't sleep properly.

I've attached a log and would be grateful if anyone is able to find a clue. I have no ideas left. Funny sidenote: Even rebooting won't solve the problem. The only thing that solves the issue is booting into TWRP, erasing "cache" (there's nothing in these directories except for a bare structure, e.g. lost+found - but no files). It then works for a day before, over night, it again stops sleeping.

Feedback highly appreciated. Thank you in advance.
[BetterBatteryStats] chamonix:
The dumpfile does not show anything keeping your phone awake. Could you please repeat the exercise and provide a dumpfile togather with a logcat and dmesg so that we can get a bigger picture. Those two additional logs may show abnormal activity (logcat) or even hint at what prevent the power management to go through the stages leading to deep-sleep.
[BetterBatteryStats] dreinulldrei:
Log sent; as long as I don't know if there's private data present in these logs (e.g. IMEI), I am not posting it in public. But any feedback you have, please feel free to share here and I will post the portions of the logs here, or the full log after I've sanitised it. Thanks!
[BetterBatteryStats] Perseus:
Typically we look for the Text Dump as you had posted earlier, except over a period of Idle Time of at least 3 to 5 hours. Only here in this case with 2 Hrs and Change, its not really sufficient.

You have a Chatty Device on your network. Perhaps a Wireless Printer. Can you please assign a static IP to this phone from your Router ? Or turn the printer off ? Just for a period f Testing ?

Do please go to Advanced Wireless settings and set "Keep WiFi On During Sleep" to "Only when Charging". Turn off GPS completely and reboot before leaving the phone alone for a period, preferably overnight.

Just for your information, Logcats DO NOT include IMEI information.
[BetterBatteryStats] Ckovvi:
Is it really better for battery to select Keep Wifi On During Sleep to Never instead of Always?
[BetterBatteryStats] Perseus:
Keeping the WiFi On is more than merely keeping the antenna powered. Its about constantly negotiating with the Router, Roaming Scan, Look for other open Networks and keep DHCP Lease. All this takes a toll. Now if you are wanting or expecting some important email or update then yeah you should do all of above and keep Wifi on. If that's not the case, then there's no point.

Just for Kicks and Giggles, you can do 2 Hour experiment with Set to always vs Never. See what is the Drop in Battery.
[BetterBatteryStats] mitchdickson:
What if you live in a low cell signal area? Would it be better to leave wifi as always on?
[BetterBatteryStats] Perseus:
Most Definitely. Otherwise the RILJ Wakelocks will chew your Battery to pieces. However, if you turned off Data Completely and Keep WiFi to "Only when connected", Battery will be saved, but the downside would be, if there's a important email or message or notification you're expecting, those won't come unless you unlock screen, which turns WiFi back on.
[BetterBatteryStats] murti52:
Dump file attached sir. Please let me know if you need anything else. :)
[BetterBatteryStats] dreinulldrei:
Thanks, I am having it sitting here and will do another battery dump. I must just strongly assume that we won't be getting any new insights there. Still, it'll be ready in a couple of hours.

As for the IMEI thing... It just was late at night and I rushed a full log with SysLog app which by default includes all logs, also modem, because I also expect some strange thing like the WiFi issue you mentioned.

I am going to create a fresh log later on as well.

I can turn off WiFi at night. What puzzles me is that if it's the WiFi, turning it off or rebooting should make my issue go away. But - so far - the only way to make it behave correctly is to empty (the already empty) cache folders via TWRP. Also, when downgrading to 4.4.2 the issue is gone - although it's still in the very same LAN.

Thanks for your thoughts and feedback which is highly appreciated.

---------- Post added at 08:46 AM ---------- Previous post was at 08:43 AM ----------

Oh, I also do have a guest WiFi... Could remove the phone from the general one and isolate it from local devices. Or turn off WiFi completely.
[BetterBatteryStats] chamonix:
I see a bunch of weird things in your dumpfile:

*launch* (com.teslacoilsw.notifier.TeslaUnread): 34 m 16 s Count:0 7.1%
*launch* (at.jclehner.appopsxposed.AppOpsXposed): 34 m 16 s Count:0 7.1%
*launch* (com.asksven.betterbatterystats_xdaedition.BetterBatteryStats): 34 m 16 s Count:0 7.1%
*alarm* (CyanogenMod System): 34 m 16 s Count:28 7.1%
*launch* (CyanogenMod System): 34 m 16 s Count:20 7.1%
*launch* (UID): 34 m 16 s Count:0 7.1%
*launch* (com.google.android.packageinstaller.Package installer): 34 m 16 s Count:0 7.1%
*launch* (com.android.deskclock.Clock): 34 m 16 s Count:0 7.1%
*launch* (com.alensw.PicFolder.QuickPic): 34 m 16 s Count:0 7.1%
*launch* (com.microsoft.rdc.android.Microsoft Remote Desktop): 34 m 16 s Count:0 7.1%
*launch* (com.vito.lux.Lux): 34 m 16 s Count:0 7.1%
*launch* (com.oasisfeng.greenify.Greenify): 34 m 16 s Count:0 7.1%
*launch* (com.ceco.marshmallow.gravitybox.GravityBox [MM]): 34 m 16 s Count:0 7.1%

If this is not a glitch there is something seriously borked with your phone. Out of curiosity: did you do anything special before saving the custom reference? Did your phone soft-boot?

Now to the wakeups:

imoblife.toolbox.full

is waking up your phone every 10 minutes. It up to you to decide if it's worth it or not.

And finally to

"battery-monitor" (): 1 h 20 m 28 s Cnt:(c/wc/ec)4866/0/4866 16.7%

As I said in my previous post this wakelock is a symptom not a cause: this wakelock is held shortly at each wake-up to re-calculate the battery level. The cause is the wakeup it self.

You have three causes of wakeups driving this:

- com.google.android.gms

- imoblife.toolbox.full

- wifi broadcasts/multicasts

Looking that the number of of wake-count caused by wlan:

"wlan_rx_wake" (): 59 m 53 s Cnt:(c/wc/ec)6799/0/6799 12.4%
"wlan_wd_wake" (): 29 m 4 s Cnt:(c/wc/ec)8845/0/0 6.0%
"wlan_wake" (): 20 m 44 s Cnt:(c/wc/ec)13188/4400/0 4.3%

I would say your best shot is in not leaving wifi on all the time, or to inspect your local network (assuming you took this reading in an environment that you can impact) and get rid of any upnp traffic (multicast).

To verify this theory you could simply turn off your wifi (including wifi sniffing when phone is off in the advanced wifi settings) and take a new reading to confirm.
[BetterBatteryStats] v7:
*alarm* and *launch* wakelocks appears on almost all 5.0+ ROMs.They don't drain.It's a glitch :)

__

v7

XDA Assist
[BetterBatteryStats] chamonix:
I have checked the logs (logcat and dmesg) but I am not sure if the reading is conclusive as:

- you did not post a dumpfile for the timespan

- logcat only covers about 15 minutes of activity

Nevertheless I saw I few things that may be worth inspecting:

- dmesg contains some hints at suspend not being performed:

Wakeup IRQ 326 sw_cc_thr pending, suspend aborted

- logcat shows powerstate errors:

E/libsuspend( 935): Error writing to /sys/power/state: Device or resource busy

- there is a ton of battery related activity in both files and I was wondering if you have any external battery connected:

sec-battery battery.82: sec_bat_battery_cable_check: Battery Connected

Edit: next time you provide a dumpfile please use the in-app option to save dmesg and logcat together with the dumpfile
[BetterBatteryStats] chamonix:
Let's call it a kernel bug then.... Interesting because I have never seen any of these between 5. and N (always running stock kernels)
[BetterBatteryStats] v7:
I don't have it on my stock Kernel now.But I have seen plenty of them on my thread and on my older device with custom ROMs.

__

v7

XDA Assist
[BetterBatteryStats] dreinulldrei:
Ok, here's a fresh set of logs, including dmesg and catlog. For some reasons BBS did not save dmesg at all (when sharing the result with e.g. AquaMail or TotalCommander the sharing app would complain about a file missing). I created it manually, hope it's what you need.
[BetterBatteryStats] ralfbergs:
I have massive doubts that this is possible. How should the phone detect an open-circuit, a passive cable? There's no switch in the socket (which also wouldn't make any sense...).

---------- Post added at 19:09 ---------- Previous post was at 19:05 ----------

Damaged micro-USB port so that phone "detects" some flapping signals on the port?
[BetterBatteryStats] nasenbaer2:
Same guess here: tho not about being damaged but just kinda dubious overall: the tablet (http://www.cube-tablet.com/cube-iwork10-flagship-type-c.html) has two USB ports. One normal 2.0 micro USB and one USB c-type. The manufacturer did the el cheapo version (made in China at its best) and implemented the c-type internally as a normal USB 2.0 connection. So I now got a c-type port that is just another 2.0 connection and has some funky behavior when a cable is plugged in. Guess saving less than 2 cents for them was worth it :eek:. Wouldn't be the only issues they cheated on: instead of DDR3L they used normal DDR3 ram and it seems that every tablet got a broken sd card reader too :laugh:

However since I'm using the table just as a glorified TV / Audio remote I'm fine now...
[BetterBatteryStats] Adrianrff:
Hi, [MENTION=1330150]chamonix[/MENTION]. Is there a bug in BBS regardings sensor time usage?

I've been seeing very high readings and trying to figure out what has been using my phone's sensors. Other apps (GSam, for example) don't register such high sensor times. Also, I noticed that if I use the 'boot' mark (2 days span) I get smaller reading than if I use the 'unplugged' mark (12 hours span), which doesn't make sense.

Thanks
[BetterBatteryStats] chamonix:
that looks indeed weird. Could you please post a logcat for each situations so that I can see the sensor data.

I can not comment on the figures given for sensors by other apps as there is no source code to look at for those. What I can say for BBS is that I do not leave our any sensor in the sensors display and filter on sensor #-10000 for GPA totals. This means that the sum of sensor time cumulates whatever sensor there is in the device, potentially leading to a sum bigger that the runtime for the case the sensors overlap in use (eg proximity + gps). This of course does not on explain the inconsistency you have found.
[BetterBatteryStats] Adrianrff:
Sorry, I have to ask you to be a little more specific. Do you mean using the debug option inside BBS or a logcat from another app? I'm only a little familiar with these things.
[BetterBatteryStats] swat4samp:
Can someone please have a look into my dump file? I don't see any type of wakelocks but still it drained nearly 8% overnight. Its been happening for quite a long time. Currently I'm on stock ROM with full wipe including storage but still observing drain :(
[BetterBatteryStats] chamonix:
in bbs when you use the share option you can select a logcat to be saved. That's the easiest way
[BetterBatteryStats] Adrianrff:
There you go. I noticed that last night in the 'since boot' stats the sensor reading didn't even show. Now they do. I thought you might want to know that. Let me know if there's anything I can do to help.
[BetterBatteryStats] TNSMANI:
I also had high sensor readings in BBS in addition to wifi being always on irrespective of the settings (never or only when plugged in). The inbuilt battery history also showed wifi as always on.

I tried wiping dalvik and cache in recovery, a couple of reboots, but nothing helped. Since these started after a dirty flash of ROM update, I clean flashed the ROM wiping everything but internal storage. Happy to report that now everything (sensors, wifi) is back to normal.