yashsingh1/xdaforums huggingface dataset:
[Android General] cristixperia:
:cool:
[Android General] AndroidWars:
Can I get more SOT?
[Android General] MuadDib6:
Hello all, i'am a long time android user but i dont have so much time nowdays as i used to. I know I should use search but I really dont have much time with job and college. I noticed most roms nowdays have some sort of powernap, and amplify seems obsolete now. Is greenify only way to reduce power compsution and is there any good guide for xprivacylua? Thanks in advance, sorry once again for not doing research.
[Android General] :
Quick question -

I own a bacon I left dead for 6 whole months because I got myself a new phone. I decided to use my bacon again. Charged it up, installed a stable rom and started using it. I am finding that my average battery life has significantly reduced from being 6hrs 4G SoT to barely 4hrs 4G SoT.

Did I kill my battery by not charging it for 6 months or is it because my phone is 3-4 years old by now?
[Android General] gothicVI:
Might be the battery. Lithium ion batteries are quite easily damaged if not charged regularly and correctly.

Gesendet von meinem Moto G 2014 LTE mit Tapatalk
[Android General] marinegundoctor:
You could always replace the battery if you don't want to get another phone. $10 (US) https://www.walmart.com/ip/3030mAh-...0890&wl11=online&wl12=347120852&wl13=&veh=sem
[Android General] ichigo696:
Any suggestions? (Replace with a decent battery is almost impossible). One plus One - tugapower Oreo.
[Android General] luke1513:
wow, that is really affordable. i sent it to service last tuesday and it cost 35$. still didn't come
[Android General] strongst:
According to the dump(not the screenshot) there's nothing to complain about. It's the battery for sure. The age and maybe the charging cycles are up to 500.
[Android General] L22EEW:
I followed the steps outlined in post #4.

All generally OK, but phone sometime randomly rebooted (numerous times). This morning rebooted phone, and phone would boot for about 10 seconds, then reboot (constant cycle).

Quickly opened amplify, and Reset to defaults - which solved this issue.

I'm aware post #4 was written sometime ago, just wondering if there in an updated version within this 1325 paged thread? :confused:
[Android General] DB126:
Updated version: don't use Amplify or any other tool that artificially mucks with wakelocks and alarms on Android 6+ unless there is a demonstratable, reproducible correlation between some undesirable behavior (eg: excessive battery drain) and a specific alarm/wakelock. Armed with that detail it is usually a simple matter to resolve the issue without screwing with WLs. Well, unless you like random reboots, subtitle side effects or spending hours twiddling settings in an effort to find the illusive and often fragile elixir that works just until the next update.
[Android General] L22EEW:
Fair point, thanks for the feedback.
[Android General] Isley_FR:
So no more amplify on my Moto G 2015 armed with 6.0.1?

I haven't noticed random reboots but sometimes I don't receive calls (people get directed to voicemail as if my phone was turned off), and/or I receive sms and notifications hours after they're sent. I was wondering if it were network issues or something with amplify/greenify.
[Android General] DB126:
Almost certainly a side effect of wakelock blocking/limiting (Amplify).
[Android General] Isley_FR:
Damn... Well I tried resetting amplify's setup and only limit WL and alarms considered safe and probably safe from this sheet : https://docs.google.com/spreadsheet...0gYFBe1K8_R3NBloP4Q1FgpIU/edit#gid=2072742181

