yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] jeremysherriff:
I see nothing obvious, the partial wakelocks and kernel wakelocks don't add up to the more than 1h of awake time. That probably means a radio issue. What's your 3g coverage like? Can you force it down to 2g for a while and see whether the drain stops?

---------- Post added at 10:41 AM ---------- Previous post was at 10:34 AM ----------

@aashgaur your dump covers your daily usage, can you take another dump file just covering a period of no use (such as when you are asleep) please?

Also, your dump file is incomplete (no kernel wakelock information).

Reboot your phone.

You have around 1h of "awake" over and above your "screen on" - that's not too bad for a 32-hour period.

Do you actually have bad battery drain? Did you charge at all in the 1d 8h that this dump covers?
[BetterBatteryStats] iovaniorgovan:
Hello everybody,

This might be an unseen beast inside the ICS approach for Samsung i9100. So, I'm running a beta release of ICS 4.0.3, XXLPH released 12feb2012, on a slightly modified ROM called Omega v3.0, made by indie.

Only over 2G and 3G (not Wifi, not no-data) I get these massive wake locks:

-GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservi ce.AndroidEndpoint with amounts of 4%, 6%, 12%, 19% or more wake time.

And it is not Google sync (mail, calendar, etc), GTalk, G+, G+ messenger, Google backup, google location, location and google seach because I disabled them one after another and still get the wake lock. I went as far as removing the Google account from my Android device and I'm still getting this wake lock.

- GTALK_ASYNC_CONN_.............@gmail.com/android_talkbb255d1baef with amounts of 4, 4.5%, 6%, 12% wake lock. In this case, I am not running Gtalk either. I replaced my gmail address with dots..........

The Android.Endpoint wake lock has been mentioned 3 times some in the 340 pages of this topic, but it wasn't in such a huge amount and nobody examined it deeper.

Any ideas?
[BetterBatteryStats] Icey34:
Hey guys would having nfc on on a galaxy nexus affect battery much?
[BetterBatteryStats] rocky459:
Hi, not sure but if you are rooted as per your tagline, you can check appops application(s), if any of them allow to perform this operation. Thanks.
[BetterBatteryStats] thewaywardgeek013:
Xiaomi Mi A1

Stock ROM

Non Rooted

Android Oreo 8.0

Hi [MENTION=1330150]chamonix[/MENTION] would like to report a bug.

Import/Export of Preference does not work properly. BBS does not ask permission for Storage, which I need to give permission thru App Info, and with that enabled, it can only do an import of a backup. Export results in "The operation failed" message.

Attached is a screenshot of the issue plus logcats.
[BetterBatteryStats] TNSMANI:
No/Unknown signal for 100% means that your mobile signal was available for 100% of the time. No weak or patchy signal. It is a good thing.

Since your dump is not an idle dump (phone used for nearly 4 hrs), it is not possible to make recommendations based on this dump.

Search this thread for instructions on how to save an idle dump and post one here.

---------- Post added at 04:53 PM ---------- Previous post was at 04:36 PM ----------

Wrong thread!

However, the list is not updated for N or O, AFAIK. Even the app has not been updated. Most of the names have changed and some have disappeared in O. But still the app is usable (but carefully).
[BetterBatteryStats] fridrik:
In less than an hour and already had 3% of drain. ?

Is it because of these kernel wakelocks? fpc_ttw_wl

qpnp_fg_memaccess

qpnp_fg_update_temp
[BetterBatteryStats] AndroidWars:
Thank you so much :good:
[BetterBatteryStats] DB126:
This is BBS thread; other app questions/concerns should be posted in their respected threads.

---------- Post added at 01:04 PM ---------- Previous post was at 12:59 PM ----------

So is a kitchen knife by a toddler; outcomes are generally predictable. :)
[BetterBatteryStats] thewaywardgeek013:
Anyone having the same issue as I have, feel free to jump in.
[BetterBatteryStats] lazostat:
How can I benefit from this app? I have bought it and have it running this week.
[BetterBatteryStats] DB126:
Read the OP.
[BetterBatteryStats] :
OP: https://xdaforums.com/showpost.php?p=15869904&postcount=3
[BetterBatteryStats] RASTAVIPER:
I also used appops and there is no sensor tab.

Any other permission that could help if I block it?

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] rocky459:
Do you use gestures in launcher? Try disabling them all, most probably, they are the one using sensors, also remove any extra permissions like device admin, usage access from MS launcher.

