yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] BruceElliott:
Yes, my Samsung Galaxy S5 was throwing frequent errors from the MotionRecognitionService while phone was majorly messed up following Google Play Services updates over past few weeks. XDA members helped me to resolve on various threads. You can click on my name to find the threads. I finally got my phone settled down. From hindsight, my extreme problems may have been a combination of my tweaking my phone together with Play Services updates. My tweaking was to reduce Google intrusion and Google Play Services updates are to crack down on such tweaking; so I believe that the resulting "oil and water" combo cratered my phone.

The Google app is likely not related to your problem. Disabling the Google app will disable voice search but should not cause other problems. "Google Play Services" updates are likely the problem, as indicated by your logs. Play Services (com.anroid.google.gms) is a critical system service. Disabling it will likely crater your phone completely.

From my experience, Google has made recent mistakes in updating that service, given that they have updated it several times in the past couple of weeks or so. I believe that the best that you can do is visit the Play Store and Google will download the latest Play Services no matter how your update settings are set. FYI I am on Play Services 12.6.85, which works fine after I relaxed the lock-down that I had instituted.

Good luck!

P.S. One of the things that Google Play Services updates did was to institute a heavy-handed SafetyNet crackdown. If your phone is heavily tweaked, it will likely fail the new SafetyNet check. When that happens, if you are lucky you will be able to see your device as "Uncertified" in the Play Store... Settings, bottom of Settings page. If you are not lucky, you may be locked out of the Play Store completely. In any case, then new policy will essentially disable your phone by causing the critical Play Services and all other "gapps" to fail. Do a search on "white-listing"uncertified device to learn how to find the "Google Services Framework" ("GSF") ID assigned to your phone. You can visit a special Google website where you can enter your GSF ID. That will "white-list" your phone and all will play nice, providing that you do not misbehave too dramatically by attempting to lock Google out of your phone.
[BetterBatteryStats] Koong1:
Thanks for your detailed and swift reply. My play services is also at 12.6.85. I am running stock rom (Nougat 7.0) and not much modifying of the phone. I only used a few ADB commands to enable Macrodroid, system UI tuner, XDA navigation gesture and such.

Thanks once again.
[BetterBatteryStats] BruceElliott:
Well, you should be ok then, as far as SafetyNet is concerned. You can check your device "certified" status on the Play Store as I described above. Otherwise, not sure what is going on with your phone.
[BetterBatteryStats] X46X:
Here is it, I switched to 2G/3G with phone on same place.. Thank you
[BetterBatteryStats] TNSMANI:
I meant the screenshot of the page which comes up when you click the battery symbol in your first screenshot. That will show the health of the mobile signal graphically. Doesn't matter, I now see that you have drastically reduced the drain to 0.8% per hour. So if you start switching to 2G/3G when your signal becomes poor, you will save a considerable amount of drain. There are apps to do it automatically.

If you have not reset your wifi recently, do it now. Also, do you have any other device connected to your wifi?

Photos(Fotky) and Outlook sync in the background, draining some battery, though not drastic. Whatsapp is also active in the background. In fact, background sync is your next big drainer. You may have to live with it if you want your phone to be "smart". If you just want a "phone", you can shut off automatic sync.

Significant Motion Sensor was active for almost the entire time the phone was asleep. Have you enabled something related to that?

Everything else seems to be behaving normal. How old is the battery? You can do another dump in airplane mode ie mobile data, signal, wifi, BT, Location everything off. That will give you the base drain below which you can't go, however much you try. That may also indicate the battery's strength.
[BetterBatteryStats] BillGoss:
[MENTION=1330150]chamonix[/MENTION] there are two numbers that I generally use to determine (in general) how good the battery usage is of a ROM/kernel and they are:

- battery usage while asleep (%/hr)

- battery usage while awake (screen on) (%/hr)

I generally take the overnight battery drain as an indication of the first value and then treat all the remaining drain as the second value. That's as close as I can get using the stats in BBS.

I recently came across this display (from EX Kernel Manager samples screens in Play Store) and thought it was perfect.

Would it be possible to have BBS display something similar?

