[CLOSED, 2023-11-25] PK's Tuning Script

Search This thread

pkgnex

Senior Member
Aug 13, 2012
1,018
1,179
Michigan
All,

As of this week, I have moved to the Pixel 8 Pro, and I traded my Pixel 4 XL in to get $200 from Google.

I will therefore no longer be doing any development on this mod, or even checking the thread to answer questions.

If you want to keep this mod around for your future use, please download a copy to your personal cloud storage utility in case the thread gets deleted by the XDA moderators.

I have thoroughly enjoyed creating / maintaining this script for the past 4 years, and interacting with the user community on improving it. You have been the best part of the experience!

Thank you, and best regards, Paul.

.
.
.

A11 & A12 - use v16
A13 - use v17

Hey Coral / Flame Gang!

First off, I'm glad to be here. I just came from Pixel 2 XL after my phone died from hardware issues and I needed to upgrade!

Anyway, here's a script that I put together for my own use, but still develop occasionally; tuned especially for our Coral / Flame devices.

Enjoy!

The Back-Story:
I helped some good guys out with developing the awesome Franco.Kernel tuning parameters "back in the day" (Franco's Dev Team - you can look us up, the great osm0sis still hosts the original file set - but they won't even run on Android Pie or later). What is still applicable to Android 12 is in this file; trimmed and consolidated into a single script, along with some other goodies I've come across since. ;)

Philosophy:
- I don't write untested BS or questionable crap in my scripts. If a given tweak doesn't show an objective improvement in benchmarks or battery life or a subjective improvement in performance that can be turned on or off by running or not running the script in a blind test - it doesn't get added.
- If I do not believe a given tweak is safe to run on everyone's daily driver device, I also won't include it my script, regardless of the benefit.
- This script is biased toward increasing performance - but it takes advantage of battery saving opportunities that don't affect performance.

