yashsingh1/xdaforums huggingface dataset:
[Android General] pawwaap:
It was such displayed in Amplify (as gotten many hits).

If disabled in screen sleep only it exerts no visible effect, not positive nor adverse.

Please, any ideas what makes phone awakening for so long while screen is OFF?
[Android General] DB126:
No reason to 'manage' wakelocks that are not responsible

excess

(operative word) drain.

You are working with an obsolete (2011 vintage) device running a custom KitKat build (not to mention kernel). Neither are known for extraordinary power efficiency. Average drain rate on a tired 1700mAh battery is 0.7% per hour with just 26 min of wake time over 28 hours. Give it a break.
[Android General] pawwaap:
And what, it's best in its class (little watertight) on the market. You have admitted it. It works remarkably well, except this idle battery drain. And it also improved, after adding few alarms and wakelocks to ScreenOFF disable list, now it's 0.5%, however it's done blindly. And this is why keep asking you ;)
[Android General] DB126:
Idle drain rate is fine. Wake time is largely irrelevant and unconcerning.
[Android General] pawwaap:
And which wakeup do you mean? In this very phone or in general?
[Android General] Celestial Fury:
Still around but no master still. This was (and still is I believe) the first (and only) thread to aim for 0% [0.0%/h] drain while retaining functionality as much as possible. So, I hope that the spirit of the thread can be maintained with the cut-off point being 0% [0.0%/h] - that is when you reach that then you can stop tweaking, or when the poster is satisfied - whichever comes first.

The reason to start from 100% is for better comparing of other logs when everyone starts their logs from 100%. Of the hundreds of logs posted in battery drain threads you can start to get a sense of what should or should not be. I certainly have noticed that battery discharges aren't exactly linear. Batteries can usually hold their charge longer at the upper levels but in the long run over many hours it should certainly capture more potential draining wakelocks/alarms then if measured at a lower battery level/time.
[Android General] peterlee928:
sorry im a noob masquerading as someone who knows what theyre talking about. so apologize if this is a basic and obvious question... but why should more wakelocks/alarms be captured at 100% than at lower levels? i would think that it would be the opposite, no?

much thanks in advance for whatever insight you can provide. if [MENTION=7408621]noc.jfcbs[/MENTION] and [MENTION=5488402]Davey126[/MENTION] speak highly of you, then im guessing you have the ability to turn water to wine and heal the sick with one touch.
[Android General] DB126:
All else being equal the same suite of alarms/wakelocks/etc will be captured regardless of starting point. What may (and often does) vary is the absolute battery level fall-off per unit of time, especially at low drain rates which tend to amplify the differences. Some devices (battery packs) hang at 100% for an extended period after coming off charge while others fall to 99% almost immediately. This behavior can be observed regardless of when charging actually stopped as indicated by an inline current meter. Both can occur on the same device depending how the charging circuit cycles.

This can lead to artifically high or low calculated average drain rates, especially for relative short duration studies with 'efficient' devices. You see it all the time in posts claiming a doubling/halving of drain rate despite having made no changes to the device. A 'tumble' from 100% to 96% (over 6 hours) is deemed a failure at 0.66%/hr while a subsequent run yields a 'fantastic' outcome at 0.33%/hr if the reported fall off was only 2%. In reality total power consumed was likely quite similar as evidenced by screen off wake time, CPU activity, signal levels, etc.

Starting mid-cycle mitigates but does not eliminate the effect as battery level is reported in whole numbers with no indication of the level within that value. 50.49% and 49.51% will both be reported as 50%. That near 1% difference can have a big influence on perceived rate of idle drain.

There's also some interesting interpretations involved dividing whole numbers yielding fractional quotients that are often carried out to the tenths/hundredths. Recall grade school discussion of significant digits. Hum.

None of the above has anything to do with the linearity of battery discharge at different levels which is a completely different discussion.
[Android General] Celestial Fury:
Did you do Step 2 under Test Idle Battery Drain in Post #3? Otherwise, what was displayed could have been from a previous recharging cycle.

Not 'at' 100% which would mean a total time of zero seconds spent off the charger (which I believe is the confusion?) but capturing the BBS log 'from' 100% till 7 hours later or more.
[Android General] peterlee928:
sorry bad wording by me. that is what i meant. [MENTION=5488402]Davey126[/MENTION]'s post provided excellent color. ?
[Android General] erfan007:
Lose 23% in 7 hours, please check my dump.
[Android General] peterlee928:
check your mx player... was on almost the entire time
[Android General] erfan007:
Yeah it is, thanks

