yashsingh1/xdaforums huggingface dataset:
[Android General] peterlee928:
so i have a complete noob question. how are you determining whether a wakelock is causing excess battery drain when you read an idle dumplog?

EDIT

to clarify (or perhaps this is a somewhat unrelated question) - say for example that you are looking at an idle dumplog. and there is above average battery drain.

is/are the culprit(s) easy to spot when looking at the idle dumplog?

which sections of the dumplog do you focus on (wakelocks? partial wakelocks? alarms? all of the above?)?

are you mainly looking for the ones that have a high percentage?

again apologize for the noob questions. all in the spirit of learning. happy to be pointed to any existing literature that provides guidance. :)
[Android General] koekoek91:
I was wondering about this too.

I would think one of the things to do this would be temporarily disable an app/service to compare the enabled vs disabled idle drain over a same amount of time.
[Android General] githyanki:
When you see an excess drain, and the idle log is done properly, you look for anything that held the phone awake. I generally ignore things that are less than 1 minute, also have to not pay too much attention to things like android system, and power management, they only indicate that the phone was awake and are usually not the reason why it was.
[Android General] DB126:
No need to apologize. BBS (and similar tools) detail what happened but not why. Nor do they expose meaningful correlations between events or reveal wake time attributable to a specific app/service. The ubiquitous wakelock is frequently maligned as it simply a request along with an associated max value that folks often interpret as actual wake time. The receiver determines what actions, if any, are taken and how long the wakelock is enforced up to the requested value (not entirely accurate but good enough). Alarms, wakelocks and actual wake time are not evil - what happens during that time is what's important. Knitting this all together into a 'drain profile' is not rocket science but does take a bit of experience mainly gained by reviewing logs and observing how my own suite of devices behave under various scenarios. More of an art than science with modest goals (80/20 rule...ideally 95/5); extreme anything generally isn't part of my vocabulary. Being older than dirt with a long career and a few too many sheep skins doesn't hurt either.

Happy you and others are taking an interest. My time with XDA is winding down as life deals a new new set of cards and others take up the mantle in the handful of forums that I frequent. Be around for a bit and look forward to sharing and learning as always.
[Android General] lbinder:
How am I looking? Thanks, Lee
[Android General] peterlee928:
:good: proper dumpfile

i will leave it to the smarter folks to opine on your dumpfile and whether there are any "bad guys" :)
[Android General] githyanki:
Not too bad, but with you running lollipop, you should use xposed and amplify to tame many of those wakelocks. Review the first 4 posts for direction, or be happy with 0.6%/hr drain.
[Android General] sandeeppathak007:
Does this work on Android 7.1.1? As each time it fails to detect the root while other apps works just fine
[Android General] Oswald Boelcke:
What is supposed to work on 7.1.1? What fails to detect root while other apps are working fine?
[Android General] sandeeppathak007:
So I a am using Oneplus 5 and have rooted it I can use greenfy add away and fontfix they all detect root and works fine but when I open amplify I get error that my device is not yet rooted

I am using magisk version 13
[Android General] peterlee928:
you need xposed to run amplify

---------- Post added at 10:21 AM ---------- Previous post was at 10:18 AM ----------