I don't want to say how, or if, this is implemented, but showing % battery used and %/hr battery usage rate on the first three items of the summary page (deep sleep, awake, screen on) would be really nice.
[BetterBatteryStats] Koong1:
This is stupid. Why the hell is Google services using over 4 hours of motion detector sensor? And worse still wakeup=true. I only have a hour of SOT. Most of the Google services drain was during my sleep. Which have WiFi, location and data turned back off. Any one know how to solve this?

(I have posted about this yesterday and the Google player services update don't seem to help)
[BetterBatteryStats] BillGoss:
Could it be Ambient Display is enabled?
[BetterBatteryStats] Koong1:
I turned off my ambient display (always-on-display) two days ago. Don't think it is causing it
[BetterBatteryStats] TNSMANI:
Since this is not a reading from the phone during its idle time, much can not be said about drainers. An idle dump with wifi and data enabled would be better and would be required for a proper analysis.

However, I see that Navigation Gestures drains your battery and it may be the reason for the Google Play Services drain also.

Further switching off everything during idle time will result in a rush from the apps when the phone is unlocked and connections are restored. This may drain more battery than keeping wifi and data enabled throughout.
[BetterBatteryStats] X46X:
Ok I switching to 2G/3G now, thank you!

You mean wifi router or WiFi in phone? Yes, I have connected another phone and 2 notebook to that WiFi.

I need sync for email for I can't do something with outlook.. Can turn off sync in Google photos.

I had an app for my kernel which running background and using motion sensor for some feature. So I have it freezed now.

Here is another dumb in airplane mode.. Thank you!
[BetterBatteryStats] Koong1:
Thanks for your tips. I will test again tonight when I sleep.
[BetterBatteryStats] thewaywardgeek013:
One question to users of BBS that might not have been asked yet, is it better to remove BBS at Android Battery Optimization or just leave it as is?
[BetterBatteryStats] kmem:
I have experienced this for a long time now. I even posted in this very thread about it. I sure hope you can make more progress than I did. I am following closely.
[BetterBatteryStats] strongst:
Just leave it as it is,no significant change when excluding from battery optimization.
[BetterBatteryStats] Koong1:
Good morning~

Below attached is my dump file for last night. Roughly 7 hours of sleep. I noticed I only have 0.3% per hour of battery drain while keeping WiFi and data turned on 100% of the time. I don't think my phone battery is acting normal.

The only two noticable difference I made to the phone before I went to sleep is that:

1. I charged my phone to 100%, and still let it plugged in for 10 mins or so before I unplugged it. I usually charge it to 90+%, I heard fully charging the phone wears down the charging cycle quickly. Also, everytime I 100% charge my phone, the battery seem to drop slower from 100% to 80%, it is like there is some kind of hidden battery storage.

2. Lay the phone flat on a hard surface away from my pillow. I used to put the phone right beside my pillow, maybe my snoring and turning caused the phone to wake?

Also in the dump file, Google services used ridiculous amount of time on the significant motion detector sensor. This kind of sensor time shouldn't result in on 0.3% per hour drain, it should be at least 0.5% per hour.

Is there an issue with my battery not displaying the percentage correctly? Or is there any other issues that I failed to think of?

Thanks in advance for your time and effort.

P.S. After all, a phone is merely a device to make my life easier, I shouldn't be too troubled (OCD) about the battery life. By typing out this message, my battery dropped 3% in around 15mins.
[BetterBatteryStats] DB126:
Right on. 0.3%/hr avg idle and 12.0%/hr avg active are fine. Park the OCD and enjoy your well behaved device.

Want a better read on avg idle drain? Start the study at 90-95% charge vs 100%.

Active battery drain a concern? Lower the panel brightness (biggest power suc by far).

Charging a mobile device battery to 100% will do no harm provided it is not left in a fully charged state for a prolonged period. Same with running down below 20%.

And for gawds sake stop fussing over sensor utilization that has no impact on battery endurance.
[BetterBatteryStats] Koong1:
Hahaha thank you for your insights and advices. I shall no longer fuss over sensors. (Facepalm)
[BetterBatteryStats] TNSMANI:
OK, so your drain in airplane mode is 0.3% per hour and the earlier reading with data and wifi on was 0.8%. You can't go below 0.3% whatever you try.

So now post another idle dump with wifi, data on and on 2G/3G.

I meant your wifi modem/router. Since some more devices are connected to it, in the earlier dump there was some chatter between the devices. You can disable the other devices while taking the next dump to see whether it improves the drain rate.

My guess is that you will end up somewhere around 0.5 and 0.7% which is good for Oreo.

---------- Post added at 02:37 PM ---------- Previous post was at 02:21 PM ----------

Since you have a doubt (me too), repeat the test to confirm. Since you are on Nougat, anything below 0.5% is ok.

There are some niggles still, but if the next dump shows anything below 0.5%, forget everything else and enjoy your device as the others said. Your alarm stats also don't show the detail of which app sparked the alarm except to say Android. It is difficult to diagnose in such a scenario. Don't you get alarm stats if you disable API in BBS settings?
[BetterBatteryStats] xn0live:
Hi,

can anyone check my BBS

i get always only round about 3:30 hours screen on
[BetterBatteryStats] strongst:
Uh, usage can lead to misunderstanding. That's why only idle dumps should be analyzed.

Galaxy s5 is old, maybe your battery capacity isn't good anymore due to aging.
[BetterBatteryStats] strongst:
[MENTION=8613713]uswername[/MENTION] your deep sleep time isn't hight enough. Please read first post whats needed for a suitable log.

And if you have enough posts(xda new user guide), please attach the dump file rather than post its content in the post :good:
[BetterBatteryStats] Oswald Boelcke:
Additionally to that what @strongst correctly stated you can paste your log to e.g. hastebin and simply post/add the respective link.

Please be aware that the "hide functionality" only works if you visit XDA via browser but not on XDA Labs i.e. you are definitely cluttering the screens of XDA Labs users.
[BetterBatteryStats] thewaywardgeek013:
Found this tidbit of info when searching the Thread

https://xdaforums.com/showpost.php?p=75285615&postcount=33604
[BetterBatteryStats] strongst:
If you have specific issues, yes.
[BetterBatteryStats] BruceElliott:
Writing a log file...

Hi All,

It is not clear to me from the instructions at the start of this thread how to initiate writing the log. Under "sharing options" there are check boxes to choose a log type. Does merely checking a box cause the selected log to be written to the selected storage location? I don't see any other "go" button to initiate writing the log.

Also, a small suggestion. I find the graphs very useful. (A picture being worth a thousand words.) However, the lack of any timeline identifiers is frustrating. (I realize that it is often a problem with complex timelines to fit a legend on a small screen.) But what about something like three small arrows at the top of the top-most graph, pointing downward. From left to right, one arrow at the far left (at the vertical axis), one at the midpoint along the horizontal axis, and one at the far right of the horizontal axis. Each of the three arrrows would be a different color. A connecting line from each would travel upward and then turn 90 degrees to the right. To the right of each such line segment would be written the absolute time (HH:MM:SS.XX) of the start, middle and end of the graphing period. That would help me, at least, to remember when I took the trace and the period of the trace.

Thanks,

Bruce
[BetterBatteryStats] BruceElliott:
Never mind the question...

I found the save function, under the "share" icon.

As to my suggestion above regarding the graphs, I now understand my intuition that some sort of timeline legend is necessary. As I have experimented with the app, it has become increasingly clear that the wifi graph, at least, is way out of whack with the "history" log. First, the app helped me to discover Google's tricky-dicky hiding of Play Services' ability to toggle wifi on and off at will with no notification whatsoever. That is no doubt to increase bandwidth for "snatching up" user data via sync options that are default-enabled before the user has an opportunity to become aware of the condition, and even re-enabling sync after being user-disabled under cerrtain circumstances.

Before that discovery and making sure that wifi was definitively turned OFF, the wifi graph showed a strange straight-line curve upward from 0 ("OFF") at t=0 (left-hand side) to wifi "ON" at t=max. Of course wifi state is binary, so that could not be correct. However, such a graph could result from plotting "history" values if history shows wifi as "OFF" until the final value, with the final value being "ON" with no transition to "ON" until t=max. In any case, I found the tricky-dicky "allow Google to arbitrarily toggle wifi on and off at will" setting nicely buried under "location" settings.:) So I figured that the clandestine toggling might not be written to the battery stat logs.