BTW, what mx player do for the entire time, is there a log in it?
[Android General] peterlee928:
easy fix - greenify it. and whenever you stop using the player, make sure you hibernate it. i use the same player (mx pro beta) - that is my process and have never had a wakelock from it.

give that a try. then redo the dumpfile just as you did previously (very nicely done ?). see if that cures things.
[Android General] erfan007:
Cool thanks.

Will send another dump tomorrow ?
[Android General] peterlee928:
no problem.

two additional considerations:

1) qpnp - see second to last post here for potential solution https://www.google.com/amp/s/xdaforums.com/g4/help/qpnpfgmemaccess-wakelock-t3321518/amp/

2) facebook - consider using lite version. or just deleting app altogether and accessing via the web. or just log out of your account after using it.
[Android General] erfan007:
Qpnp isn't block able right now then, well i can disable Facebook when im not using it,,,
[Android General] peterlee928:
its not about blocking it. its about finding a solution to prevent/reduce its occurrence.
[Android General] erfan007:
Oh okay I'll search that thing, thanks
[Android General] DB126:
Seems related to a (motion) sensor glitch on Samsung phones. Make sure fitness and related settings/services are disabled.
[Android General] erfan007:
Greenifyed all of installed apps, and still got 15%+ standby drain.

Please read my dump, thanks
[Android General] peterlee928:
1) rilj - potential solution here https://xdaforums.com/showthread.php?t=1878692

2) bbm - read mixed reviews on this being a battery drain. may consider using an alternative if possible.

3) facebook - consider using facebook lite. or logging out when you are done using the facebook app. or deleting the app altogether and accessing facebook via web browser.

4) qpnp - see second to last post here for potential solution https://www.google.com/amp/s/xdaforums.com/g4/help/qpnpfgmemaccess-wakelock-t3321518/amp/

other potential causes/solutions - https://forums.oneplus.net/threads/qpnp-charger-wakelock.311223/

5) if acceptable to you, try changing/disabling your sync patterns for google services. may also try wiping cache and data for google play services, then restarting your phone. if you have twrp, wipe your cache and dalvik cache there also.
[Android General] Celestial Fury:
Additionally:

These are what you need to limit in Amplify

Alarms: 64, Intent: *job.delay*

Alarms: 98, Intent: *job.deadline*

(What application is this? See if you can click on it in BBS for more details -not the log.)

Alarms: 13, Intent: CONTEXT_MANAGER_ALARM_WAKEUP_69933