"this"... he is talking about "this"... what is not clear about that? :laugh:
[Android General] Oswald Boelcke:
As @peterlee928 stated, Xposed is required to use Amplify. But Xposed isn't available for Nougat i.e. if you want to use amplify you must "downgrade" to Marshmellow or lower. AdAway doesn't require Xposed, Greenify "only" requires Xposed for some more in-depth capabilities.
[Android General] DB126:
Spot on - but I would opt for updating to Marshmallow (Android 6) vs doing the Amplify dance. That said, the best you'll see on this device is 0.3-0.4%/hr drain (without going to extremes) so 'no action' may be the wisest course of action given no bad actors. Installing/managing Xposed framework and related modules is a somewhat involved process for casual users. Really depends on your passion for controlling device minutiae.
[Android General] :
I have a big problem with kernel wakelocks which I am unable to solve by myself :(.

There are some other wakelocks in the log, but the main culprit is this:

================
Kernel Wakelocks !!! wakeup_sources !!!
================
event0-1531 (): 2 m 51 s Cnt:(c/wc/ec)553/0/0 0.7%
event1-1531 (): 2 m 50 s Cnt:(c/wc/ec)554/0/0 0.7%
event2-1531 (): 2 m 50 s Cnt:(c/wc/ec)736/0/0 0.7%

From my understanding, this is likely a bug in the kernel itself, and a proper solution would be to replace the kernel. The problem is that the phone is kind of rare, which means very limited unofficial support. This is the only Nougat compatible kernel available for it, so I am kind of stuck, unless I downgrade to Marshmallow where I did not have these wakelocks. I actually compile the kernel from source (https://github.com/tomasz1986/kernel_shv-e470s). If possible, I would just like to fix the bug in the source, but unfortunately my programming skills are too low to properly analyze and modify the code.

I have done some research and did in fact find similar issues concerning other devices with similar SOCs (the phone in question has Snapdragon 800). There was a whole thread about OnePlus One concerning such a wakelock issue (https://xdaforums.com/oneplus-one/help/event0-wakelocks-t2957829). In that thread, the proposed final solution was https://xdaforums.com/showpost.php?p=62057630&postcount=115. The thing is that firstly, no such WLAN driver with its configuration file is present in my device, and secondly, the wakelock takes place even with WiFi turned off, so I am not sure whether it is really related to the one described in those threads. It also occurs in airplane mode (as can be seen in the log) so it does not seem to be related to mobile data too.

To sum up, does anyone have any idea where to begin when it comes to fixing such a kernel issue / bug? I would like to properly diagnose the issue first, and then possibly fix it. The kernel maintainer is not very active and does not update the kernel too often so I would prefer to do something myself rather than waiting for him to do something with no guarantees that the issue will actually be fixed as it has been present in the kernel for some time already.
[Android General] lollazzo:
Currently is usefull powernap?
[Android General] DB126:
I don't have an answer to the specific question/concern but will share a few general observations for community benefit:

- average drain rate was 0.1%/hr which is excellent by any measure

- device idled efficiently for 15 min over 7½ hour monitoring window yielding further evidence that screen-off wake time is not always evil nor synomous with excess battery drain

- Android 6.x/7.x based ROMs can return excellent idle performance on older hardware without the use of Xposed, Amplify and other power management tools focused on alarm/wakelock management

- Greenify, MyAndroidTools and similar utilities are still beneficial for dealing with drain sources vs symptoms

I suspect you are focused on these kernel wakelocks on principal vs. any real concern over power efficiency. Best of luck finding an answer!

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

Not really necessary on most devices/ROMs but some folks like it.
[Android General] DEVILOPS 007:
Could someone tell me how to create a dump file please. I saw a tutorial somewhere like leave idle for 6 hours or something. Please help me. Thanks.
[Android General] peterlee928:
search this thread. there are links that have been posted recently.
[Android General] DEVILOPS 007:
I searched it before posting but didn't find anything about how to do it.
[Android General] peterlee928:
i linked a post this week
[Android General] :
That is true although I would like to stress that such a minimal drain is possible only in airplane mode, especially since the cell signal at my house is extremely weak (-100dBm at best, can barely even make a phone call without losing connection). The reported idle drain is also often misleading since the phone will quickly lose another 2-3% in just a few minutes after waking up ;). In addition, I am very conscious about my apps so nothing unneeded is running in background, using CPU cycles, etc. unless I want it to.

I need to mention though that while the phone itself may be a few years old, the two batteries I am using are relatively new. I swap them on a daily basis so they should degrade slower too. Nevertheless, I am personally quite satisfied with the power management in Android 6.x and newer. I still use Greenify's aggressive doze though since I find it conserve more battery when on the go, in a situation where doze would only work in its light mode. Greenify forces deep-doze all the time which does block more background activity.

Yes and no :p. Yes, because even with these wakelocks I do not have any heavy battery drain so I could just ignore them and still be happy with the current performance. However, the wakelocks do in fact prevent the device from sleeping so they definitely have some (minor) impact on the battery life. You are right though that it is rather my personal cling and obsession rather than a serious issue.

What is interesting, however, is this:

==========
CPU States
==========
1.04 GHz (): 3 m 45 s 0.9%
300 MHz (): 11 m 27 s 2.7%
Deep Sleep (): 6 h 45 m 26 s 96.4%

I set the CPU governor to powersave when idle which means that it was supposed to stay at 300 MHz no matter what. Yet, it ran at 1.04 GHz for almost 4 minutes. The 1.04 GHz frequency is actually my input boost frequency which would suggest that something was causing input events despite the fact that the display itself was turned off for all that time :eek:.
[Android General] DB126:
A few quick follow-up thoughts:

Expected behavior after a prolonged period of network isolation induced either via airplane/flight mode or aggressive doze. Often it's a pay-me-now/pay-me-later scenero with total power consumption largely awash over the doze/sleep +5 min interval. I recognize your situation is different with a barely perceptible mobile signal shifting the calculus.

The kernel can do what it wants regardless of which governor is in use. Seen this many times. Often restricting CPU frequencies is counter productive as tasks take longer to complete. Really depends on your SOC. Such measures can also obsecure CPU spikes that can be indicators of a larger/new problem. Obviously apps can simulate input events; one would hope that isn't the case given your carefully currated suite. That said, I wouldn't put it past Google's incessant background reporting tools.
[Android General] :
I find such a frequency restriction useful particularly for phone calls, or any voice calls in general. The difference in battery drain after a long Skype conversation is especially noticeable, i.e. it is much lower when the CPU is restricted to the lowest frequency. From my experience Skype tends to unnecessarily drain the CPU even though there is no noticeable drop in voice quality or lag when restricted to the lower frequencies. The phone also does not heat up which does make a huge difference when hold to ear for longer periods of time :). This point also applies to normal phone calls, although to a lesser extent.
[Android General] DB126:
Governor tunings can address that on most devices but your approach is cleaner if it carries no undesirable side-effects. Fits my 80/20 (ideally 95/5) Garfield rule. Also agree Skype is a pig but undeniably good and universally accepted. No reason for Microsoft to pursue optimizations until they loose significant market share (hey - always best not to be proactive or learn from past mistakes). :)
[Android General] îĞhøşť:
What are the apps need to whitelist in power nap?
[Android General] DB126:
Only you can answer that. Better yet, skip PowerNap and see how device responds without it. Generally makes little to no difference in real-world battery life.
[Android General] maybeme2:
Hate to see you go, Davey126. Your wise and knowledgeable comments will be sorely missed.
[Android General] peterlee928:
to quote a wise man - "just when i thought i was out... they pull me back in again!" thats right davey126 - gonna pull you back in! ?
[Android General] maybeme2:
Hope so. Davey126 combines expertise with the rare quality of simple (but rare) common sense.
[Android General] cristixperia:
Can you take a look at my log? :p
[Android General] peterlee928:
your battery lost 0.0% during an ~8.5 hour period. safe to say no changes necessary. :good:
[Android General] DB126:
Well done. More evidence that exceptional idle performance can be realized on Android 6.x based ROMs without the use of Amplify or other overt alarm/wakelock management. Noticed you opted for ForceDoze for quieting motion sensors and placing the device into doze more quickly which are primary power management short comings in Marshmallow (addressed in Nougat).