I have less items limited/blocked now. I'll see how it goes, if I keep having weirdness I'll remove amplify altogether but I'd rather keep it, I definitely have more battery life with it.
[Android General] Thespartann:
Thanks man!
[Android General] DB126:
Removing Amplify exposes the true sources of drain which can then be addressed directly vs squashing symptoms. If running Android 6.x you already have most of the tools needed to manage any bad actors. Be sure to enable 'doze on the go' in Greenify as Android 6.x did not have that by default (standard in Android 7+).
[Android General] halilb1978:
Many unknown wakelockd,alarms and services. How to decide and what seconds to limit them? Safe limit part empty after did ur options. But too much unknowns :(
[Android General] marcdw:
You didn't specify your ROM or android version but heed these words from the previous page.

http://xdaforums.com/showthread.php?p=76110640

You don't actually mention any issues regarding wakelocks or anything. Only that you have a list of items you want to limit for no stated reasons.

LG G3 D851, PAC-MAN LP ROM, MultiROM, Tapatalk 4.9.5
[Android General] halilb1978:
My phone: Samsung Galaxy A8 Duos ( SM-A800F )

Marshmallow 6.0.1 stock room

Root+Twrp+ Xposed Framework+ Greenify (with Donation Pack) + Amplify (Pro ) + Appoppsxposed

I did almost everthing u posted. Nice result. But on Amplify i have few things to limite from ur post. Mostly unknown.

Btw Amplify waking up Google Play Store from deep hibernation on Greenify.
[Android General] halilb1978:
Here screenshots off Alarms and services
[Android General] halilb1978:
Here 4/7 of wakelocks
[Android General] halilb1978:
Last 3/7 wakelocks.

None in ur post. But what will we do with theses. Which ones to block and what second to limit?? Thanks for ur future helps
[Android General] halilb1978:
As u can see, after limiting some nothing going into Safe To Limit part. All stay in Unknown part. So????
[Android General] DB126:
So...walk away. Your device (and likely your time manager) with thank you for the wise decision.
[Android General] halilb1978:
So i should not limit any unknowns?? Btw i am searching for answere to learn which can be limited safely.
[Android General] strongst:
No. As [MENTION=5488402]Davey126[/MENTION] said: don't waste time on things that maybe drain the battery by 0.001%. you won't be able to recognize it. It's just that fact you've blocked something and you feel good, but benefits are minor compared to the time you wasted to figure it out or not.

That's also my recommendation to everybody: until you find a real drainer, don't waste time for minor ones, live your live, have fun with your device. Wakelocks are imo perfectly handled by Android 7+ and most apps are updated to benefit from that system changes. If the app isn't, uninstall it and find an alternative. We have Android, not IOS, there are enough :o

Regards :cool:
[Android General] DB126:
Walk away from alarm/wakelock limiting. See previous posts.
[Android General] initguru:
Hi guys,

Thanks for this great information thread, I have suffered from deep sleep issue and got some clue in thie thread.

I believe that Android Oreo have well optimized battery management so I wouldn't do much tweaks.

I have used Greenify and ForceDoze to put some misbehaving apps into Doze, and blocked some wakelocks caused by specific apps by rom-builtin wakelock blocker.

Device: OnePlus 3T

ROM: Nitrogen OS 04/15 build

Kernel: Mady's Extended X12 with Magisk 16.0

Tools: Greenify, ForceDoze, ROM Builtin Wakelock Blocker

In AppOps, I have disabled 'keep awake' of Google Play Service and Google Framework.

Here I'm attaching full bbs stats of 6 hours idle overnight.

I would like to do more optimization to have better deep sleep, any helps would be very appreciated.

Is there anything I can do more?
[Android General] strongst:
[MENTION=5019006]initguru[/MENTION] the stats are very good! The only alarms that should be investigated cause they are the highest in the dump file are:

com.skhynix.client (): Wakeups: 45 (7.3 / h)

Alarms: 45, Intent: com.skhynix.client/com.baidu.android.pushservice.PushService

com.xiaomi.hm.health (): Wakeups: 43 (7.0 / h)

Alarms: 6, Intent: com.xiaomi.hm.health.WAKE_UP

Alarms: 37, Intent: com.xiaomi.hm.health/.device.service.HMCoreService

com.kakao.talk (): Wakeups: 40 (6.5 / h)

Alarms: 40, Intent: com.kakao.talk/.service.MessengerService

But again: the stats are very good and nothing to complain about! 1% within 5h20min :good:
[Android General] initguru:
Thanks for the reply.

I will disable those apps and test overnight drain again.

btw 6% in about 6 hours (~1%/hr) :)
[Android General] strongst:
Sorry, typo :cool:
[Android General] Mietjelan:
Anyone that can check this? Thanks in advance
[Android General] strongst:
From what we can see is that Facebook causes many alarms. But the main problem is the very bad mobile signal

No or Unknown Signal (): 6 h 17 s 84,2%

Which leads to a higher drain compared to good signal.
[Android General] Mietjelan:
Could it be because I greenified facebook?
[Android General] DB126:
Has nothing to do with Facebook (greenified or not) and everything to do with your phone searching for service for 6+ hours.
[Android General] Mietjelan:
I was talking about the facebook alarms :/
[Android General] DB126:
So was I. Facebook alarms (generically, any/all Android alarms) are not evil in isolation. How an app or device responds to alarms/wakelocks/etc determines if a desirable/undesirable event occurs. Hibernating Facebook should mitigate any significant activity/draining events associated with the app. As such the alarm count carries little interest beyond being a statically anomaly.

