yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] zevzek:
I had a similar issue and it seemed to show the data only after clearing data or a reboot. But that stopped since I excluded it from power saving in system settings, so I don't consider it a bug, but my fault for blocking it.
[BetterBatteryStats] sirxdroid:
I tried that, no difference. In any case, the app shouldn't just sit there and just keep spinning, or showing all 100% values or values that make no sense such as 1800% -- obviously computed from invalid data, but the app itself should have the proper math checks in place.

Issues/bugs are OK, we can handle that. The problem to me is the developer is silent, doesn't respond to emails or address the issues here in the thread, perhaps offering suggestions for things to try or asking for more logs, etc.
[BetterBatteryStats] gaich:
Looking throuhg first posts you can find detailed description of what bug report should be, what should it include etc. Of course developer wouldn't answer without essential data provided.
[BetterBatteryStats] TNSMANI:
Please read the last 10 pages or so of this thread where the dev has answered almost everyone. Agreed, he is not that much active on this thread as we would like, but he is also human with a life. And this app is so old (in the positive sense), I doubt any other dev keeping up for so long a period. Give the man some time.
[BetterBatteryStats] amirhosseinakb:
when the phone had calibrated and had turned off overnight for 7 hours, in the morning after turning On the phone, battery remained in 100%. no draining observed.

here you can see another experiment for more than 9 hours overnight with flight mode ,wifi off , location off, no movement and also the second screen off.

battery level was 80% that dropped to 49% (31% draining in full sleeping condition).i'm confused.

help me find why the battery is draining without any usage , please .
[BetterBatteryStats] TNSMANI:
I am in the same boat as you are. Unable to comprehend the behaviour of the battery.

You need advice from higher levels.

[MENTION=5488402]Davey126[/MENTION]
[BetterBatteryStats] DB126:
First and foremost there are no "levels" - just different perspectives. Over time no one on this board has assisted more members with their battery management woes than [MENTION=5656100]tnsmani[/MENTION]. Others come and go (self included). Tip-of-the-hat to tnamani and all those who consistently volunteer their time and talents to help others w/o personal gain.

As for the issue at hand BBS (as configured) does not expose sufficient information to identify the culprit(s). It's not Android; trivial screen-off 'wake' time and CPU activity suggests the problem lies deeper. Me thinks you have a hardware/kernel problem driving the parasitic drain. Could be a faulty sensor or kernel interface to the numerous 'always on' components. While I loath to recommend reloading/replacing the kernel on an unrooted (presumably bootloader locked) device that may be the only way to drill down to root cause. If the device is still under warranty I would seriously consider making a claim before taking other actions that may be beyond our comfort/experience level. Also monitor your device forums for reports of similar issues.

Sorry for the non-solution. Good luck with whatever path you choose to pursue.
[BetterBatteryStats] TNSMANI:
[MENTION=7662695]amirhosseinakb[/MENTION]

This portion of the above post from Davey126 relates to you:

"As for the issue at hand BBS (as configured) does not expose sufficient information to identify the culprit(s). It's not Android; trivial screen-off 'wake' time and CPU activity suggests the problem lies deeper. Me thinks you have a hardware/kernel problem driving the parasitic drain. Could be a faulty sensor or kernel interface to the numerous 'always on' components. While I loath to recommend reloading/replacing the kernel on an unrooted (presumably bootloader locked) device that may be the only way to drill down to root cause. If the device is still under warranty I would seriously consider making a claim before taking other actions that may be beyond our confirmation/experience level. Also monitor your device forums for reports of similar issues.

Sorry for the non-solution. Good luck with whatever path you choose to pursue."
[BetterBatteryStats] chamonix:
The first log says it all: the BATTERY_STATS permissions are not granted.
[BetterBatteryStats] chamonix:
Sorry you feel that way. Why not registering to the beta programme on gplay and help me getting the next release out of the door?
[BetterBatteryStats] chamonix:
New build is on its way, fixing save Dump/dmesg/logcat issue. Please test and report specifically on that issue.
[BetterBatteryStats] One Twelve:
Can i get an update on this issue ?

---------- Post added at 06:48 PM ---------- Previous post was at 06:45 PM ----------

Should mention i don't see any more extra alarms info with the beta mentioned above as compared to 2.2.2.0