//In case this doesn't help, then idea is same to revoke sensor permission but don't know how to do it on your device.

---------- Post added at 09:14 AM ---------- Previous post was at 09:01 AM ----------

Don't you have 'Sensors' section in App Permission?

Settings - App&Notification - App permissions - Sensors?
[BetterBatteryStats] TNSMANI:
Firstly, a dump for less than 6 hrs can not form the basis for recommendations. Post a proper idle dump.

Secondly, it is preferable to wait for the battery to drain below 95% before starting to measure the drain. Some batteries, especially older ones, drain faster from 100% and then stabilise.
[BetterBatteryStats] RASTAVIPER:
Only body sensors, but no launchers in there.

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] rocky459:
Out of ideas :(
[BetterBatteryStats] DB126:
Still looking for that illusive link between "sensor occupied" and battery drain...or any other undesirable behaviors other than being noticed. :rolleyes:
[BetterBatteryStats] fridrik:
Yes, but I referred to this amount of kernel wakelocks.
[BetterBatteryStats] DB126:
Kernel (or any type of) wakelocks are a characteristic of some activity which may or may not be associated with battery drain. The objective is to identify and mitigate root cause vs squashing symptoms which leaves the culprit unchecked. Log was insufficient for any type of accurate diagnosis although there were some tantalizing clues (finger print sensor; Titanium Backup ...) that may or may not play out over a longer period. Be sure to begin the study at a level not exceeding 95% as I suspect your middle-age battery may have lost some of it's full charge endurance.
[BetterBatteryStats] Vordx:
Any of the pros here know what is this?

" media.extractor "

Help is appreciated.
[BetterBatteryStats] RASTAVIPER:
And how do you claim that such link doesn't exist?

The logical conclusion is that when you see a sensor occupied at a so high rate, that also it can drain the battery.

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] DB126:
Possible but certainly not conclusive. There are many components/sensors that remain "occupied" for prolonged periods with negligible drain. You could easily run a BBS study to determine the impact. That said it's your device. If you want to play sock-a-sensor, whack-a-wakelock or take other steps to override behavior that is not well cataloged have at it.

Good thing BBS doesn't report on internal organs. People would be going after heart, lungs, nervous system, etc. as they too are continuously occupied.
[BetterBatteryStats] m0han:
looking for help to get better sot/standby times. thanks, everybody.

Statistic Type: Custom to Current

Screen On (): 58 s 0.2%

https://pastebin.com/x713v7VR

device/battery about 16 months old

mostly in locations where cell signal not good
[BetterBatteryStats] DB126:
Device idled normally with <1% awake time (~4 min) over the 7+ hour sampling window. No apps misbehaved, no egregious wakelocks, network traffic or CPU usage. Battery run off averaged 1.1%/hr which is elevated given idle behavior. Thoughts:

- Aging battery may not have the endurance it once did.

- You may not be doing yourself a favor running Android 8.1 on a device that was engineered for Lollipop. Likely the ROM nor kernel are optimized for the shotgun marriage. If life changed significantly after upgrading from your previous ROM a rollback may be in order.
[BetterBatteryStats] m0han:
many guys on the rom thread go gaga over their high sot on stock kernel.

i was wondering 'why not me'! maybe they have newer devices/batteries.

don't feel like going back to nougat. your tips are very much appreciated.
[BetterBatteryStats] RASTAVIPER:
Ok got a reply by the developer of Microsoft launcher.

They are going to settle this issue at the next release.

I guess there was already concern from other people as well.

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] DB126:
Receiving a direct response from the developer is a good outcome. It does not mean there is a problem beyond optics (or there could be). If app behavior can be modified to reduce user concern it is a 'win' for all parties.

---------- Post added at 12:46 PM ---------- Previous post was at 12:27 PM ----------

SOT is a horrible metric as it is often exaggerated (fish stories) and typically quoted without accompanying detail such panel brightness, environmental conditions (eg: signal strength), radio/location settings, background activity and apps being used. A device being used for 3D gaming in bright sun will have significantly less endurance than one used for reading in a dark room. Unqualified SOT is the electronic equivalent of "mine's bigger".

That said, your device is exhibiting elevated idle drain despite a well behaved app portfolio. Suspect 'active' drain rates are also elevated leading to less usable time between charges. A couple potential reasons are mentioned in a previous post. Fairly common for a mid-age device that may have seen heavy use. My daughter's iPhones are typically shot after a couple years due to near continuous engagement with media rich content. Takes a heavy toll on batteries.
[BetterBatteryStats] Haldi4803:
Got an Email from AskSven, via Hockey. Version 2.4 is out.