(See Post #2 CONTEXT_MANAGER_ALARM_WAKEUP)

Alarms: 76, Intent: com.android.providers.calendar.intent.CalendarProvider2

(See Post #2)

jp.naver.line.android (): Wakeups: 73 (11.6 / h)

Alarms: 27, Intent: jp.naver.line.android.legy.SpdyHeartbeatChecker.sendPing

Alarms: 36, Intent: jp.naver.line.android/.alarm.LineAlarmReceiver

Alarms: 10, Intent: jp.naver.line.android.legy.SpdyHeartbeatChecker.check

(If Greenifying Line doesn't work then limit these. Line WILL be delayed.)

com.mobilityflow.torrent (): Wakeups: 38 (6.0 / h)

Alarms: 38, Intent: io.presage.receivers.BootReceiver.RESTART_SERVICE

(If Greenifying Torrent doesn't work then limit this. Torrent may not work properly.)

These are the major issues, more so than your other apps. Basically, you have lots of stuff needing internet access and syncing and if you really need them then another option will be to FREEZE them (using SD Maid, Titanium Backup, etc.) and only unfreeze when you need them. Otherwise, you'll have to live with the drain but do all the above first then post another log.
[Android General] DB126:
Well that ain't gonna help. Akin to smearing your entire body with hydrocortisone (not recommended!) after noticing a mosquito bite. Not to mention adding unnecessary overhead hibernating numerous apps that likely weren't contributing to the problem and further overhead spinning them back up when reaccessed. Better to use a targeted approach once the culprits have been identified.

On a similar note I'm not a fan of alarm/wakelock limiting as it simply blunts the symptoms vs dealing with root cause. You would also need to install an immature Xposed Framework on Android 7.x to utilize Amplify which is the primary tool used to limit alarms and wakelocks.
[Android General] peterlee928:
oh really? THATS what i was doing wrong when i got bug bites! smh lol.
[Android General] erfan007:
Done 1,2,3 and 5 and still 15% standby drain. I guess i have to change my rom and see what happens.

Thanks

---------- Post added at 08:48 AM ---------- Previous post was at 08:46 AM ----------

indeed all of my apps, need internet access, i use NOS when i use redmi note 3 pro and doesnt face this kind of standby drain, everything is same, just the ROM and the phone that different

---------- Post added at 08:50 AM ---------- Previous post was at 08:48 AM ----------

Does change a rom that includes alarms and wakelocks block/limit help me?
[Android General] Oswald Boelcke:
If ROM and device are different that's already quite a lot! How do you want to compare?

I doubt as I tried it. I'm using Resurrection Remix that includes this features but without influence on drainage.

And I suggest to inhilate @Davey126's wise words:
[Android General] erfan007:
Bbs dump and standy drain is to compare, i think i still got my old device bbs dump.
[Android General] Oswald Boelcke:
Accepted as you can certainly compare the mileage of a Fiat 500 with the one of a Porsche 911. You're going to know one is using less fuel than the other and running farer. But does it support you to figure out the causes of higher fuel consumption? And turning of the alarm (wakelock) that initiates the low fuel light to lit doesn't bring you closer to the cause.
[Android General] peterlee928:
if im not mistaken, you use cyanogenmod.

if this is correct, then i have recently seen a handful of other phones running that mod with some heavy wakelock issues. so you are not alone.

dunno if it is compatible with your phone... but if it is, i recommend biggins rom. when i was using my note phone, that was my go-to rom and battery life was excellent.
[Android General] erfan007:
I use JDC aosp, yes its LOS based.

---------- Post added at 09:41 AM ---------- Previous post was at 09:40 AM ----------

Hehe thats make sense, barely got 6h SoT using this phone, while i can get 7h easily using my old phone lmao
[Android General] :
These are related to light doze in Android Nougat. You cannot limit them with Amplify. They can be reduced if deep doze is forced faster (e.g. with Greenify's Aggressive Doze).
[Android General] DB126:
Clearly something is amiss; blocking alarms and wakelocks is not the answer. If it were app driven Android (doze) should have quieted much of the activity. The dump is a mess with tons of kernel and process wakelocks. Suggest you reset the device, allow it to stabilize and then evaluate idle drain without any apps aside those that come preinstalled. Then add a few apps at a time until the culprit(s) are identified.

---------- Post added at 01:02 PM ---------- Previous post was at 12:33 PM ----------

Yet they pull no power so why manage? There is a reason light doze precedes a deeper slumber. Those who slam their device into a comma with Aggressive Doze typically pay the price with a burst of catch up activity on wake. But that activity doesn't show up on the 'idle scoreboard' so everyone's happy. Until the conversation turns to lag and SOT (cough) which is probably the most imprecise metric ever devised. An excellent analogy can be found here.

To be fair Aggressive Doze has its place but it is misunderstood/misapplied far too often if XDA posts are any guide. On the same note [MENTION=5038522]tomasz86[/MENTION] wasn't recommending its use in this case, simply stating facts which are (of course) accurate.
[Android General] :
That is true although I do believe that Aggressive Doze is quite useful when on the go a lot, e.g. when moving (by car, bike, train, etc.) and having the phone always in your pocket. Without it the device will never enter deep doze in such a situation.
[Android General] Celestial Fury:
Good to know. I'm still on L.

[MENTION=6042715]erfan007[/MENTION]

I can't tell for sure but if they show up in Amplify there's no reason they can't be limited but on the topic of root cause this is a perfect example since you can manage it through the setting in Doze itself. If Doze works the same way as Greenify then it just means that too many apps are dozed. IMO doze's alarms are too high rendering any battery savings questionable. Just as in Greenify, only those apps which cause unnecessary (key word) drain should be dozed.

However, not everything can be fixed by going to the root cause - short of uninstalling and that would be out of the question if you actually need the app. Not all apps have settings that will let you manage their sync/trigger frequency much less core android alarms. That's where Amplify comes in.

Android does not have a way for you to individually measure how much drain individual alarms/wakelocks cause. There is no way for anyone to say for certain whether a certain alarm/wakelock drains or not but on the whole the

rule of thumb

is the higher the count for a particular alarm/wakelock the higher the probability the drain. That's all there is to it.

As to factory resetting, that's the nuke option and a guarantee that everything will be better but how practical is that? Are you going to do that every time? I've always been on stock and never had to try a different ROM/kernel, ROM+kernel combo, etc.

To find the root cause is not to go back to the source but to read the log and it's all there. RILJ usually shows up when your data is on - is it? Is your cellular connection stable? As for qpnp-fg it's to provide interface to clients to read properties related to the battery. Its main function is to retrieve the State of Charge (SOC), a 0-100 percentage representing the amount of charge left in the battery. As to whether the amount kernel wakelocks (as shown in your log) is normal, establish a baseline (Post #3) and compare.
[Android General] erfan007:
I think i wont get such drain in stock rom, which is MIUI, and to be honest i hate MIUI lmao.

Nvm im going to change ROM and see how the drain goes.

My cellular connection isn't stable mostly because i move to different places a lot.
[Android General] DB126:
On my MM devices 'Doze on the go' fixes that behavior. I have yet to experience it on Nougat but don't have a huge base of active motion experience as my primary mobile remains on Android 6 (Xposed dependencies).
[Android General] cristixperia:
1% lost over 6 hours

Only on LTE (signal is really poor):(
[Android General] peterlee928:
0.1%/hr... nice!
[Android General] DB126:
Reinforces superior idle performance can be acheived on Android 6+ without overt alarm/wakelock management. I see similar results on Moto handsets. Careful app selection is key along with BBS (or similar) to monitor background activity. A tool like ForceDoze or Greenify is also benifical on MM based ROMs to enable/maintain doze while the device is in motion. Thanks for sharing.
[Android General] MachoArs:
I ask you to see the screenshots and give advice that you need to turn off for the correct operation of the alarm clock. (The alarm clock will not always be to me, I think it works with a delay)

https://scontent-frt3-2.xx.fbcdn.ne...=8214ace159f2f970a3da8cc30d43e945&oe=5997FD3A

https://scontent-frt3-2.xx.fbcdn.ne...=4d9cd885178adfb183027144fd26a84b&oe=5998020D
[Android General] DB126:
Crosspost: https://xdaforums.com/xposed/modules/mod-nlpunbounce-reduce-nlp-wakelocks-t2853874/post73434461
[Android General] Chocklety Boyee:
Guys can anybody let me know how to block this wakelock plz....
[Android General] DB126:
Err...which one? Regardless, event xx wakelocks typically originate at the kernel do not need to be managed (nor can you block them). Impossible to determine if an actual problem exists without further context. If interested see first half dozen posts for information on generating a BBS idle dump.
[Android General] Chocklety Boyee:
Thanks man..
[Android General] Celestial Fury:
Hello, there. Besides the cross-posting, when I replied to your PM last month, I said:

So sending another PM again isn't really going to speed things up. That said, search Post #2 under DANGEROUS - DO NOT LIMIT / DENY for

alarm clock

.
[Android General] gozzaa:
Help, iam actually having awesome standby time almost (0% drain), but very bad screen on time (25%/h)

Anyone got an idea?

Brightness is on like 15% most of the time. Using Lte only. I switched roms recently and since then I get this drain while screen on
[Android General] akhilkgeorge93:
Which rom are you on ? Try some custom kernels if you want a bit more sot, 1hr = -25% on lte means you getting 4+ sot which is good im also having same sot on RR
[Android General] gozzaa:
Carbon Rom

it's actually not good because my device has a 4000mah battery, iam used to getting sot of like 8-10h.
[Android General] DB126:
- changing ROMs won't help (unless corrupt); different kernel might

- almost certainly a rogue app vs ROM/kernel issue

- use BBS, GSAM or Android's native battery monitor to identify the culprits

- tools like Greenify can tame hungry apps (better yet uninstall it/them!)

- question is off-topic for this thread...and can not be effectively answered (in another thread) without a BBS dump or equivalent performance detail
[Android General] bielie:
I did it (almost). Plus Gov tuner
[Android General] Chocklety Boyee:
How did u tune ur governer??
[Android General] bielie:
Search gov tuner project
[Android General] tudor.raneti:
Is there an Amplify for Gingerbread (Android 2.3.5)? I can't google it up, only required xposed framework for Android 2.3 https://androidforums.com/threads/guide-android-2-3-xposed-framework-modules.778217/
[Android General] Celestial Fury:
So you get 0% [0.0%/h] then? Limiting Google Fit stops it from working?
[Android General] netyang:
I didn't calculate so accurate. I have installed all the apps I need. I use Cold Launcher as my launcher. So I can freeze all other apps which I use it not too often. Then with Amplify, I got 4% battery used a night( about 7 hours) with Wechat and Fongo run. I'm very happy with the result. Because VOIP app (Fongo) and chat app (Wechat) usually use a lot of battery.

With these setttings, it keeps 99% of phone function and save a huge battery. The only app cannot work for me is Google fit. Before I use Google fit, I need to Disable Amplify and reboot the phone. This because Amplify doesn't have temporary disable function. I hope future Amplify version can add this function. That will be perfect.
[Android General] netyang:
what's the "currently not limited" meaning in the settings?
[Android General] aukhan:
[MENTION=5401012]Celestial Fury[/MENTION] did you by any chance notice that the new Google play service has been draining battery quite a but any suggestions or recommendation??

Powered by ET!
[Android General] Celestial Fury:
#305 Last paragraph.

Sure did. #305 First three paragraphs.. Almost every day I'm limiting a new alarm. My recommendation is to find a way to stop these alarms from being created in the first place. No, I don't know how, yet.
[Android General] aukhan:
I had couple of services disable and due to that I saw the play services was under Control and now post update it has increased the awake time, now I've undone for the services disable now it seems better but still I would love to see this play services not eating my battery.

Powered by ET!
[Android General] wxfreak:
Newbie help

I love the idea of using Amplify only to limit battery drain! What can I limit to to trim my drain a little further? Sorry this was not on a 100% charge, Many thanks!
[Android General] Celestial Fury:
There are individual alarms in the top 3 alarms in this attachment. Click on it and screenshot them. Only individual alarms can be limited.
[Android General] wxfreak:
Thanks for the help! The alarm details are attached. What is the best way to determine the number of seconds to set as a limit?
[Android General] Celestial Fury:
Best way is to start with 1 hour / 3600 secs then increase it if you feel it still causes drain as reported in BBS. To keep things simple, I set them at either 2h / 12h / 24h / max.

Limit:

- android.content.syncmanager.SYNC_ALARM

- android.net.wifi.DHCP_RENEW (your WiFi router is renewing the DHCP configuration often enough to cause drain. Find the cause or limit this but be sure to check functionality)

- android.appwidget.action.APPWIDGET_UPDATE (Widgets usually cause drain. Your call.)

- com.google.android.sidekick.shared.a.a.UPDATE_CALE NDAR_ACTION (check calendar alarm functionality - if affected, use an alternative calendar app, Post #2)
[Android General] netyang:
Hi, I use this settings and I get a great results at home(which I always connected to wifi). But when I go out side these weekend, I the settings doesn't work well when there no Wifi connect. I checked the battery chart, the phone waked up a long time when screen off. The phone always keep sleep when screen off at home with Wifi connect.

do you guys have any idea about this?
[Android General] Celestial Fury:
[MENTION=4236789]netyang[/MENTION], yes - see Post #3 on how to test. Doesn't matter if you're home or outside. Need screenshots or ATTACH (not post) the Text Dumpfile.
[Android General] brooker88:
Nice guide, my device is note 2 but I was able to apply most of these to it. Dropped %4 over night which is good to say battery is 3 year old. Only guide that aspears on google, good job:good:
[Android General] Celestial Fury:
I did a Google search for Amplify guide and looks like you're right, [MENTION=5806912]brooker88[/MENTION].

In other news, I used Apps Ops to uncheck everything in Google Play Services but it's random 5 digit ALARM_WAKEUP still keeps recreating itself. Still searching for the exact source of its creation. . .
[Android General] Mudahuda:
Strange, I only have 1 alarm with 5 random digits which worked only once. Maybe try with App Ops "keep awake" off on "Google Play Services" and "Google Services Framework"
[Android General] v7:
0.0% Battery Drain
[Android General] Portgas D. Ace:
No data connection for 8h 17mins... did you enable airplane mode for this time?
[Android General] v7:
No,Mobile Data off.
[Android General] Portgas D. Ace:
Yeah, but try again with mobile data or WiFi on. That's the main purpose of this guide. With mobile data off I get a 0,0% loss for even more than 12h.
[Android General] v7:
I'll try tonight.
[Android General] Pvcabr:
NOUGAT REALLY SUCKS in idle

I already tried everything, wakeblock is the closest app to Amplify but with Nougat I never made idle less than 0,50%/h

This is so annoying >.<

I really miss Amplify

FU*KKKKKKKKKKKKKK
[Android General] profetia:
https://xdaforums.com/xposed/xposed-android-nougat-sdk-25-arm64-t3639221