The Facebook alarm discussion is a distraction. 800 lb gorilla in the room is the lack of a usable network signal for 85% of the monitoring window. If that condition persists (ie: moving to a different location makes no difference) placing the device in airplane/flight mode or leaving on a charger is probably the best response.
[Android General] Mietjelan:
Okay thanks, usually it's on a charger at night but i wanted to test deep sleep
[Android General] butla:
I think the sarcasm was a little lost in this instance, made me smirk though, thanks.
[Android General] Mietjelan:
It blocked some wakelocks and tried again, is this better? I believe i do have a good signal now.
[Android General] DB126:
"Better" is a personal judgement in the eyes of the beholder. On one hand your device drained at an average rate of 1.2%/hr which is elevated but not horrible. On the other hand device was awake for nearly 20% of the monitoring window. Ideally that should be 5% or less.

Log shows you have a noxious cocktail of 'power management' tools installed including Greenify, PowerNap and Amplify (ugh!). Totally unnecessary on Oreo and likely a contributor to extended wake time. First step in your recovery plan should be to uninstall the last two. Greenify can still be beneficial on Android 7+ when selectively used (ie: not everything) and generally does not introduce negative side effects.

tl;dr - over management is your worst enemy; let Android take care of itself.
[Android General] Mietjelan:
Okay, I will try that, thanks! Should I use any modules in magisk? Like doze for play services?
[Android General] DB126:
Why would you do that unless there is a specific "problem" to solve? It would seem the default position is Android power management is fatally flawed and needs the assistance of weekend warriors to rein in its errant behavior. No doubt there are many who tilt to that windmill. While additional actions are required in some specialized situations Android does a pretty good job balancing the needs of all masters. Including the much maligned Google Et al. Because we all need villains to rail against. :rolleyes:
[Android General] Mietjelan:
Okay so i did it again, no amplify, no powernap, not a single wakelock blocked, not a single alarm blocked.
[Android General] DB126:
Screen-off wake time was reduced to 35 min (~7%) reflecting a 60% reduction from the last run with all the of the power management toys running. Device idled at the lowest CPU frequency for over 492 min of the 495 min monitoring window. Pretty much an ideal performance. No issues with signal quality. Yet the battery level dropped 13% (!!). This is likely due to a kernel and/or custom ROM that has not been optimized for your hardware. A 'stuck' sensor can also cause this or one that is not put into a low power state by the kernel. A final suspect is the battery but this seems unlikely given age of device and steady voltage.

My advise? Go back to stock on your G5+ or at least a Nougat ROM variant that utilizes the stock kernel. Toss in Xposed framework and a few modules for UX flexibility. Moto devices are generally very thrifty on stock. Most of the custom ROMs spun up by weekend warriors (especially Oreo based) are generic builds with little consideration for your specific hardware.

Finally, read through (keyword search!) the thread for your device and ROM (here). There is a fair bit of chatter about battery life. Good luck.
[Android General] Mietjelan:
I didn't know a stuck sensor could cause that, I was having issues with my proximitysensor after installing a new screen, apparently there was some debree on it, i just cleaned it off, will try again overnight.
[Android General] DB126:
I think at this point you're on your own. Issues with Android tunings and your app suite have been ruled out now that Amplify, PowerNap and other (cough) tweeky tools are out of the picture. You can read the high level numbers as well as anyone else. An hourly idle drain rate >1% suggests further action is needed. Ideally that figure should be between 0.5-1.0% depending on device, app suite and environmental conditions (eg: signal strength). Anything less requires extraordinary actions and acceptance of associated side effects or other compromises. I prefer to use my gizmos vs 'manage' them. Good luck.
[Android General] Mietjelan:
I believe it has been fixed after cleaning out the sensor, only 0,5% drain per hour.
[Android General] DB126:
Excellent!

Future readers take note of what happened here which is not uncommon:

- device exhibiting high idle (screen off) battery drain

- faux conclusion alarms/wakelocks were the culprit

- device loaded up with obsolete tools to battle a benign foe

- those supposedly helpful tools increased wake time by 60%

- in the end a misbehaving sensor was the likely cause (not unusual!)

- BBS/GSAM/etc. generally will NOT directly detect this type of drain

tl;dr: alarms and wakelocks are not evil in isolation; tying to limit/block without an understanding of root cause will likely make the problem worse - not better.
[Android General] ninobrtv:
HTC 10 Oreo draining battery