I could download the APK in the browser without the need to install the Hockey app.

That was cool! i like.
[BetterBatteryStats] _MoD_:
Moto Z Play Battery Drain 5%/hour in idle condition

Hello,

Can anybody help me with the battery drain problem. It's a severe 4-5% battery drain per hour in device idle condition even with wifi & mobile data off. I have tried every possible solution i.e. factory data reset (twice), wipe cache. The drain persists even if I don't install any third party apps after factory data reset. So I think android system is malfunctioning. I have generated BBS dump log for 7 hours. Since I'm new to forum so unable to provide link or attachment. If there is anyway to attach the file kindly help me with that. Meanwhile I'm posting some dump file information in this post directly. Kindly anybody help me out with the issue.

Thanks

Pastebin link: pastebin.com/JFSvyyrm
[BetterBatteryStats] strongst:
[MENTION=9055062]_MoD_[/MENTION] can you please attach a full log instead of pasting half of the its content here, it makes the post unreadable. Thanks!
[BetterBatteryStats] TNSMANI:
Did you charge the device during the measurement? One of the screenshots suggests so. If so the readings are skewed and may not be helpful.

But as Davey said, the phone behaves normally and nothing jumps up for correction, except, as you yourself mentioned, the mobile signal. It was patchy and that could be the main reason for the drain. Arresting that will definitely reduce the drain.

---------- Post added at 04:57 PM ---------- Previous post was at 04:45 PM ----------

Your mobile signal was patchy and you were on mobile data not wifi. The patchy signal was the main culprit. Apart from that, the dump doesn't contain alarm details, so unable to offer further suggestions.

Next time, post the full dump on pastebin or similar site and provide the link here.
[BetterBatteryStats] chamonix:
New experimental build is up with big changes in the way BBS was handling root. Until now root was used to conduct different operations (e.g. get access to kernel wakelock files when they were not world readable). As over time we have achieved feature parity between root and non-root I have refactored the code to not rely on root except for granting the perms.

Please give me feedback on following scenarios (root users):

a) features are still working and nothing is missing