Notes:
- This script is lean and mean, but it's not rocket science.
- I didn't invent anything here. Feel free to use it (or not), distribute, alter, whatever; to your satisfaction, giving credit for redistribution only to "Franco's Dev Team", and maybe me if you're feeling generous.
- I have verified it works well on my personal Pixel 4 XL, and is compatible with all Android versions, Kernels, and Magisk versions applicable to the device.
- It won't make your phone run any worse, and it should make it feel a bit "snappier", but YMMV.
- Most benchmark scores improve marginally (1% - 4%) on my device with stock or EX kernel. Again, YMMV.
- I do not plan to do heavy maintenance on this, but I will keep it up to date so it at least safely runs on the Pixel 4 / 4 XL as long as I own one. I will post updates with a minimal change log (it's a script, you can read it!). If I stumble across something that helps the community, I'll share it!

Disclaimer:
I can't see how this could possibly cause irreparable harm to any Android device on which it is run.
However, I suppose untested configurations may (rarely) have slow-downs, reboots, or other effects.
REGARDLESS, it is offered as-is with no warranty, and you choose to run this at your own risk.
If you do encounter issues, let me know and stop using the script. I may ask you for further help with debugging.

Requirements:
Root
BusyBox installation (I recommend the Magisk module by osm0sis)
Knowledge of how to execute a linux script and/or where to place it and allow permissions to run on boot

Usage:
Download the linked file to your device
Copy it to /data/adb/service.d
Ensure permissions are correct (0755)
Reboot and wait a three minutes

NOTE: The script will generate a text file called "pksp4_script_result" in the base of your "external storage" directory (/storage/emulated/0). This file will state either "Success!" or "Failure..." indicating if the script completed at the last execution attempt (it will over-write each time the script is run - check the date/time stamp on the file properties) .

Credits:
Franco's Dev Team, esp. osm0sis
Others as noted in the script file header


 
Last edited:

pkgnex

Senior Member
Aug 13, 2012
1,018
1,179
Michigan
Change Log

V17 (use for A13)
- Audited script against A13 to ensure compatibility
- Script timing edits to support successful execution on A13 with Magisk 24 (especially ZRAM)

V16 (use for A11 and A12):
Fixed V15! :oops:
- Delayed and slowed ZRAM change to enhance the reliability of it "taking" on each boot
- Made Adrenoboost and power-efficient work queues contingent on those modules actually existing in the user's kernel
- (Did the same with the wakelock blocker while I was at it)
- Fixed a script typo that was the likely root-cause of V15 not running to completion or outputting "failure" for some users.

V15:
Enabled power-efficient work queues by default (most kernels have this functionality built in)
Enabled GPU Adrenoboost module by default, set to low boost (many kernels have this available, on/low seems preferred for a slight / smooth gaming boost without battery life detriment)
Changed vm.vfs_cache_pressure to 50 (was 200, wrong-direction from 100, I now believe after more testing)
Changed vm.dirty_ratio to 10 (from 20; avoids latency when having to write-out data to disk asynchronously by halving the amount of data needing to be written; this could reduce occasional "hang-up's" you may have experienced on this device regardless of kernel or mod - including stock!)

V14:
Increased ZRAM capacity by 50% to 3 GB
Turned off TCP timestamps to reduce overhead
Adjusted VM settings for having more memory
Added a couple minor VM tweaks
Added a minor kernel scheduler tweak
Minor code clean-up and re-ordering

V12:
Small core schedutil up/down rate limit tweaks, making small cores more responsive to increasing frequency and maintaining higher frequencies a bit longer. This should keep more load on small cores / reduce offloading to big cores unless big core utilization is truly necessary. I noted a little less latency and a little better battery life in my testing.

V11:
REMOVED.

V10:
Welcome to 2021.
Minor update - now bbr2>bbr>westwood (depends on what your kernel offers) for TCP congestion control algorithm. As an aside, I reconfirmed txquelen of 512 is still optimal for modern wifi and lte networks.

V9:
Happy holidays!
Added some TCP and kernel cfs tweaks that reduce device latency.

V8:
Stable, slightly improved Android 11 release.
Minor CFQ tunable tweaks that very slightly improved IO in benchmark testing.
Now blocks a single wakelock: qcom_rx_wakelock (if your personal philosophy is to never block any wakelocks, feel free to comment that line out in the script).
Changed TCP congestion avoidance algorithm to BBR2 (if available in kernel) - else, Westwood; based on network speed testing (BBR2 > Westwood > BBR).

V7:
Removed mount tweaks - they no longer do anything useful
Increased DBR slightly
Modified write-out file to not list time/date (for some reason it was being written twice on R). Just look at the file properties in your file manager to see when it was last written, if needed.
V6 is deprecated: Use V7 for R, V5 for Q

V6:
- Updated for Android 11 B1, verified to run without outputting any errors and is 100% stable.
- Removed one schedutil tweak that is no longer available on A11.
- Reverted kernel entropy settings to stock; tweaked settings were no longer increasing entropy pool.
- Users on A10 may use v6 without any issues, but v5 will still provide very slightly better performance on A10.

V5:
- A minor kernel overhead reduction from scheduler statistics
- Force CFQ as scheduler (just in case non-stock kernel isn't already set that way)
- Two CFQ tweaks, one that eliminated backward seeking penalty (makes no sense on non-rotational storage) and one that my testing showed sped up throughput and in theory should also reduce latency (so a true win-win!).

V4:
- Reverted foreground app schedtune boost, swappiness, vfs_cache_pressure, and dirty_ratio to stock
- Reverted IO scheduler to CFQ
- Removed wakelock blocking - verified no / minimal effect on deep sleep (I got 0.12%/hr idle drain overnight)
(for all of the above, thanks to @Freak07 for the advice / education!)
- Re-verified tx_queue_len (512) and tcp_congestion_control (westwood+) are optimized for WiFi and LTE networks

V3:
- Remove fstrim commands for /data and /cache since device is F2FS and fstrim doesn't apply (thanks to @woundman for pointing this out to me)
- Changed to Deadline scheduler with Franco Dev Team tunables - I just verified still benchmarks better after all these years ;)
- If your kernel does not have Deadline available (e.g. stock kernel), the script will still keep you on Noop, as before.

V2:
- Reduce schedutil downrate limit to increase battery life.
- Block some safe wakelocks to increase battery life.
- Oh yeah, and a magic trick to turn off vm dirty write back timer (it still happens, just memory based and not every 5 seconds), to also increase battery life.

V1:
- Initial Pixel-4/XL release.
 
Last edited:

xFirefly93

Senior Member
Jan 10, 2018
1,423
2,293
Timrå
ooh interesting! would this play nice with the blackened mod found in this forum?

I wouldn't recommend you to mix stuff together because it can introduce values that conflicts with each other to some possible very random extent. Though it's your device - try it out and report back with accurate feedback on how it does perform.

:highfive:
 

pkgnex

Senior Member
Aug 13, 2012
1,018
1,179
Michigan
ooh interesting! would this play nice with the blackened mod found in this forum?

It should. My script runs after BlakenedMod, so you'll get most of xFirefly93's battery savings, with a little bit of the PK snappiness.;)