My HTC 10 drain a lot of battery, I made several test but still the same problem. This is an INDIA SEA model (3.18.400.2) with the rom HTC_10_MaximusHD_4.0.0. I always stay at about -3% to -4% per hour.

Here are the stats of bbs with airplane mode enabled without wifi or anything.
[Android General] strongst:
[MENTION=9036941]ninobrtv[/MENTION] can you please attach the bbs dump file or upload it to some hoster to keep the readability of this thread ;) thanks!edit: thanks for shrinking your post :good:

Please, lines 344 and following showing you that there are large amounts of downloads even when the device was in deep sleep all the time :rolleyes: [MENTION=5488402]Davey126[/MENTION] any ideas other than then battery problem?
[Android General] halilb1978:
Anyone can give a list of which google play services can be cut off on greenify without effectting GCM notifications and Google Play Store?? I cut off all in last 2 days. 1 off them ( auth.... name starting so ) causing google play store and google account crushes. But could not find which one is crushing gcm notifications. But cutting off all in google play services stopped all goougle background. :)) there were no working google services :)) or anyway to change google play store. Like amazon. But i dunno what will happen to push notifications. Honesty i dont need google and dont wanna at all. Any advices ?? Like using Amazon. I just need push up notifications work normal and dont wanna backgrounds . I did everthing on this post. All works fine. No more steps ?? How to rescue android from google :))
[Android General] DB126:
Unfortunately I don't have confidence in the BBS data presented; too many inconsistencies:

- only 4-1/4 min of screen-off wake time over a 9-1/2 hour monitoring window (exceptionally low for device config even with all radios off)

- 1.5 GB (!!) of WiFi network traffic recorded across numerous apps with minimal CPU use

Hard to tell what is real. Probably need to cross check with another battery app such as GSAM or the native tool built into Android 8.

---------- Post added at 08:52 PM ---------- Previous post was at 08:45 PM ----------

A fools errand to limit Google Play Services. Many apps depend on background fucntions provided by Google's suite which is why usage appears artificially elevated. Artificial cutoffs only create problems that may or may not be immediately apparent. If you really despise Google consider switching to micro-G which is no cake walk to implement on most devices.
[Android General] ninobrtv:
HTC 10 Oreo draining battery

Thanks [MENTION=5488402]Davey126[/MENTION] and [MENTION=613506]strongst[/MENTION] for your help.

I did the same manipulation under the same conditions (airplane mode).

That's what I get.
[Android General] DB126:
No smoking guns - just steady, unexplained drain. Could be ROM and/or kernel has not been fully optimized for your hardware. Might have to roll back to Nougat which really isn't a bad option all things considered. Don't be lulled into blocking alarms/wakelocks or taking other extreme actions. Those items are not the source of the problem. At least at a level that can be detected/controlled by available tools.

Final thought: Clear all storage from Google Play Services and reboot. Seems an unlikely culprit in this scenario but can't hurt to try. Good luck.
[Android General] ninobrtv:
Htc 10 oreo battery drain

I had the same problem under Nougat. I do not know what to do. Can be a material problem ?
[Android General] DB126:
Material problem? Have no idea what that means. Possible the battery pack is failing or a hardware sensor (in particular fingerprint scanner) is stuck or dirty. Nothing that can be addressed via apps/software/tweeks IMHO.
[Android General] Shark5060:
I think he means "hardware problem" with material... might be a translation issue.
[Android General] DB126:
Thank you; hadn't though of that possibility.
[Android General] Manuel Rodriguez Collado:
@v7

Naptime is an amazing application is from the developer Francisco Franco

Enviado desde mi LG-LS997 mediante Tapatalk
[Android General] Ihe87:
Hi,

i know, i got no bad results but there are many wakelocks on Idlemode (Tasker freaks out :confused:).

I use Helix Engine and Naptime on debloated OOS Rom.

Can anybody advice me what to do?

Thanks in advance.
[Android General] strongst:
I really can't see that Tasker freaks out :rolleyes: the only "high" wakelock is GSam Battery Monitor with little over one minute....

And 0.4% idle drain per hour is excellent! There's really nothing to care about and no need to optimize :good:
[Android General] Ihe87:
Thank you for your quick response. :good:

I meant this one:
[Android General] Ihe87:
Sorry i meant this one.
[Android General] strongst:
I saw that too, but there's no big impact on battery. You have alarms but they are not resulting in massively wakelocks.