Just alarms are listed, there is no breakdown for each alarm like on rooted devices
[BetterBatteryStats] chamonix:
Please follow the instructions in the first post on how to report bugs. With such a short description I can not really help you.
[BetterBatteryStats] DB126:
Yeah - I should have noted that for the specific member report being quoted. My response was more generic acknowledging issues exist and are being addressed as time and resources (yours) allow. Whether those issues are largely device/procedural oriented or reflect systemic problem(s) is for others to determine. Me thinks it is a mixture of both.
[BetterBatteryStats] chamonix:
It's bug bash week-end: new release is up, fixing the frozen package info dialog. Bring your logcats on :D
[BetterBatteryStats] stylemessiah:
Just installed latest private build, on AOKP 7.1.2, no change here, still not working.

No data on app run, auto/manual refresh takes forever, and ends up with no data
[BetterBatteryStats] chamonix:
As you may have noted non of the changelogs refer to that issue. Please provide a logcat / dumpfile and re-state the issue to avoid that I have to search for context. Ideally do the refresh, and save the dumpfile/logcat straight after so that I can look at the end of the log.

You mention no data is shown: does this apply to all stats? if yes, does it also apply to raw stats?

PS: make sure to test with 2.3-227 if you have a rooted device
[BetterBatteryStats] chamonix:
Potentially there are also issues specific to root / root-tools. I have stopped rooting phones with the pixel xl and have the feeling that I should get myself a rooted phone again, or remove dependencies to root completely (I have created issue #821 for that but it won't make it to 2.3 so I guess I will have to root). What root-method is used these days?
[BetterBatteryStats] solar666:
I would go for magisk root
[BetterBatteryStats] DB126:
Agreed. SuperSU (2.82 SR5) is easier to digest and arguably more stable but has zero official support with ChainFire on the sideline. Quickly becoming irrelevant...especially for newer devices and Android builds.
[BetterBatteryStats] chamonix:
Two new build out this morning, fixing more bugs. Please post detailed reports on any issues arising with 2.3-233
[BetterBatteryStats] stylemessiah:
I just downloaded the latest build 23-230 (92) in preparation to give you the answers you asked for and a new logcat....but the latest build seems to work.....

I'll update you if it fails, but at the moment it opens and loads data as quickly as it used to, and a refresh is quick and the data is good
[BetterBatteryStats] shaggyskunk:
Rooted device and 2.3-233 works without any issues - Stock Unrooted Samsung Galaxy S8+ and no data is displayed EXCEPT for raw stats then data is displayed.. Apologies for the brief reply - I just wanted to provide a snapshot of info as I'm on my way out... On the Unrooted device BBS seems to work when the phone was recently fully charged - But if I reboot the phone after a few hours then No stats are displayed with the exception of raw stats.

Sent from my SM-G955W ??
[BetterBatteryStats] chamonix:
I have read the one or the other conversation about not having a reference stored at boot time. If this happens to you could you please give me the output of these two commands?:

grep OnBootHandler <your logcat-file or "adb logcat" goes here>

and

grep WriteBootRefService <your logcat-file or "adb logcat" goes here>
[BetterBatteryStats] adm1jtg:
+1 first build that seems to work for me as well

Shamu running 8.1
[BetterBatteryStats] mrjuniork:
[MENTION=1330150]chamonix[/MENTION]

Tested the latest hockey build and the app loads all statistics fine but the moment I press settings the app crashes. Cleared cache, force closed and restarted it, no change.

OOS 5.0.2 stock, Magisk 15.3, Oreo 8.0
[BetterBatteryStats] gaich:
[MENTION=1330150]chamonix[/MENTION]

233 crushes when you try to enter the settings. Maybe it has been captured by logcat:

View attachment logcat-2018-02-18_182602105.txt

Updated, just saw [MENTION=6912702]mshinni80[/MENTION] experienced the same problem.
[BetterBatteryStats] chamonix:
Fix is building and getting uploaded right after. Thanks for your support, this build will got to gplay beta right after and it looks like a release candiate if nothing goes wrong in the two next days.
[BetterBatteryStats] Bonoboo:
Thanks for new 2.3-239

Finally info refreshing fast.

And now BBS again appeared in Tasker's plugins list.

But if try to add it toast message says: "Plugin error: missing, disabled, not exported or no permission receiver, or too many receivers"

Android 7.1.2 (LOS 14.1), latest Tasker 5.1. Logcat attached (few tries).
[BetterBatteryStats] :
2.3-239? Typo? 2.3-236 is latest release, isn't it?
[BetterBatteryStats] Bonoboo:
Not typo, updated today via Beta GPlay channel.
[BetterBatteryStats] RASTAVIPER:
Any news about providing the beta versions through another channel?

Why should we need to download another app for doing this?

In the past all versions were posted at this threads, ready for downloading.
[BetterBatteryStats] chamonix:
The gplay version number is different from the one on hockey-app due to some internals of the CI/CD incrementing the number for each step but it is the same build. I have to fix that to avoid irritations
[BetterBatteryStats] chamonix:
No need to download another app. The decision to use hockey-app is to have CI/CD support and a central view on figures/feedback. Releases will still be published for download on xda but I feel registering to hockey-app is a small price to pay and it is the only way I know of with full automation. If you know of a way to automatically publish to xda while having access to stats please feel free to hint me at it so that I can add a task to circleci.
[BetterBatteryStats] Gen5:
I get a wakelock from something called netlink? What is netlink and how can i stop it from waking my device?
[BetterBatteryStats] Lughnasadh:
I'm not exactly sure what netlink is but I believe it is connected to wifi somehow. The only way I have figured out how to stop it is by using a custom kernel that can block kernel wakelocks, such as Elex, Franco, Shadow...
[BetterBatteryStats] yochananmarqos:
What stats server is used? Is it through HockeyApp? I just want to make sure AdGuard isn't blocking the requests.
[BetterBatteryStats] Gen5:
Im currently using elementalx. Do you know i can block this wakelock?
[BetterBatteryStats] Lughnasadh:
Yes. Using the EX Kernel Manager, just go into Settings>Miscellaneous>Block Wakelocks
[BetterBatteryStats] chamonix:
Yes, it's all hockeyapp
[BetterBatteryStats] RASTAVIPER:
Well, I can propose this hosting site that many other xda devs are using. I think it's called androidfilehost.

No registration or emails are required for downloading.
[BetterBatteryStats] chamonix:
Again, it's not about hosting, it's about integration in the continuous delivery pipeline as well as stats providing the feedback loop. Those parameters are important to me:

- full automation from commit to release allows me to focus on dev and forget about the workflow

- stats help me understand how adoption goes and how representative a test went

Of course the solution also needs to protect my asset as the xda edition is free only for xda users.
[BetterBatteryStats] chamonix:
Please keep in mind that suppressing wakelocks is just a band-aid that may cause more harm then good. Let's take an example to illustrate: if you use the screen on/off references with BBS a reference will be saved when the screen goes off. In order to make sure that the work of saving the reference can be completed before the phone goes to sleep a wakelock is requested at the beginning of the save-routine and release at the end.

Now guess what happens if you prevent bbs to hold the wakelock?

The app will fail doing its job....

This example is trivial but now consider what would happen if bbs detected that the save was done properly, and kept waking the phone up, again and again, trying to save the reference and never managing to do so. That would have a destructive effect on battery life.
[BetterBatteryStats] Lughnasadh:
Thanks for this response. I wholeheartedly agree with everything you said. After taking BBS dumps every night for almost 2 months straight (yeah, a little OCD here :D) changing different variables each time (i.e. blocking/unblocking various services, receivers, wakelocks, kernel wakelocks, crystallizing (hibernating) apps, etc.), I have come to heed the conclusion that you and [MENTION=5488402]Davey126[/MENTION] are always promoting, less is usually best :good:.

For me personally, I crystallize (using 3C Toolbox) a handful of apps that I don't need running in the background (e.g. G+ and Gmail) and block 1 or 2 kernel wakelocks (1 of these being NETLINK). And although my average wake/screen off time is usually between 10-11%, my idle drain averages around .5-.6% (leading me to the conclusion that even though I have a relatively high wake/screen off time, whatever processes are causing this are in actuality not using up that much battery).

As for my response to blocking kernel wakelocks to [MENTION=6735287]Gen5[/MENTION], I was just letting him/her know how to block that specific kernel wakelock (NETLINK) since I have had trouble with it using up battery in the past as well. But your words hold true, going around haphazardly blocking this and that can in the end be more destructive than good. :good:

And as always, I appreciate all the experts here providing very insightful information that has allowed us to curtail sometimes destructive behavior coming from our devices/apps while at the same time not limiting the functions that they provide us. :cool:
[BetterBatteryStats] chamonix:
Could you please guide me through what you have set-up the plugin to achieve and how I can reproduce the problem. And please assume I am a task noob because that is what I am :)
[BetterBatteryStats] Gen5:
Can ex kernel manager be used for any custom rom or only for elementalx? What other alternatives are there?
[BetterBatteryStats] Lughnasadh:
Yes, it can be used on other custom kernels. Kernel Adiutor is another option. The options you get will depend on the kernel itself.
[BetterBatteryStats] Bonoboo:
Steps to reproduce: Tasker (trial APK) > tab Tasks > "plus" button in right corner > any name > "plus" button > Plugin > BBS > error toast