I wouldn't recommend you to mix stuff together because it can introduce values that conflicts with each other to some possible very random extent. Though it's your device - try it out and report back with accurate feedback on how it does perform.

:highfive:

See above. Should be fine to run both... might even be best for some users! Let us know if it doesn't work!

I use this Script with fsociety Kernel 1.27 and it works fine.

Thx for it

Gesendet von meinem Pixel 4 XL mit Tapatalk

Glad to hear it!

Welcome to the Pixel 4 XL community. Also coming from the Pixel 2 XL as well, looking forward to testing this out.

Thanks. Hope you like it!

I'm on flame using this script and seems to work fine here.
It feels a bit snappier.
Thanks for your work.

Glad to hear it - it should...

Welcome brother... Nice to see another Taimen dev jump into the pool here!

Thanks! Great to see you again, too. Athouth, technically, I'm not a Dev :p

I'm on p4 with kiri, so good so far, let's see how will this improve battery life, thanks :cowboy:

Probably won't help much, but I'm working on some improvements for V2 (probably tomorrow or the day after!)

Running great on fsociety!)

Thanks for letting me know!

Stock ROM only? Or will it work in pixeldust too.

Any ROM!
 
Last edited:

woundman

Senior Member
Feb 11, 2016
122
68
I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.
 
Last edited:
  • Like
Reactions: pkgnex

pkgnex

Senior Member
Aug 13, 2012
1,018
1,179
Michigan
Any testing with kirisakura's kernel? You said not to mix things

It should work on any kernel... I've used on on stock and EX on Pixel 4, but I used it on kirisakura on my previous Pixel 2 XL device. If there are any issues, let me know.

I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.

Thanks for the heads-up. Running the fstrim command doesn't return any errors, so the script is "safe" to use, but if it's not actually doing anything on the device, I'll remove it in a future release.
 

pkgnex

Senior Member
Aug 13, 2012
1,018
1,179
Michigan
AFAIK - only the /data partition is using the "newer" f2fs filesystem on the three latest Pixel line-ups..

Looks like you're right.

That said, I stopped trimming /System to be safe once Android went SAR, and /Cache is sym-linked to another partition anyway. So, I don't think the commands are actually doing anything anymore - at least not anything useful since /cache isn't really used for much on newer Android versions.