After revoking that madness to ensure that wifi really was "OFF" when I set it to "OFF," the wifi graph became binary as expected. However, after experimenting with toggling wifi on and off several times at 10-15 minute intervals and opening BBS each time to look at the wifi graph, I see that the history log looks correct but that the graph is often way out of whack. I will do a bit more rigorous testing and post screenshots, probably tomorrow.

Then I will move on to the gps graph and see if that tracks the history. The graphs are a nifty snapshot of the monitoring period, so it would be nice to be able to rely on them...

Note that this is not a complaint nor am I seeking any kind of answer (unless my methodology is flawed; I would certainly like to know in that case). My comments are merely FYI to the developer if he is not already aware of this problem.
[BetterBatteryStats] buffal0b1ll:
2.4-256 seems to be working on DP3?

Does nag about incompatible API, but it's showing stats.

I got no stats at all on DP2.
[BetterBatteryStats] uswername:
[MENTION=613506]strongst[/MENTION] Thank you. sorry I'm old 4pda.ru forums user, so wrote my post by their rules (habbit)

I can't attach so here is hastbin link to my log

hastebin.com/ayusagogar.scala
[BetterBatteryStats] uswername:
If you' ll find something like this, olease could you write a little FAQ where the such drainage is comig from and how to turn it off?
[BetterBatteryStats] strongst:
Thanks for the dump! There's nothing going roque which indicates a high drain. You have 1%/h which isn't bad. A little exposed, but not bad. I don't know how your wifi signal strength impacts on this,but since there are no exposed wakelocks etc. you can't do anything.