Expected behavior: opens action edit screen where by tapping "Edit" button shows activity from BBS with desired actions (custom reference, dumpfile).

Also here some info for creating plugins, maybe something changed.

UPD 1: Nevermind this "bug". I'm very sorry, seems problem was on my side, now all works fine.

I enabled unused services and receivers for widgets (yes, OCD), but they seems unrelated for Tasker.

UPD 2: now plugin setting available, but they won't save in Tasker.

How to test: select some action for BBS, press Back, edit again - settings reverted to default.
[BetterBatteryStats] chamonix:
OK, up to that point I have a fix but there is still an issue with the broadcast receiver not firing so nothing happens. I will give it another try tonight and push the state to hockey-app. Would you mind switching to the xda version for a while so that you can test and validate before I push to gplay?
[BetterBatteryStats] GoJo ^^:
My P9000, runinng Eragon MM rom, won't show NOTHING. Just no stats at all. I checked/changed all possible options. I don't understand why.. Never had such thing happen on any other devices. Any idea?
[BetterBatteryStats] Spinvis:
Just letting you know that the latest test builds have solved all my issues and better battery stats is running great again, thanks so much for your dedicated effort!
[BetterBatteryStats] chamonix:
New build 2.3-240 is up on hockeyapp fixing the save-state as well as handler for Tasker integration. If you could please test the xda-build and report back I will then push the build to gplay beta.
[BetterBatteryStats] Bonoboo:
Tested: yes, now Tasker-related problems gone.