That said, 0.0% drain over 8½ hour is a bit misleading. Power was obviously consumed maintaining radios, sensors, memory, etc. Not to mention the 4+ min of screen-off wake time which included modest network activity and a few CPU spikes. A 1% drop in the reported battery level (which likely happened shortly after device woke) would have yielded an average hourly drop of 0.1%; a 2% drop pushes that toward 0.25%. There in lies the rub. Batteries don't always exhibit linear drain rates under constant load. After the device exits doze (especially the "aggressive" varient) there is usually a flurry of intense 'catch-up' activity that can quickly pull the battery down 1-2% or more which is not reflected in BBS 'screen off -> screen on' stats. That loss can offset much of the savings realized during aggressive doze. Finally, battery levels are not reported real time but are sampled at intervals ranging from a few seconds to a minute or more. Sampling/reporting can also be impacted (delayed) by aggressive doze.

None of this takes away from the nice results that you obtained. But it does highlight the challenges (and sometimes silliness) of explaining/managing small differences in reported drain rate.

tl;dr - too many uncontrolled variables and insufficient reporting granularity to accurately identify distinctions or draw meaningful conclusions at lower drain rates (0.5% per hour or less).
[Android General] Chlorophyll:
Kindly check my logcat and please verify reason for battery drainage

Thank youhttp://cloud.tapatalk.com/s/59661b5c214d7/logcat-2017-07-12_181137757.txt
[Android General] peterlee928:
you will need to submit an idle dumpfile per the instructions in the link below:

https://xdaforums.com/android/general/guide-extreme-battery-life-t3095884/post72734867
[Android General] cristixperia:
After few seconds battery level drop from 74% to 73%, so I can say that I've lost 1 % in over 8 hours.;)

I gave up at greenify cause my battery drain faster when greenify is installed (I don't know why :confused: )
[Android General] DB126:
More interesting is where battery level is 2 min after waking which encompasses more of the sleep->wake->sync (loosely defined) cycle. Those using aggressive doze often see a more pronounced drop immediately after waking the device as the system and various apps 'catch-up'. Normal doze would allow some of this processing to take place during maintenance windows. Boils down to how you want to eat your pie: in little bites over time or a big stuff at the end.

I have heard that before but have yet to see compelling evidence. Others claim ForceDoze drains more. See previous comment for possible explanation. Regardless, it is nice to have choices. :)
[Android General] ProudRed:
Is it possible to control these alarms ? Losing a lot during idle time. Its like 1% in every 1 hour when used frequently
[Android General] :
The first three are related to (light) Doze. You can reduce them by activating deep Doze forcefully (e.g. with Greenify's Aggressive Doze) although the question still remains whether they are actually responsible for the battery drain.
[Android General] ProudRed:
Aggressive doze stays enabled Plus using Force doze.. If I keep my device idle for 6 hours I lose a max of 2% if I am using it every hour I lose %
[Android General] :
Xposed has just been ported to Nougat.

https://github.com/abforce/xposed_art_n

This is a module so it is not something that you can just install but it rather has to be added directly to the Android's source before compilation. If you are a ROM developer or know someone developing ROMs then this is definitely something worth trying though.
[Android General] DB126:
Another (different) update: https://www.xda-developers.com/xposed-android-nougat-support/
[Android General] peterlee928:
see rovo89s comment in the linked thread:

https://github.com/rovo89/Xposed/issues/230#issuecomment-315959127
[Android General] aggro600:
What was wrong with my nexus 7 battery over night? I use No Wakelock and Amplify.

https://www.dropbox.com/sh/hs3q5exkvz9rnm0/AABNUHnBz8RePm9OJhQWmpafa?dl=0

---------- Post added at 10:24 AM ---------- Previous post was at 10:23 AM ----------

What was wrong with my nexus 7 battery over night? I use No Wakelock and Amplify.

https://www.dropbox.com/sh/hs3q5exkvz9rnm0/AABNUHnBz8RePm9OJhQWmpafa?dl=0
[Android General] Oswald Boelcke:
Don't know (yet) if there's something wrong with your device but there's definitely a lot wrong with your log.

I strongly recommend to read the OP including post #6, and to provide a log accordingly.

Alternatively, or probably even better, use this procedure provided by @Davey126.
[Android General] :
Two different threads with flashable zip files have already been created in the Xposed forum. Regardless of the controversies, I have actually installed the files and surprisingly the framework does seem to work properly. I have not experienced any hickups, force closes or any other bugs whatsoever yet.

I have only checked Greenify and Amplify so cannot really speak for anything else. It seems that Greenify is not able to detect Xposed so the boost mode is not available at all. However, Amplify does work correctly, at least on my phone. I have seen people saying that it only worked for ~1 minute and then stopped, but in my case I have just checked the alarm and wakelock stats after 2 hours and everything has been listed as shown in BetterBatteryStats.

There seem to be many different views and opinions on these Xposed builds though. I would still suggest at least trying them out yourself before making any strong arguments for or against them. One thing I would like to stress is that I am using a clean LineageOS 14.1 ROM with no intrusive system modifications except for Magisk with its systemless root.
[Android General] Oswald Boelcke:
For me, flashing and reboot without any problems. I flashed the ARM version but already in TWRP it was indicated as ARM64. Same indication in Xposed installer. However, at that point I discontinued and reverted to my Nandroid backup as I got permanently crashes of the settings - and somehow, I can't live without the ROM settings.

Samsung i9305 with RR v5.8.3.

And it's really crazy what's currently going on in the respective thread. I can't believe how many guys are reporting that the Magisk Xposed module isn't working but the OP clearly stated in the OP and occasionally in the thread that the Magisk module shouldn't be used (yet). Same everywhere: For whatever reasons, so many guys simply refuse to read the OP and to search the thread before they do anything or post and spam a thread.
[Android General] DB126:
Significant caution advised as with any early-alpha. It will be interesting to see if the cautions raised by [MENTION=4419114]rovo89[/MENTION] play out in the real world and how fast they are addressed now that a larger community is involved. I'm betting they will which will likely trigger significant XDA activity in the coming months as various 'gotchas' emerge. While I deeply miss the capabilities Xposed framework enabled on Android 7+ ROMs I am taking a wait-and-see stance for now. The stability of Xposed Framework is greatly under appreciated for those who like to use their devices vs manage them.

---------- Post added at 10:29 AM ---------- Previous post was at 10:22 AM ----------

Direct result of an evolutionary miracle where spontaneous genetic mutations have yielded acute ADHD like symptoms among those who consume all aspects of life in 140 characters or less.
[Android General] Shark5060:
and that's exactly the reason why rovo89 was strictly against releasing WIP content. Because people just DON'T read and then complain that several things don't work as expected. I wouldn't want to be a xposed addon developer right now and being spammed by "not working" requests.
[Android General] Oswald Boelcke:
Wow!!!!:good::D That's great!:good::cool::victory:

I apologise for OT.
[Android General] peterlee928:
https://github.com/rovo89/Xposed/issues/230#issuecomment-316623920

additional feedback from rovo89 if anyone is interested.
[Android General] :
The ROM may be your culprit though. LineageOS is likely more similar to AOSP than ResurrectionRemix with all the customizations added to it ;).