You can check the device forum to compare to other users :good:
[BetterBatteryStats] Oswald Boelcke:
This was already occasionally discussed in this thread. It's called WiFi- and Bluetooth-scanning. See attached screenshots to locate the respective setting. Second screenshot you need to tick on the three perpendicular dots in the top right corner.

To disable these scannings not only improves battery duration but in my opinion is also important for enhanced privacy.
[BetterBatteryStats] DB126:
Oi - another conspiracy oriented arm chair detective discovering what billions have missed. There is nothing nefarious going on nor clandestine toggling of radio settings. Google is pretty clear on what they collect and how (in general terms). Don't like it? Go with microG or Apple. The former will consume half your life configuring/managing a faux 'dome of silence'; the latter has its own suite of exposures. There are far simpler ways of reducing the amount of info providers collect. Also pretty easy to configure your device to behave the way you want with root permissions. No root? Get a different handset.
[BetterBatteryStats] uswername:
[MENTION=5488402]Davey126[/MENTION], yeah. root permission give you full control, but only if you are understanding what you are doing! is there any beautiful step by step manual how to not damage your device and make safe surgery to it.

search will give many posts, but which is right?
[BetterBatteryStats] DB126:
General approach is pretty simple:

- don't mess with anything you don't understand

- don't go looking for 'problems' as they are everywhere both imagined and real

- monitor and measure; can't fix what you can't quantify

- identified an issue? Research it and apply only the minimum changes needed to address the concern. Specific problems usually have well defined solutions.

- review point #1; don't follow some guide just because it exists

- backup everything before twiddling knobs

- make sure you have a recovery path should things go wrong

Hum, seems too complicated. In that case the best course of action is to enjoy your device for what it is. It's probably 'mostly correct' right out of the box. :)
[BetterBatteryStats] TNSMANI:
Though your wifi is reported to be on and running for the whole time, there are periods when the mobile data kicks in and it leads to some wakelocks because of the frequent switching between wifi and data. When did you last reset your modem/router? Reset it now. Do you have other devices connected to the same wifi/router? If so disconnect them and take a fresh dump. How is your mobile signal at home/the place where you keep the phone while taking the dump? I don't think it is very good. If you are on 4G/LTE, switch to 2G/3G for the duration of the dump.

There was some background downloads on mobile data by Play Services, Viber etc. If your mobile signal is not great, this will cause some drain.

I think that your Location setting is on. Do you require it to be on when the phone is sleeping?

Your wifi/mobile signal is by far the worst villain.
[BetterBatteryStats] strongst:
Why you recommend all the time to reset the home wifi router? Now he should do it now. There's no real background, an none for the quoted dump.