Huge thanks for attention to this minor bug!
[BetterBatteryStats] chamonix:
2.3 is rolling out on gplay and available in post #2 as well. Thanks for your patience, testing and feedback.

Now that I have all the automation and feedback loop in place my next challenge is to speed-up the cadence.

Edit: change version number and replaced the download from post #2 to ensure consisteny with the gplay release number
[BetterBatteryStats] deepakdavidster@gmail.com:
After a long time we got an update
[BetterBatteryStats] gordonpn:
Can I ask what's up with your entitled comment? Does the dev owe you updates?
[BetterBatteryStats] DB126:
lol - amazingly egoistical.
[BetterBatteryStats] deepakdavidster@gmail.com:
There are no guarantees from any developers, but it is good to see updates
[BetterBatteryStats] sirxdroid:
When you pay for an app to support the developer and not just leech off the free XDA version, is it unreasonable to expect timely updates in particular when older versions do not work at all with newer Android versions? I don't know, just asking what the expectations are ...
[BetterBatteryStats] DB126:
I view the paltry onetime contribution asked by most developers a token of appreciation for a specific build with no expectation for further updates or support - although both often *generously* occur for months (years!!) after. Expectations for a subscription model (recurring payments) are completely different.
[BetterBatteryStats] shaggyskunk:
Maybe something is getting lost in translation...?

But this comes across in a very unfortunate manner..

"After a long time we got an update"

?

Sent from my SM-G955W ??
[BetterBatteryStats] chamonix:
Just as a reminder: you can vote on our favorite bug/feature on github. I have put up an initial backlog for 2.4 here: https://github.com/asksven/BetterBatteryStats/milestone/53

If your favorite feature is missing for that release or if you have wishes for additional feature I have not logged yet please raise you voice and let's have a conversation!
[BetterBatteryStats] sirxdroid:
[MENTION=1330150]chamonix[/MENTION] -- is there any benefit to using root for BBS these days on latest Oreo? If no, any way to tell BBS to stop asking for root?
[BetterBatteryStats] Icey34:
Ok be back today really late or tomorrow with some helpful screenshots/dumps. Thanks! :) Will run it down in idle.

edit: I actually had one from this morning but.. sleepy and all.. I forgot to make a dump, so now I have to wait again.
[BetterBatteryStats] Bouncer5:
Can someone look at my dump file and tell me why my battery life is not great, It has improved the last 2 days for sure.