I'll be removing the fstrim commands starting with the next version. In the meantime, it's not really hurting anything.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 33
    All,

    As of this week, I have moved to the Pixel 8 Pro, and I traded my Pixel 4 XL in to get $200 from Google.

    I will therefore no longer be doing any development on this mod, or even checking the thread to answer questions.

    If you want to keep this mod around for your future use, please download a copy to your personal cloud storage utility in case the thread gets deleted by the XDA moderators.

    I have thoroughly enjoyed creating / maintaining this script for the past 4 years, and interacting with the user community on improving it. You have been the best part of the experience!

    Thank you, and best regards, Paul.

    .
    .
    .

    A11 & A12 - use v16
    A13 - use v17

    Hey Coral / Flame Gang!

    First off, I'm glad to be here. I just came from Pixel 2 XL after my phone died from hardware issues and I needed to upgrade!

    Anyway, here's a script that I put together for my own use, but still develop occasionally; tuned especially for our Coral / Flame devices.

    Enjoy!

    The Back-Story:
    I helped some good guys out with developing the awesome Franco.Kernel tuning parameters "back in the day" (Franco's Dev Team - you can look us up, the great osm0sis still hosts the original file set - but they won't even run on Android Pie or later). What is still applicable to Android 12 is in this file; trimmed and consolidated into a single script, along with some other goodies I've come across since. ;)

    Philosophy:
    - I don't write untested BS or questionable crap in my scripts. If a given tweak doesn't show an objective improvement in benchmarks or battery life or a subjective improvement in performance that can be turned on or off by running or not running the script in a blind test - it doesn't get added.
    - If I do not believe a given tweak is safe to run on everyone's daily driver device, I also won't include it my script, regardless of the benefit.
    - This script is biased toward increasing performance - but it takes advantage of battery saving opportunities that don't affect performance.

    Notes:
    - This script is lean and mean, but it's not rocket science.
    - I didn't invent anything here. Feel free to use it (or not), distribute, alter, whatever; to your satisfaction, giving credit for redistribution only to "Franco's Dev Team", and maybe me if you're feeling generous.
    - I have verified it works well on my personal Pixel 4 XL, and is compatible with all Android versions, Kernels, and Magisk versions applicable to the device.
    - It won't make your phone run any worse, and it should make it feel a bit "snappier", but YMMV.
    - Most benchmark scores improve marginally (1% - 4%) on my device with stock or EX kernel. Again, YMMV.
    - I do not plan to do heavy maintenance on this, but I will keep it up to date so it at least safely runs on the Pixel 4 / 4 XL as long as I own one. I will post updates with a minimal change log (it's a script, you can read it!). If I stumble across something that helps the community, I'll share it!

    Disclaimer:
    I can't see how this could possibly cause irreparable harm to any Android device on which it is run.
    However, I suppose untested configurations may (rarely) have slow-downs, reboots, or other effects.
    REGARDLESS, it is offered as-is with no warranty, and you choose to run this at your own risk.
    If you do encounter issues, let me know and stop using the script. I may ask you for further help with debugging.

    Requirements:
    Root
    BusyBox installation (I recommend the Magisk module by osm0sis)
    Knowledge of how to execute a linux script and/or where to place it and allow permissions to run on boot

    Usage:
    Download the linked file to your device
    Copy it to /data/adb/service.d
    Ensure permissions are correct (0755)
    Reboot and wait a three minutes

    NOTE: The script will generate a text file called "pksp4_script_result" in the base of your "external storage" directory (/storage/emulated/0). This file will state either "Success!" or "Failure..." indicating if the script completed at the last execution attempt (it will over-write each time the script is run - check the date/time stamp on the file properties) .

    Credits:
    Franco's Dev Team, esp. osm0sis
    Others as noted in the script file header


    9
    New Version - V3

    V3 available in OP, change log in 2nd post.

    Slightly better storage benchmark with Deadline and old Franco Dev Team tunables... probably not noticeable, but faster is faster! :D
    8
    New Version - V2

    A little Sunday night treat!

    V2 available in OP, change log in 2nd post.

    Better battery life as I tune this in for Pixel 4/XL...
    7
    I tried so hard to follow along with you guys crazy tech talk so if you don't mind dumbing all this down to users like me. I'm not a noob to Android but I know nothing about coding and building kernels etc. So my question is that is this mod still safe to use?

    It is "safe" to use - your phone isn't going to overheat, blow-up, stop working, or anything like that!

    Freak07 just pointed out that some things may not be optimized for Pixel 4/XL and the latest kernel we are running - which is understandable since I was using my script from a 2.5-year-old phone as a starting point for development.

    Bottom line... if you're already running a version of my script, you don't need to remove it and reboot your phone, BUT if you haven't started using it yet you might as well wait for V4. I will probably release V4 tomorrow, but in no case later than Friday.
    7
    Hey Freak07,

    Thanks for stopping by and providing thoughts / dropping some knowledge on me! I truly appreciate the discussion.

    I've read the twitter convo you linked, and will do more research on this topic as well - I'm always learning! That said, I'm still not yet sold on CFQ. Here's why:

    I'm not sure how "heavy workloads" were defined in the discussion, but using a reputable storage benchmark that reads 32MB files and writes 2MB ones (both sequentially and randomly), CFQ under-performs Noop in throughput. It always has. Those seem like reasonable phone-sized workloads to me, not the server-size ones I suspect may have been used in testing. Deadline, with the parameters adjusted as I have where the timeouts are cut in half and the batching and write starvation is reduced from the stock Linux setup performs better still. Granted, the differences are very minor, and it's playing at the margins at best; CFQ just has so much more over-head for a non-rotational device. I don't think choosing a different scheduler than CFQ is really undoing much optimization as you imply - and I certainly don't feel that subjectively on any device I've ever used my script on.

    Taking your other questions:

    ZRAM is still active with my script - and even with swappiness set at 5, it is still used substantially. Out of curiosity, have you tried running my script on Taimen or Coral to see how it changes behavior (if at all)? To me, it seems to just favor using physical RAM for immediate / recent tasks - ZRAM still fills up with background stuff. FWIW, I used to try turning ZRAM off, and that worked OK pre-Pixel (Nexus 6, 5, Galay Nexus), but you're right that Pixels seem to need it, so I have abandoned that effort. I reserve the possibility that I may be wrong about the effect of lowering swappiness, but I have not seen any negative effects so far, and it seems to work well with my workloads.

    I agree with you on wakelocks. The three wakelocks I chose to block are (or were), in fact, blocked by default on other kernels I have used (EX, Boype, and Franco, I believe - but not on this device, and perhaps not all of them on any one kernel except Flar2's on Taimen). I have never lost a notification due to any of these (or even a slightly expanded set like xFirefly93 uses) but I may walk one or two of them back with further testing.

    I also agree with you on the foreground schedtune boost - setting it to 5 does exactly what you said, it biases foreground apps to favoring bigger cores, increasing drain when the phone is idle and the screen is on. The benefit I'm shooting for and seem to have realized is a slightly faster response when switching to other apps in recents. The battery effect was minimal on Taimen, but I'm new to Flame/Coral, so we'll see! It may also be the case that app switching on Coral doesn't benefit from this like it seemed to on Taimen, again, I'm new to Coral and just trying things out that helped in the distant past or on my last device.

    Thanks again for the advice.

    :highfive:

    Good morning :)

    thanks for you open-minded answer. I try to give a few more details here.

    I'm not sure how "heavy workloads" were defined in the discussion, but using a reputable storage benchmark that reads 32MB files and writes 2MB ones (both sequentially and randomly), CFQ under-performs Noop in throughput. It always has. Those seem like reasonable phone-sized workloads to me, not the server-size ones I suspect may have been used in testing. Deadline, with the parameters adjusted as I have where the timeouts are cut in half and the batching and write starvation is reduced from the stock Linux setup performs better still. Granted, the differences are very minor, and it's playing at the margins at best; CFQ just has so much more over-head for a non-rotational device.

    I don´t think you should conclude that from the results of one artificial benchmark. That´s basically the same trap the google developer fell in, when he changed to deadline in the dev-preview.

    I don't think choosing a different scheduler than CFQ is really undoing much optimization as you imply - and I certainly don't feel that subjectively on any device I've ever used my script on.

    Isn´t thinking and feeling maybe the wrong tool to approach this topic? Why not looking at the code or the mechanisms google put into play?
    You´re wrong by thinking you just switched to another IO-Scheduler and didn´t undo other optimizations. You probably never triggered any workload with your personal usage or testing, where you felt that the optimizations you removed are gone.

    Google introduced the blkio cgroup during the preview for Android 10. That´s dependant on CONFIG_CFQ_GROUP_IOSCHED=y.
    Line 83 and following:
    https://android.googlesource.com/pl...fs/tags/android-10.0.0_r36/rootdir/init.rc#83
    See the commit here as well:
    https://android.googlesource.com/platform/system/core/+/2b3bf84373665e10d96c6b1680e5e53039505325

    Quite a bit of work was done on this topic over a few months to get it working correctly, if you follow the development.

    After booting successfully, there are specific values set for Pixel 4 devices.
    https://android.googlesource.com/de.../tags/android-10.0.0_r36/init.hardware.rc#590

    They are intended to help with various background work. On the Pixel 4 we have more of those than other devices such as soli, face recognition, uploading photos to cloud and others.

    ZRAM is still active with my script - and even with swappiness set at 5, it is still used substantially. Out of curiosity, have you tried running my script on Taimen or Coral to see how it changes behavior (if at all)? To me, it seems to just favor using physical RAM for immediate / recent tasks - ZRAM still fills up with background stuff. FWIW, I used to try turning ZRAM off, and that worked OK pre-Pixel (Nexus 6, 5, Galay Nexus), but you're right that Pixels seem to need it, so I have abandoned that effort. I reserve the possibility that I may be wrong about the effect of lowering swappiness, but I have not seen any negative effects so far, and it seems to work well with my workloads.

    You´re mistaken about this as well, and I saw that you left ZRAM enabled, that´s why I was talking about swappiness. I didn´t look at your Pixel 2 script until now. The Pixel 2 and Pixel 4 are not comparable in this regard. The Pixel 2 still uses the kernel-low-memory killer, because there´s no backport for the kernel-backend on 4.4 devices (only for 4.9, so Pixel 3 and upwards), that´s required for the userspace low memory killer in conjunction with PSI.
    But if you translate your settings or findings from the Pixel 2 to the Pixel 4 and compare both devices with regards to memory management, that´s just wrong.

    Google increased ZRAM size and changed swappiness to 100 on the Pixel 2, to counter the fact that 4GB RAM just isn´t enough to (semi) reliably keep apps in memory alongside Android 10, combined with the sad development that most popular (social media) apps just start to require more and more RAM over the last 2 years.
    https://android.googlesource.com/de...6f37008f6cd3ecf4724ed1994aaed2f8eef1fd9^!/#F0

    The userspace low memory killer, here´s some documentation works best with swappiness being set to 100 (pixel 4 default) or higher (that´s not in mainline, but you can change it up to 200 in my kernel if you want to (various other OEMs allows this, though 100 is default). Result is that swapping memory and dropping the cache have the same priority when set to 100. When swappiness is set to 5, it will strongly favor dropping the cache and almost never swap memory. The reason why you still see your ZRAM filling up slowly is the userspace lmkd being designed to do exactly this, even though you actively hinder it doing its job.

    Observing that disabling ZRAM on Pixel devices introduces negative effects was the first step :) Now try to understand how favoring swapping memory instead of dropping the cache works with the userspace lmkd!

    I also agree with you on the foreground schedtune boost - setting it to 5 does exactly what you said, it biases foreground apps to favoring bigger cores, increasing drain when the phone is idle and the screen is on. The benefit I'm shooting for and seem to have realized is a slightly faster response when switching to other apps in recents. The battery effect was minimal on Taimen, but I'm new to Flame/Coral, so we'll see! It may also be the case that app switching on Coral doesn't benefit from this like it seemed to on Taimen, again, I'm new to Coral and just trying things out that helped in the distant past or on my last device.

    You didn´t understand were I was coming from. When apps are opening on the Pixel 4, Energy-Aware-Scheduling gets disabled by the powerhal for 5 seconds. There won´t be a difference if foreground schedtune-boost is set to 5 during that time, because everything will be boosted to max (ignoring EAS) during these 5 seconds.
    Like I explained in my last post, you will only bias foreground tasks to the big cluster when the phone is without an interaction hint and there´s absolutely no need to bias towards big cores. (when being idle, watching videos, reading)


    Something I feel that needs to be clarified here as well. I´m not trying to make your work or your script look bad. In fact I´m bad at scripting myself so I admire everybody that is good at this. I´m just trying to provide a different perspective for tweaks that are counterproductive by just looking at the code and mechanisms in play here.
    Try to start looking into the actual mechanisms that are present on the Pixel 4 or in recent android develpment, instead of importing tweaks from other devices or the past that are out there on the internet.
    For example, I know there are a lot of tips or sites out there that advise people to turn of ZRAM or reduce swappiness, because it´s a waste of resources, but they just can´t be applied here. (they are years old as well, remember the times, were smartphones weren´t basically full blown mini computers in our pockets? :) )

    I REALLY appreciate this logic on potentially and unknowingly affecting others' devices... I will definitely consider un-blocking most, or all, wakelocks in my next release. The debugging ability for Dev's hits home, too. It's the reason I don't block any of the kernel-level logging stuff (except iostats ;)) that other script writers do.

    As I recall, there was really only one wakelock that was super-active anyway; I believe it was the qcom_rx_wakelock. I may just revert to blocking that one, or none at all, to make it safer for all users.

    qcom_rx_wakelock may look like worse than it actually is, but it´s not as impactful as it looks in apps like better battery stats. When I removed this wakelock completely in the wlan driver before compiling the kernel, guess what happened? I lost exactly the same amount of battery over a night on all four of my 4.14 devices. That´s why I said it´s a strange case.
    The wlan driver has more than enough ways to acquire a wakelock. If one wakelock is blocked most services/apps will just jump to using another. Or they will try to finish their job when a completely different wakelock is held. But that prolongs the time of other wakelocks. And in the end nothing will be won, except maybe a slight delay in notifications that you will never notice yourself.
    I know I start to repeat myself, but wakelocks should only be blocked in case of hardware or firmware incompatabilites, where the device fails to sleep completely.

    A very interesting read is the following one:
    https://arstechnica.com/gadgets/201...sts-tracks-and-improves-android-battery-life/