Investing hours of other unnecessarily actions(resetting wifi router, disconnect devices) without approval(wifi is causing the high drain you mention) but obviously he has 1%/h(not 15 or whatever) drain is a waste of time imo.

All other is already said by [MENTION=5488402]Davey126[/MENTION]
[BetterBatteryStats] Oswald Boelcke:
DELETED
[BetterBatteryStats] strongst:
[MENTION=7408621]Oswald Boelcke[/MENTION] I quoted you but you removed your whole post:D

This was not the answer to tsnmani's post, just for clarification.

Resetting the router to obtain new IP adresses won't help to reduce battery drain. DHCP generate leases and after a lease the ip will be renewed. That's the purpose of DHCP, but differently implemented in every soho router.

Your android phone will obtain most likely the same ip every time cause of stickiness in most routers.

But that's not the right topic to discuss fundamentals of network functionality. So BTT: don't dig too deep. and you really won't be able to recognize 0.1%/h better drain.

That's only for statistics and static tests under special conditions, not for a daily usage scenario(nobody does the same every day) ;)

Personally I have DHCP enabled at home/work and get idle drains of 0.5-0.7%/h but this variety depends on apps, the mobile phone signal and other factors.
[BetterBatteryStats] TNSMANI:
You are entitled to your opinion and likewise I am to mine.

I have indicated in my post why I suspect the wifi/mobile signal to be the villain. I don't recommend resetting the wifi to everyone every time. It just so happened that the last couple or so of the members having problems with drain, had issues with wifi. Resetting the router and disconnecting devices will hardly take hours.

He was asking for help and you provided it. I added my 10 cents worth. He can take it or leave it.

I am resting with this. I will not respond further.
[BetterBatteryStats] zulusik:
Hi everyone,

Can someone please help? I have a HUGE drain, and want to understand if this is a dead battery, some app or setting, or both together?

Some background: my phone is a 1.5 year old HTC 10. I was running stock till last week. After upgrading to Oreo (stock) the battery life became awful, and was degrading quickly. And when looking at standard battery stats, there was no apparent app "eating" the battery. Besides, the phone sometimes dies when battery reaches 20-30%, but sometimes goes down to 0-1. Finally decided to root and jump to custom ROM, and took this dump. In 5+ hours, the battery went from 96% to 1%!!!

Will appreciate any help. Thanks in advance.
[BetterBatteryStats] Oswald Boelcke:
I know but I'm now finally out of this thread. Happened to me already once. For me, it's done.

A search within the thread for the keywords "fixed IP" is going to lead you to quite a few posts of me and e.g. Davey126 why I mentioned that in the post above, which I deleted.

Actually, it hasn't anything to do with the router, that's just the tool. And I guess I'm sufficiently familiar with DHCP, lease times etc. But at least my devices with their kernels "behave" much better if the WiFi-network connection isn't set to DHCP but to static; however, certainly device depending but mine are out of 2012 (or about) and still working great to my desires.
[BetterBatteryStats] strongst:
I know about that and also the post of Perseus https://xdaforums.com/showthread.php?t=1179809&p=59241587 but where in this dump file

https://hastebin.com/ayusagogar.scala should the wlan wakelocks are shown???

[MENTION=5656100]tnsmani[/MENTION]

That's what I mean, I can't find anything related that proofs a WiFi related wakelock.

Just for information: DHCPdiscover messages are only sent when an ip adress is needed until DHCPoffer arrives on that device and not permanently keeping devices awake. Until the lease ends, no DHCPdiscover messages will be sent. If a device sends permanent DHCPdiscover messages, that device needs to be troubleshooted(like the mentioned printer for example) and not the smartphone or router that will be set to static addresses along with other devices.
[BetterBatteryStats] DB126:
Hum - seen this movie before. Deep breath, gentlemen. We are all on the same team. As a trusted mentor once quipped: opinions are like [colorful descriptor]: everyone has one and they all stink.
[BetterBatteryStats] maybeme2:
Nexus 5 with LineageOS 14.1 installed.

Battery runs down very fast and I'm not sure what is at fault. I am attaching a dump file for a period when I left the phone off for hours. Hopefully it shows why.

I'm traveling and data is turned off to avoid remote charges. So I'm only using hotel wifi.