Pastebin for those experts not logged in.
[BetterBatteryStats] Icey34:
So I'm getting a new device due to my current one being replaced cause it can't get a 4g signal. When I get the new one and get it setup with the correct ROM/Kernel, will post back. Should be in a few days. Don't forget me! Lol. Getting mines tuesday.
[BetterBatteryStats] scorpeeon:
Hi!

Recently had some wake lock problems, can anyone take a look at this?

Link

Thanks!
[BetterBatteryStats] chamonix:
Backup has been keeping you device awake. I suggest using an offline backup like titanium and get rid of the cloud backup by disabling it. The problem with cloud backup is obvious: there are no settings and under bad conditions or if the server misbehaved stuff like that happen
[BetterBatteryStats] chamonix:
Unfortunately the kernel wakelocks are missing from this stat but here are some infos:

Since 9 h 42 m 29 s
Awake (): 6 h 27 m 39 s (23259 s) Ratio: 66.6%
Screen On (): 2 h 40 m 21 s (9621 s) Ratio: 27.5%
=========
Wakelocks
=========
RILJ (Phone): 3 h 27 m 3 s (12423 s) Count:864 35.5%
realtimechar (com.google.android.apps.plus.Google+): 37 m 32 s (2252 s) Count:49 6.4%
NetworkLocationLocator (com.google.android.apps.maps.Maps): 27 m 48 s (1668 s) Count:591 4.8%

As you can see your phone was awake without you using it 4 hours out of 9, that's really high.

3,5 hours are attributed to RILJ, that's the userland interface to the radio module so suggest you check in the SGS2 forums and try another radio if this wasn't a one time effect
[BetterBatteryStats] chamonix:
There was no data for kernel wakelocks and alarms because the reference had not been saved, probably because you updated bbs after charging the phone.
[BetterBatteryStats] chamonix:
What I meant is you provided a dump "since charged" but there was no data "since charged" for kernel wakelocks and alarms. This is why I suggested switching to "since unplugged", plugging/unplugging our phone and leave it alone for a couple of hours before saving a dump
[BetterBatteryStats] chamonix:
The problem is gtalk is not only used for messaging but also for internal stuff related to the market. This is why you can't prevent your phone to connect to google's servers as long as you have gapps on it.

On the other hand you should not obcess about those wakeups. Ideally you will not get much below one alarms every 30 minutes as long as you have data connection on because that's the average keep-alive time for most xmpp alive tools (the client must ping the server every 30 minutes to avoid session timeout). Of course those alarms are annoying but the cost is limited as long as they don't sum and wake up your phone all the time. That's why it is impostant to put alarms/wakelocks into perspective.
[BetterBatteryStats] chamonix:
Gtalk aside I see two things from this dump:

- a kernel wakelock that I associate with incoming traffic is higher than the sum of the wakelocks cause by userland. As you have wifi on I believe that that kernel wakelock is related to your phone being woken up because of traffic. Caould you turn wifi off or set its sleep policy to "off when screen off"?

- you have a pretty high *sync* count on "feeds". Are you using google reader? if yes, you may want to revisit your settings of that account to reduce the sync overhead

What ROM / Kernel are you using on your Nexus S?
[BetterBatteryStats] glennkaonang:
I'm using Peter Alfonso's latest nightly, the 16th February build with Air kernel, the deep idle test version.

Conservative 200/1000, cfq.

i9023, radio KB3, someone in the forum told me to flash this one instead of using the default KI1.

Nope, I don't have Google Reader installed.

That's weird, I only have gmail synced. I occasionally sync contacts when I add new or edit one.

I added new SS and dump file with wifi off.
[BetterBatteryStats] scorpeeon:
So should i just untick settings/backup & reset/back up my data? It says it would "stop backing up WiFi passwords, bookmarks, other settings, app data, plus erase all copies on Google servers" which doesn't sounds so good... I mean WiFi pws and bookmarks are not so important but others sound useful and it would also erase them from server...

Isn't there anything else i could do? Updating Gapps maybe?
[BetterBatteryStats] chamonix:
If you want to stick to using google's could backup then there's nothing you could do. Personally I don't and prefer to rely on the nandroid / titanium backups I do myself.

Before making a decision you could still wait and see if it was a one time effect due to poor network coverage or maintenance from google on the servers.

I can just show you what is going on on your phone and tell you what is "expensive". It's up to you to decide what is the best for you