b) root is really not used at other places anymore; this may be harder to test as revoking root will not help
[BetterBatteryStats] chamonix:
Fixed in current 2.4 build
[BetterBatteryStats] m0han:
yes, had to reboot and also charge, albeit not fully (i've marked my screenshot). which is why Statistic Type: Custom to Current. i might change provider soon and see if things improve. will get back here to post results. thanks. happy easter, folks!
[BetterBatteryStats] _MoD_:
Sorry for that...as I said I'm unable to attach the log or provide the external link as per forum rules as I'm new to forum, so had to paste the log in the post.
[BetterBatteryStats] rocky459:
Provide link by entering space between dots. Write it in a way that it doesn't form a URL.
[BetterBatteryStats] _MoD_:
updated the pastebin link for the BBS dump log in the original post. Kindly have a look and suggest some measure.
[MENTION=5656100]tnsmani[/MENTION] : I had generated the dump log after disabling mobile data as well as wifi. Also I had tested the phone in aeroplane mode also for a brief period of 20-30 minutes, the drain was same. So I doubt that signal is causing such a drain persistently.
[BetterBatteryStats] DB126:
Incomplete log in pastebin (truncated).
[BetterBatteryStats] _MoD_:
What is missing? I have pasted complete dump log. Do you want logcat file also?
[BetterBatteryStats] DB126:
Sorry - my bad. Mobile device I was using cut off log after 103 lines (hasn't done that before).

Nothing wrong with with Android; idle stats were excellent with <1.5% wake time, low CPU use, no persistent wakelocks and no misbehaving apps/services. Problems appears to be deeper. Possibilities:

- failing battery (most likely)

- malfunctioning sensor or radio

- dirty/damaged fingerprint sensor

- kernel corruption

This assumes BBS stats are accurate which at this point I have no reason to doubt. Bottom line is there is nothing in the BBS log that indicates the source of the problem other than it isn't Android or the installed apps. Sorry.
[BetterBatteryStats] _MoD_:
thanx for the insight Davey. The sensors are ON for whole the time as appearing in the log, is it normal? and I doubt that battery has issue because I noticed the draining issue about 30 days ago. Before that everything was smooth also the handset is about only 17 months old. Is there any way I could find the exact problem? How could I update the kernal? Or how would I know if any sensors malfunctioning?
[BetterBatteryStats] Vordx:
Using latest release , note 8 , Oreo.

As you can see the No Data Connection is on 100%.

While trying to share the dump before , the app crashed too. Sent a report after that.

PS : while trying to save this file my whole phone froze. Not sure if that's normal , but that's kinda scary and annoying.
[BetterBatteryStats] DB126:
- app crash is not normal

- phone freeze is not normal

- study is <90 min in duration; min request is 6 hours

- not an idle study; screen on time exceeds 1 60 sec
[BetterBatteryStats] DB126:
Nothing in the log suggests the observed idle drain level (>3% per hour). If the problem began suddenly think back to what happened a month ago. Did you receive a system update from Moto or your carrier? Don't be too quick to dismiss the battery. They can slowly loose endurance or fail suddenly. That said, starting and terminal voltages were fairly consistent which usually isn't th case if the pack is taking a dive. As for sensor activity every device is different. Being "ON" does not necessarily correlate to excess drain.

In your shoes I would completely reinstall the ROM which will also include a kernel refresh. However, that's not always easy to do on an unrooted device. Moto (Lenovo) provides a tool called RDS Lite for this purpose but it's none too user friendly. If you carrier has local service centers might see if they will refresh your device for a modest fee. Be sure to backup any important personal items and the technician may end up wiping it (intentionally or by accident). Good luck.

p.s. Might take and submit another BBS idle study in the highly unlikely event the one previously posted was somehow compromised.
[BetterBatteryStats] _MoD_:
Just took another overnight Idle log(with Aeroplane mode). Pastebin link: pastebin.com/enwcDwkY

Results are exactly the same I guess. Even the voltages are consistent with previous log. Though there seems some very high counts in Kernal Wakelocks this time. I don't know despite such high counts, why the percentage shown against them are so low?

I think the issue came after the December security patch. Or some data recovery softwares i.e. FonePaw which I used to recover some of my lost files. It did installed something using ADB. But after factory resetting that wouldn't have been undone I guess? Issue with security patch is ruled out because one of my friend is also having the same phone with the same updates and it's working fine.

Should I wait for Oreo update? Will it update the kernal also? Can I get official Nougat ROM for my phone with fresh kernal ?
[BetterBatteryStats] Vordx:
You mean , I should wait another day and report again , or? Bit lost here.
[BetterBatteryStats] jndvlp:
Thank you for your great app.

I have just one questione, i'm on nougat rooted with magisk, safetynet is green.

Installing the last versione of better battery stats will it keep the boot partition uncorrupted and safetynet green?

Thank you.
[BetterBatteryStats] DB126:
Although not the developer I can say with confidence all Greenify BBS builds "keep the boot partition uncorrupted". Whether a device continues to pass Safetynet is dependent on a variety of factors - none of which are directly attributable to Greenify BBS.

Edit: fix app gaffe noted above. :eek:
[BetterBatteryStats] yochananmarqos:
Greenify, eh? :laugh:
[BetterBatteryStats] DB126:
Damn - gotta lay off the bunny juice!

Fortunately, the answer applies to both BBS and Greenify (whew!). The only possible caveat is the manual granting of permissions for BBS which might trip up Safetynet - although this seems highly unlikely. I suppose something could have crept into v2.4 that would change that assessment - also seems unlikely.

Going to pour the rest of that bunny juice down the drain ...

G is for Greenify

B is for BBS :rolleyes:

---------- Post added at 08:16 PM ---------- Previous post was at 07:58 PM ----------

Read the first few posts in this thread for guidance on creating an proper BBS activity log (aka idle study) of appropriate duration. Also here. The BBS app should not crash or freeze your device. If it does there are bigger issues that need to get sorted before worrying about power consumption and battery drain. Be sure to grant the necessary permissions if not rooted.

---------- Post added at 08:22 PM ---------- Previous post was at 08:16 PM ----------

I think these questions are best answered in your device forum. Especially if others with the same device are experiencing similar issues. From the BBS logs submitted it seems Android and/or your app portfolio is not the culprit. Device related issues are really beyond the scope of this thread.
[BetterBatteryStats] jndvlp:
Thank you for your answer.

I won't grant manually on magisk root permission to better battery stats.

Thank you.
[BetterBatteryStats] js.tan:
hi [MENTION=5488402]Davey126[/MENTION], do you mind help me look at my latest dump.

i have tried using 3rd party app as sugested, but it seems the battery drain are same compared to my first dump.

My first dump is in the post that i quote.

and also any suggestion to extend SOT?

thanks.
[BetterBatteryStats] DB126:
Idle drain rates in the three samples provided were 0.2%, 0.3% and 0.6% per hour which I'd characterize as tremendous, excellent and very good. Nothing more needs to be done IMO. You'll need to shop elsewhere for xtreme power management methodologies. SOT guidance is also out-of-scope (opinion here). Enjoy your device for what it is.
[BetterBatteryStats] lazostat:
I have a question about permissions. Is it possible an app an have permissions on my phone, even if I have disabled them all?

And what about services? How can I disable them?
[BetterBatteryStats] DB126:
Wrong forum/thread for this type of question.

[There is one button solution for the privacy paranoid. It's labeled 'power' and effectively disables all permissions and services. However, it does have an adverse effect on usability].
[BetterBatteryStats] js.tan:
Really appreciate your reply. Thank you so much
[BetterBatteryStats] sreefu:
Unable to get Kernel Wakelock Stats

Hi, would appreciate if someone could help me. I purchased BBS 2.3-247 and everything worked fine except I wasn't able to get the kernel wakelock stats. Kept showing No stats have been collected yet. My device(oneplus one) is unrooted and I have granted all 3 permissions via ADB. The following are what I've tried without any success:

enable watchdog

enable debug

enabled Alarms, kernel wakelocks and network using API

Later on, I decided to root my device via Magisk and reinstalled the BBS from Playstore and granted root access to BBS. Still rendered same results where kernel wakelock stats were not collected. This was also the same even after pushing BBS (playstore) to system app via Systemizer Magisk Module. I have also tried to install BBS xda editions (including the latest beta 2.3-248) but still not able to get it working.

On the other hand, I also installed the xda edition on my spare device (Moto G - rooted Oreo) and it was able to immediately pull stats on the kernel wakelock menu straight after the installation. I'm really puzzled now. Does this have something to do with my first BBS installation from playstore ? Please do advise if anyone have encountered such scenario and if you have a fix.

Device: OnePlus One

ROM: Unofficial LineageOS 14.1 by SultanXDA (with default Sultan kernel that came with the ROM)

UPDATE (EDIT):

- Wiped entire phone (removed encryption)

- Clean installed same ROM

- Rooted the phone (Magisk)

- Installed BBS from Playstore

Result: Still
[BetterBatteryStats] hypern0va:
I can report that the same problem also affects the official version of LineageOS 14.1 for the OPO.
[BetterBatteryStats] hopecore777:
I'm running crdroid 3.8.6 & have a built in root. What's wrong I already granted permission.
[BetterBatteryStats] thewaywardgeek013:
That was fast! Will wait for the update to be pushed in Google Play to check it! Thanks a bunch! And kudos to your work on this awesome tool!
[BetterBatteryStats] TNSMANI:
It means that the built in root is not compatible with BBS. Try a different root solution (SuperSu and Magisk work with BBS) or grant permissions through adb.
[BetterBatteryStats] chamonix:
I would rather your feedback after a test prior to releasing if possible

Edit: typos
[BetterBatteryStats] SingularityHRT3:
Is it safe to block those alarms above 15 counts??? Seems like Xposed is not working for Me so no Amplify to limit them but I can block these alarms, but is it safe??? What are the shortcomings of blocking it altogether???
[BetterBatteryStats] TNSMANI:
A majority relate to Location and switching off (or using only when needed) Location and BT/wifi scanning would resolve them. Some of the rest are unknowns and blocking them (as opposed to limiting) may potentially brick your device.
[BetterBatteryStats] SingularityHRT3:
Can I disable those two location related alarms (namely ALARM_WAKEUP_ACTIVITY_DETECTION and ALARM_WAKEUP_LOCATOR) using alarm blocker (included in the system)??? Because I having bootloop issue with Xposed so cant limit alarms using Amplify (and dont know any other alternative other than to completely block it and these two alarms are up every minute)... Or can I deny location permission to Google Play Services??? Will it affect any functionality???
[BetterBatteryStats] DB126:
Why are you blocking alarms in the first place? Simply disable location services via normal Android UI (settings) and be done with it. Alarms do not equate to battery drain. What service responds to the alarm the actions taken (if any) determine if there is a negative consequence.