yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] DiamondJohn:
FYI @TNSMANI Thanks for your time. I will possibly post in the future, using your recommendations, when I sort the other stuff out.

I went to areophane mode, as on previous days, the drain was high with it off OR on; even at the edge of my WiFi range. Normally the device is near the router and has good reception. And, if in areophane mode its too high, I dont think it will go lower by turning on the modem and wifi. Baby steps.

As for the GPS, I have a custom Doze profile which I built a few years ago, and it basically timeouts very quickly on no location, while in doze (which you can see i'm well within, and 99%+ in deep-idle with very few maintenance periods) and also the accuracy accepted is very low res. ie. i would guess (if its all still working) that GPS in doze wont be a big issue.

As for the widget (org.satok.gweather), I use it mostly as a time-zone display (it has a 24hr clock & weather), to see the time in friends time-zones (if they are awake). I noticed the errant intent is labelled about updating ALL; not a single one. I had about 5. So I am going to *guess* if one was left to the default interval of 1 hr, all 5 would get the wake and update at once (I previously set them all to 3hrs, now they are all at 12h). What makes it more pertinent, I recently added a temp one (I had not removed) for a time-zone in china, as I bought something from AlliExpress, and needed to live correspond with the seller. I would hazard a guess I left it at 1hr (out of laziness). The other thing that made it difficult, I cant check or adjust the settings on any of the widget instances; one has to delete and re-create all instances. Ive deleted the temp china one, and set all (re-created) to 12hrs; so ill see how i go.

Remember how I asked about the "sh" thing? I looked a little deeper, and it was not one of my scripts. I just ran top and the following came up. Notice that its something to do with fingerprint init and running at 30%!!!. I quickly looked at the script, and it does have a loop; didnt fully check the exit conditions. I killed the process, and checked my fingerprint reader, and it has worked every time. So the script probably only needs to run on init. My quick look makes me think it sets up the default acceptable failures.

Also, I checked my logcat and found a constant barrage (I mean very very often) of selinux denials. I have been slowly adding allows (only for system processes, not 3rd party stuff), to reduce those.

Not that it really means anything, but I quickly checked my in-day drain history, and it dropped to 0.49% for two hours. It was probably a fluke/one-off, but I dont think I have ever seen that low since flashing this new ROM.
[BetterBatteryStats] DiamondJohn:
Pass II - This Time

I left WiFi & Mobile Network On. It was <3meters from the WiFI Router

I kill the Zombie boot script with a delayed boot script. ie give it a chance to do whatever it thinks it needs to do. I dont think this was an issue during deep-idle, as my aggressive doze basically suspends running scripts. But it would of been killing my SOT.

Changed the refresh settings of the widget (org.satok.gweather) to 6h. I think I may of had 1h on last run, and normally I set it to 3h, just because.

I have corrected/added in SELinux Allows for system components that were denied. Didn't do it for battery drain, just ensuring the system can do what the system needs to do.

Lowered my MIN CPU freq down to 300MHz from 576MHz. More to limit general battery use.

8h 41m logging

Last time there were the odd obvious things like "sh" and the widget refresh.

Thank-you in advance to anyone who can spare some time to look at it(y)
[BetterBatteryStats] TNSMANI:
@DiamondJohn

I don't know why this is still high even after reducing the update interval of the weather widget. Any other widgets?

Again Location (GPS) seems to be on somewhere and Alarms related to it are in the dump file.

As per BBS, your mobile signal was great, but still Alarms related to it are present. Is it by any chance patchy?

In any case, in general, it is the Alarms that are high.

Sensors:

I am not sure that they cause any significant drain, though on the face of it, the numbers are high.

May be the ROM. Plus how old is the battery?

Any others can throw any light on this?
[BetterBatteryStats] DiamondJohn:
Time fa bed, but.

1. regarding widgets...um ....I have ...errr... a "few".... But, I have basically had this same set up with a custom launcher since gingerbread, only adding a new row as the screens got bigger; but not for a few years. I had the exact same set up on (rooted) stock A11. Its a Pixel 4a 4G. I did make a change a few days ago where I made some SELinux allows specific to the widget (multiple instances of same widget, different settings/items). I may remove the allows, as it only visibly changed one item, and it was wrong (CPU Temp), but drain was bad before the allows, and hence Im here.

2. I explicitly had the GPS on, as I thought that was part of the whole airplane mode being off, therefore GPS on?

3. The ROM is the thing that has changed. From stock google Pixel 4a A11, to Bliss. A highly customizable ROM. Before, the battery stamina was pretty good.

4. Bought it 30 Dec 2021. The battery drain changed first day of new ROM.

I think I may need to bite the bullet and upgrade to A12, as that ROM is in dev, and I could get a little support. Its an official device, and I think the guy who maintains it on this device is pretty prominent. And hence I am post fixing things like SELinux denials.

If no one else chimes in, I may have to try some unusual/random steps to see the effects. For starters, see if GPS off makes a difference, If it does, it may also help SOT. I also plotted the battery drain over time of the log (after), and there was a period where it dropped down below 1% (I have a vague memory of 0.69% for an hour or two as opposed to generally 1.5%), I can also query that (if I kept the source data) over time to see what didnt happen then, that did happen later.
[BetterBatteryStats] the_naturat_com:
Hello. Is there any version that works on android 13 betav3 on S22 Ultra?
[BetterBatteryStats] afzalhanif:
Hi, I have a moto edge+ that I recently got my hands on. It is draining battery a little too fast. If I charge it to 100% before bed, it is usually in the 70% range in the morning. Throughout the day, it would keep falling while the phone is sitting idle on the table. Tried everything I knew. Reboot, factory reset, turning off 5G, no location services, no comms, no peek display, optimized battery, adaptive battery, no apps except the stock ones. The signal strength is good, full bars. I downloaded the BetterBatteryStats app and it says that phone doesn't go to deep sleep or just goes for minutes or seconds. This is usually the case however, what's strange is that couple of days, randomly, the phone DID execute deep sleep properly. For the first time, what I did was let the battery drain totally till the phone shut down. Plugged in the original Moto charger (18W flip) and let the phone charge overnight. The next day, it showed full battery and battery usage showed 80+ hours remaining. This is the charger that I have always used. Another time, the phone was draining battery quickly, as usual, and I had to connect it to the PC for some files transfer. The battery was at 68% (no deep sleep since morning). When I unplugged the device, it started to go to deep sleep (stats showed up in BetterBatteryStats). That 68% lasted me full day, drained only 2% battery overnight. Next day, I charge the phone and I face the same problem. After a full charge, the battery section never shows more than 15-20 hours remaining (except for those two instances).

I am not sure what input you would require from me. I am attaching a screenshot of the battery stats today, since I rebooted in the morning.
[BetterBatteryStats] TNSMANI:
This obviously looks like in-use stats. That is not going to help. We need an idle dump file for not less than 6 hours. Please read the first two or three posts of this thread on how to do it and attach the file.

Also please indicate the age of the battery.
[BetterBatteryStats] {s3rious}:
Can somebody take a look at my stats?

Oneplus 9 pro, android 13 - nameless rom
[BetterBatteryStats] afzalhanif:
Thanks a lot for taking the time to reply.

Here is the DUMP file from last night. Followed the instructions.

The battery is around 18 months old.

I would really appreciate if you could point out what is causing my battery drain.

In the kernel wakelocks, I see some wakelocks from usb. Is this indicating a faulty usb-c port or charging flex? Not sure but any input would be really helpful.
[BetterBatteryStats] TNSMANI:
You did not save the dump file immediately on unlocking. Screen was on for more than one and a half minutes. This will skew the stats.

Your mobile signal is not great and that is usually a huge drainer. Next time you take a dump file, locate the phone where the mobile signal is better.

Viber and the companion service held wakelocks. Disable them for the next dump file.

As far as I know, you can't control kernel wakelocks. You can only change the kernel/ROM. And you have too many kernel wakelocks.

The system was trying to shut down some apps (I don't know which) for more than 22 minutes.

You had a watch connected? Disconnect it for the next dump.

You also had some background upload/download happening from various apps. SNS_SMD sensor and the Proximity sensor were awake the whole time.

Try to change whatever is possible from the above and post a new dump file. This time please ensure that the screen on time is as low as possible, in seconds and not minutes.
[BetterBatteryStats] TNSMANI:
You switched off wifi and data? Both should have been on.

Regarding the USB and Qcom step charging, see THIS.

System was trying to stop some apps for more than 5 hours.

Location/scanning was on? Shut it down.

Please take another dump with wifi and data on and post it here.
[BetterBatteryStats] krkhaha:
Hi. Where I can find newer version. App centre have really old version.
[BetterBatteryStats] Wolfcity:
How do you know that the versions are "really old"?

Any problems with that builds?
[BetterBatteryStats] Lughnasadh:
The one in the App Center (3.0-485 (102)) is the latest that I know of. That's from July 31, 2022, so not really old.

​
[BetterBatteryStats] Ok_Kaleidoscope5109:
Is this an Android 13 thing or what? I'm allowed to swipe away the persistent notification? I used to use the persistent notificaiton to confirm my phone didn't kill off the app.
[BetterBatteryStats] Thebear j koss:
You can set level of importance. Long press notification, hit settings button, set importance.
[BetterBatteryStats] Ok_Kaleidoscope5109:
No such option exists. Isn't this an older Android like 8.0 or something option? I don't think it's been around for a few years now.

I'm curious why I can swipe away BBS but Tasker, my VPN have to have persistent notifications. The worst thing is once I swipe away BBS, I can't get it back. I can open BBS but I see no notification anymore. It's not until I reboot that I see a BBS notification back.
[BetterBatteryStats] Thebear j koss:
In app settings of better battery stats need to choose fallback option. See screen.
[BetterBatteryStats] Ok_Kaleidoscope5109:
Yes, I already have that set.

However I do not see how this has anything to do with whether a persistent notification shows up or not. This specific setting is referring to if a specific stat cannot be shown (e.g app loses track of when the phone was unplugged or custom Ref is lost because app is closed). This is simply a default comparison point for battery stats and nothing more.
[BetterBatteryStats] Thebear j koss:
If it is set to at boot, the notification appears at boot. If at any other option it shows when that event starts
[BetterBatteryStats] Thebear j koss:
Here's options from notifications upon BBS start at boot... Android 13 pixel 6 pro stock rooted.
[BetterBatteryStats] Ok_Kaleidoscope5109:
Thanks, yeah these are pretty much my settings except I have minimize checked. I personally don't want my silent notifications all expanded, especially the persistent ones, and a slim bar is enough for me.

Can you confirm if you can swipe away the BBS notification though? That's what I'm noticing--that I can swipe away this Silent notification whereas in the past I recall we weren't allowed to and had to explicitly uncheck Show Notifications to hide it.

My problem is once I swipe it away, I cannot bring back this Silent Notification unless I reboot. This is strange to me as Tasker, VPNs, Syncthing, apps that need to constantly run in the background are undismissable in my case which is what I assumed would happen here with BBS.
[BetterBatteryStats] DiamondJohn:
The looks of those notifications styles, visually sent my mind back in a time warp to Gingerbread.👻

I haven't coded the feature for a while, but a few years back, an easy/suggested technique to ensure your app was not killed as a background process, was to create/issue a persistent notification. I have a newer app (still >4y) I created, and run as a background service, and I do not need to create a persistent notification to keep it off the kill list. Even that app is a few years old now, so I would have to look how I did that. I would *guess* its just in the manifest. ie newer techniques, which may be less reliable, but it has yet to fail me for the last few years.
[BetterBatteryStats] Thebear j koss:
Needs to be set to default.
[BetterBatteryStats] Thebear j koss:
I wish I could go back to ics/jellybean/lollipop theme wise. Material and monet themes are awful and completely ruin android for me. I used to theme every app on my device, I can't even be bothered to begin theming now. You would love my Gboard theme though...
[BetterBatteryStats] Ok_Kaleidoscope5109:
That doesn't solve it. Default still can get swiped away.

So in your case you are able to swipe away the notification on your Pixel 6 Pro? I am on a 7 Pro for reference but we're both likely on Android 13.

The notification is either persistent or it's not. Setting it to default or silent shouldn't change a thing. You can do this with Tasker as well and you cannot swipe it away.
[BetterBatteryStats] Ok_Kaleidoscope5109:
Yes I remember this a bit but I also remember when Google mandated that background services need an undismissable notification as part of Android Oreo and later, so if apps are compliant they must show this.

The only ways around this might be enabling some of those Special App Access permissions such as an accessibility service, enabling the Usage Stats permission, or Notification Access but other than that the notification is required. However when I setup my phone this past week I started noticing a few apps that should be constantly running that used to be undismissable are now somehow dismissable:

BBS: This one has Usage Stats permission so this may be how it continues running in background.

Tesla: I don't understand this one completely but maybe the app doesn't need to be permanently open anymore to unlock your car? Shrug.
[BetterBatteryStats] DiamondJohn:
@Ok_Kaleidoscope5109 my memory of this requirement is from waaaaay before Oreo.
[BetterBatteryStats] Ok_Kaleidoscope5109:
You're talking about something slightly different though. Your earlier post mentioned to keep an app from being killed off, using a persistent notification helps with that to keep it as a foreground process. Apps like Light Flow did that in the 4.x era, but it wasn't a requirement to do so. The developer chose to add taht feature to avoid people complaining about the app suddenly dying or their notification LEDs no longer functioning.

Android 8.0 was officially when it was required that if you had an app it had to either be in the foreground and visible like actively in Spotify and playing video, or you had to show a notification like a media player or in the case of these apps a persistent notification had to be shown to keep running processes in the background as a foreground app.

IIRC Android 8.0 also put in a lot of restrictions on what background processes can do, which is why apps either need to be granted a lot of permissions like notification listener, etc or rely on a persistent notification.
[BetterBatteryStats] SonnyKrockett:
I am SUCH an idiot when it comes to this stuff, but does the P7P need to be rooted to run this?

Don't yell at me if I've missed it somewhere, lol.
[BetterBatteryStats] EtherealRemnant:
From first post - "Fortunately and thanks to @Looki75 there is a way to work around the restrictions intruduced by google in Kitkat and run BBS on non-rooted devices. Please see here for more details."

IIRC, the app guides you through this when you don't give it root.
[BetterBatteryStats] gvp9000:
I have bought the google play edition (version 2.5.344) and now it does not exist.

What should I do ?
[BetterBatteryStats] TNSMANI:
Get the current version from here:

(From the second post of this thread).
[BetterBatteryStats] Ok_Kaleidoscope5109:
To build off of what I said earlier there may be some slightly different behaviors with Android 13.

Now when you swipe down twice to expand the notification tiles completely, you are shown the # of apps actively running. I suspect there may be some differences in how Android 13 handles persistent notifications. It does seem there is a way to keep apps running in the background without a persistent notification now that they show up elsewhere?
[BetterBatteryStats] TNSMANI:
On A12, I am using BBS without the persistent notification ie. it is disabled. No issues. I have another app locked in Recents so that it can run in the background. No issues. You don't have Recents locking facility in A13? That is a much easier solution.
[BetterBatteryStats] asripath:
Fyi...On A13 ...all notifications off BBS...still works...Version 3.0-485
[BetterBatteryStats] GoJo ^^:
Hello, i installed 1.7 RC1 days ago, what's difference with final 1.7? Weight is same so i guess no change... By the way, i see "Wifi ON" and also "Wifi Running", this one only appears when i'm plugged, why? It would be good to know that on battery... I mean, wifi running means while it's not sleeping i guess?

Another issue : Everytime i plug off, BBS seems to freeze for 10seconds then i see "SuperUser rights refused to BBS" and also "An error occured when creating custom reference". Cause of this freeze, SuperUser timing is out and automatically refuse the app. I changed SuperUser option to "always accept" and it works but it doesn't remember the app (i mean forever allow) and i'm not gonna keep the option "always allow"... How to fix this?

@madLyfe: I don't even know how to use this app well but i opened your log and saw "Awake" time is one hour while "Screen On" is 2min only. Meaning there was probably and app keeping the phone awake after you put it to sleep. Don't forget to close all app (with something like ES Manager) before sleep.
[BetterBatteryStats] jeremysherriff:
Change the BBS view to "Alarms" using the top drop-down box. That should make it prompt for superuser access immediately. You could also try Menu->More->Raw alarms. If SU doesn't pop up immediately, you have a problem with something else - possibly the SU binary?

Don't kill off background tasks like that, it takes more battery to restart all the ones that will auto-restart anyway. If you look further into @madLyfe's log, you can see the problems are kernel wakelocks, not a user/application wakelock.
[BetterBatteryStats] shadow3352:
Thanks for the tips. I've flashed and reflashed a few different kernels, and all of them have the sec-battery-adc thing in them. I can't really find anything about it. Google maps is updated to the latest one, and I've gone ahead and disabled Google's backup thing.

Thanks for the help!
[BetterBatteryStats] jeremysherriff:
I see sec-battery-adc in a few other dump files, often with very high counts so it may not be an issue. Your main issue is the wlan wakes - I suggest you set your wifi to sleep. There have been other suggestions too - such as assigning a static IP address to the wifi interface, as the thinking is that the rx_wake packets could be to do with dhcp lease times. I would suggest that it is more likely a problem with one of the apps trying to sync and having issues, if you want to resolve it the best bet is to install "shark" and do some packet sniffing. Not an easy task IMHO.
[BetterBatteryStats] GoJo ^^:
Well yeah i found out that it came by going to rawra alarm. Not idea for the rest'? :)
[BetterBatteryStats] GoJo ^^:
By the way i use battery monitor widget too but %/hour seems ****ed up; you too? Its like going below 0 when using and groing up while sleeping...
[BetterBatteryStats] shadow3352:
Awesome, I'll look into that. Thanks again.
[BetterBatteryStats] p107r0:
AFAIR Battery Monitor Widget is pretty much useless on note - for one the hardware does not report mA usage, so the readings are estimated instead, secondly it increases the battery drain (main reason of wakelocks/alarms on mine when I used to have it installed)
[BetterBatteryStats] kizsleg:
what about adding a simple widget that shows awake and screen on time so that we can monitor it easily when phone is not sleeping well?
[BetterBatteryStats] chamonix:
You are right, 1.7 is the same as RC1.

About wifi running : I will need to take a closer look into this as it seems that the data is not consistent. I show the info whenever the value is > 0

About superuser: bbs requires su to access alarms so it should be fine to go to alarms (upper spinner) and allow bbs from there.
[BetterBatteryStats] chamonix:
That's on my feature list
[BetterBatteryStats] chamonix:
Again, the first log showed 5 hours screen on. Have you been using your phone for that long?
[BetterBatteryStats] chamonix:
Unfortunately nothing new there. I got hands on two test devices (transformer and sgs2) and will do some debugging
[BetterBatteryStats] kizsleg:
thanks, hope to see it soon. :)
[BetterBatteryStats] Register_:
Thanks for taking time. It seems I check a lot of time the Battery Widget.

I join the graph for this day (ended at the time of the dump).

And an other 2 day before where the drain isn't related to the on time of the screen.

The second if I remember well the phone was on debug mode (Parameters > applications > debug)

Regards,
[BetterBatteryStats] ballmead:
I just bought your app, chamonix.

I've been using it for free, for long enough now, so I decided to buy it as it's an excellent program
[BetterBatteryStats] chamonix:
Release 1.7.1

I just pushed 1.7.1, hopefully fixing the wifi running problem. I'll await your feedback before pushing to Google Play
[BetterBatteryStats] intulsa:
I didn't have wifi running, do now. Looks fixed to me.
[BetterBatteryStats] madLyfe:
where do i post about those QR codes on the links that do not open? i know its not your fault, just wondering..
[BetterBatteryStats] sp8y:
Unfortunately "wifi running" still not showing up for me on the latest version.

Thanks for your efforts chamonix.
[BetterBatteryStats] DiamondJohn:
I am running A11. I can FORCE-CLOSE an app (ie hibernate it) which removes it from memory, and kills it (ie not running), and it would still appear in the recents view. ie I dont think it reflects any persistence, but only acts as a shortcut / book-mark to quickly access (or possibly restart it if requested).

PS: The same happens in Oreo
[BetterBatteryStats] TNSMANI:
My experience with the app I referred to (Kinscreen available in Play Store) is different. It needs to run in the background to keep the screen on according to the parameters I set. If it isn't locked in Recents, it is killed by Android and when I unlock the screen, it is no longer running. I have to manually start it again. So, in my usage case, locking in Recents has some effect though technically you may be right.