Is this limited to Xposed though? I think the situation has been the same in all development related threads on XDA, especially the popular ones. While I am also not a huge fan of WIP software, it has simply taken too long for people to wait in this particular case. It was only a matter of time until someone forks and tries to update the project. Even if very imperfect, it is still better than nothing.
[Android General] Shark5060:
I personally am not so sure about that. But I wouldn't disagree if someone claims that. The bad part is that some of these releases treat it like it works fine. No big warning and disclaimer etc. Sometimes not even proper credit. Just sickens me.

But well, this discussion might be out of scope for this topic. Nice if it works for some ppl. Especially amplify, since there is no real alternative.
[Android General] DB126:
The nature of Xposed framework produces a shotgun-on-a-marry-go-round set of impacts where a huge community is forced into a respond when untested change is introduced. You already see criticism mounting due to perceived issues with Magisk; no doubt that will quickly expand to module developers who will be accused of dodging their implicit volunteer responsibilities (huh?) by not supporting the handful of Franken-Frameworks that emerge from this effort. To be clear I am NOT against public alpha releases or going out on a limb to help ferret out issues. However, that is not the way the initial roll out has been handled, at least to date. Unbridled turmoil does not always lead to better outcomes.

Time to step away from this discussion and OT posts to this thread. There are no winners/losers; just various islands of thought that different people choose to inhabit (and defend).
[Android General] op3n:
hi guys. i want to stop some wakelocks & alarms in nougat version; exist some alternatives like amplify ?
[Android General] peterlee928:
https://xdaforums.com/showthread.php?t=1179809&p=73152074

EDIT

the 2 apps that are cited in the linked thread above will stop wakelocks and/or alarms.