You can make the same test and disable Tasker.
[Android General] DB126:
Even an elevated wakelock count would not necessarily demand action unless accompanied by an unfavorable response from the device. Alarms/wakelocks are not evil. Just because you 'see it' (via BBS, GSAM, WLD, etc) does not mean you need to manage it. :)
[Android General] strongst:
Correct, as you mention everytime: enjoy your device, don't dig to deep :good:
[Android General] mrjuniork:
Where is the fun without diggin' deep, right? :)
[Android General] strongst:
The fun stops immediately when you try to improve your battery drain by 0.1% when you have already 0.4%:cool:
[Android General] mrjuniork:
Yap, I can definitely relate to that :)

Have been trying to use Amplify etc., but I've come to the conclusion, that this is just simply not necessary.

After finally letting go Amplify I noticed to big difference, same idle drain and sometimes even less than before. Is just too many attempts for "damage control", whereas there isn't even any damage in the first place!
[Android General] DB126:
Amplify (alarm and wakelock limiting/blocking in general) is perhaps the #1 cause of increased battery drain and/or device instability among 'ignorant' users trying to use associated tools and techniques. Not to mention a huge waste of time and resources turning knobs and dials that should be left alone.

Please don't recoil at the word "ignorant". It is accurate in this context and simply reflects lack of detailed knowledge of the subject matter. It is not a derogatory characterization. Personally I'm ignorant to 99.99+% of the world we live in. My goal before expiring is to hit 99.98%. Not looking good ATM.
[Android General] ninobrtv:
Htc 10 oreo battery drain

[MENTION=5920269]Shark5060[/MENTION] Yes I speak well of "hardware problem" and yes I use a translator.

I did a battery test that ended at 84%, HTC's board changed it if it reaches less than 75%. So I do not want to change the battery unnecessarily.

Many people have a similar problem with the HTC 10 and there is no exact solution.

I tried Naptime version free, the problem is still there but we see a CPU activity during the doze (if I'm not deceive).

Still no ideas ?
[Android General] DB126:
As previously stated this does not appear to be a software problem that can be resolved by turning knobs and dials. If other HTC 10 users are experiencing similar problems you should be posting in the HTC 10 forum and possibly engaging the manufacturer for a resolution. Good luck.

For what it is worth - my money is on a sensor issue - possibly a dirty/stuck finger print scanner. Again, that possibility is something that should be discussed in your device forum where the experience and expertise lies for you specific hardware.
[Android General] hopecore777:
Can i still use greenify in Android oreo? I just read some thread that oreo do not need the greenify. I just want to make sure if that's true. Thanks! :)
[Android General] Ihe87:
You can. But for me Naptime is enough.

I got Idledrain about 0,3 - 0,4%/h.
[Android General] SkaboXD:
[MENTION=9036941]ninobrtv[/MENTION] calibrate your battery it maybe solve problem, if problem still persists change battery
[Android General] DB126:
Greenify is compatible but not usually needed for routine power management on Android 6+. It can help in some specialized situations (taming bad actors).

FWIW - simplify installing Greenify will do nothing. Installing it and then adding every app to the hibernation list is counterproductive and will likely consume more power. Greenify works best when targeting apps that have demonstrated bad behaviors.
[Android General] marcdw:
Running AospExtended 5.4 (4/14 I think) with Hellsgate kernel on a ZTE Axon 7.

Since I was gonna have a long day at work I figured I'd do a sleep test.

No management of any kind.

Phone was powered off and charged to 100%. Started it up and didn't touch it for over ten hours. Woke it up and it was at 90% with 0.8% drain. That's okay I guess but I'm curious about the no data while it was asleep. Is that normal on Oreo?

Haven't done any sleep/drain tests on my Moto running other Oreo ROMs yet due to multibooting and flashing. ?

BBS stats...

https://mega.nz/#!7VZFATTB!UJJGaBar5wMkOo_yEu028KwCE0KtHDk4YnLMHZGHm4o

ZTE Axon 7 A2017U, AospExtended v5.4 ROM, HELLSGATE Kernel, Multiboot, Tapatalk 4.9.3
[Android General] DB126:
Upper end of expected idle drain w/Android 8.x on older hardware. You might be able to shave off a tenth or two with various tweaks; anything more would likely fall into the aggressive category with the expected suite of side effects. I didn't do a deep dive on dump particulars as macros were in the ball park.