Database Info

[Q] Low entropy - /dev/random problem

I hope I'm asking this in the right forum ...
My phone: Motorola Cliq, rooted, Eclair ROM "J_r0dd's TheOfficial v1.6."
So the other night I needed to ssh into one of my servers and I wasn't near a computer, so I fired up terminal emulator and got the dreaded:
ssh: Warning: Reading the random source seems to have blocked.
If you experience problems, you probably need to find a better entropy source.
Took a look at /proc/sys/kernel/random/entropy_avail and sure enough it's hovering between about 120 and 190, which is way too low. It ought to be in the 3000 to 4000 range.
So I worked around it by swapping in /dev/urandom for /dev/random and got my server issue resolved, but then I got curious if this was a general problem or if it was specific to the ROM I'm running (J_r0dd's TheOfficial v1.6.)
I tried restoring Blurry Eclair RC3 and also the stock 2.1 ROM and both had the same issue - entropy_avail ranges from about 120 to 190.
I tried switching on Wifi, GPS, playing music, etc. but nothing made a difference.
This is pretty weird since it seems to me there are plenty of handy sources for entropy - phone network activity, wireless activity, app activity, user actions etc.
I'm now curious as to whether this is a problem with my phone hardware, something true of Android on Motorola CLIQ, or true of many other Android devices as well.
There are two issues here which I think are serious:
1) With entropy that low, any app that needs good randomness and uses /dev/random to get it may hang indefinitely.
2) The trick of swapping in urandom will let you go forward, but introduces a serious vulnerability since urandom can be predicted.
Any thoughts and info would be appreciated. Anybody know what hardware input the kernel uses to get entropy? Does your CLIQ (or other phone_ have a similarly small entropy pool as mine?

x-y-no said:
Took a look at /proc/sys/kernel/random/entropy_avail and sure enough it's hovering between about 120 and 190, which is way too low. It ought to be in the 3000 to 4000 range.
So I worked around it by swapping in /dev/urandom for /dev/random and got my server issue resolved, but then I got curious if this was a general problem or if it was specific to the ROM I'm running (J_r0dd's TheOfficial v1.6.)
Click to expand...
Click to collapse
Same problem with Samsung Galaxy S 4G and AOKP/CM9 kernel. Available entropy runs in the 75-200 range.
I agree that symlink-ing /dev/random to be /dev/urandom resolves the symptom, not the problem. With such limited entropy, /dev/urandom would be even weaker cryptographically that it would be on a system with reasonable available entropy.

[APK] Seeder 2.0.0 entropy generator to provide significant lag reduction

Hey everyone,
Version 2.0.0 released!
This version introduces performance tuning, power management control, and an optional MMC I/O queue extension/timing change.
For those of you who have seen reboots / black screens that seem to be caused by Seeder, I suspect it may be due to the power management implemented in previous versions. Disabling power management (by unchecking "Suspend RNG service while screen off") may help. In my testing, battery impact was negligible (less than 2% per 24h).
The performance profiles are Light, Moderate, and Aggressive, and they control how frequently rngd wakes. The default configuration (Light) is unchanged from previous versions. Moderate and Aggressive may impact battery life (slightly), but may also help on devices where the entropy pool is drained quickly and often.
Last but not least, the "Extend I/O queue" option increases the nr_requests on MMC devices to 1024, and increases the dirty page expiry time, allowing more outstanding writes to accumulate. This may allow the I/O scheduler to make better decisions and combine more writes; some users have reported an improvement under heavy I/O.
Feedback appreciated!
---
On some (older) versions of Android, the JVM (and other components) often read random data from the blocking /dev/random device. On newer builds, this problem has been solved, yet depletion of the input entropy pool still seems to slow devices.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
Result? Significant lag reduction (for some people)! :good:
Note - if you want to try it, you must be running a rooted device, and you only need to install one of the APKs (latest version is best). Then, just open it, and turn it on. The other files (patches / .zips) are intended for recompiling, packaging, and init.d integration. If you uninstall the app, either turn off rngd first (open, and click the on/off button), or reboot afterwards; the UI does not presently kill the daemon on uninstallation.
For more information on using the .zip flashing method, see Ryuinferno's post here:
http://forum.xda-developers.com/showpost.php?p=36479461&postcount=1924
FAQ
Q: Do I need the .apk or the .zip?
A: The easiest method is simply installing the latest .apk, attached below. You do not need to use the patch or the .zip file.
Q: What is the patch for?
A: The patch file contains the source differences needed to recompile the Seeder version of the rngd binary. You only need it if you want to recompile rngd yourself.
Q: What is the .zip file for?
A: The .zip file contains the latest rngd binary. It is intended for ROM builders or those who want to build their own CWMR packages.
Q: Seeder keeps shutting down! Does this mean I have to restart it?
A: The Seeder UI is only used to configure and start/stop the RNG service, which runs in the background. The RNG service is not visible from Android, since it is a native Linux process. You can terminate the UI at any time, and the service will continue running.
Q: Does seeder cause excessive battery drain?
A: Seeder 1.2.7 introduced an RNG service power-saving mode. The process automatically suspends whenever the screen is off. The code is actually in the rngd native binary, so suspend/resume events happen independently of the UI; you can see it in action by attaching to the running process with strace. This means that battery drain while the screen is off is highly unlikely.
While the screen is on, the RNG service simply polls a file descriptor every second, and, when needed, injects a small amount of random data into /dev/random (and calls an ioctl). It's unlikely that this would present enough load to trigger a CPU governor state change at 10mhz (let alone 200mhz), so it shouldn't impact battery life. Having said that, I have received sporadic reports that it does reduce battery life on some devices. They may be coincidental (other software installed at the same time), or due to extra device use while testing. Or, they may be real. If you think your battery drain has increased, shoot me a PM!
Q: How can I see the RNG service Linux process?
A: In a terminal, type: ps | grep rngd
Q: How do I uninstall the .apk?
A: Launch Seeder, and stop the RNG service. Then, uninstall the app as you normally would. Alternatively, uninstall the app, and reboot.
Q: Is seeding /dev/random with /dev/urandom safe?
A: Seeding /dev/random with PRNG-derived data does reduce the quality of its random data. However, it's worth noting that nearly all major OSes except Linux do this. Linux is one of the very few to offer a blocking RNG device. And, at least as of ICS, Dalvik doesn't even read /dev/random, so there is little difference anyway.
Updates
There has been a lot of controversy about Seeder/rngd. In newer versions of Dalvik, nothing touches /dev/random, and yet many users (including myself) still notice a lag reduction. There are theories ranging from kernel lock contention to UI polling load when crediting the entropy pool to simply kicking the governor. And many who believe it's all placebo. I'm trying my best to figure out what exactly is happening, and others are as well.
Someone asked how I arrived at the conclusion I did when I started the thread back in November, and I posted this; I think it might be better served here:
A while back one of the webapps I was hosting on Tomcat (server-side) was experiencing some inexplicable latency and while stracing java I saw it frequently hanging on read()'s from /dev/random. I checked the available entropy, and it was constantly under 250 or so. It was a VM, no HWRNG, so I decided to use rngd to push urandom->random.
Dropped session creation times under load from 5-10 seconds to less than a second.
It's worth noting that Linux is one of very few OSes that have a blocking RNG device. Free/OpenBSD, Windows, etc.. essentially only provide urandom. It's generally considered secure, even for long-term crypto keys, so long as the initial seed is big (and random) enough.
Checked on my device, and saw a few processes grabbing /dev/random. /proc/sys/kernel/random/entropy_avail reporting depleted input pool. Figured it was worth a shot, so I rebuilt rngd for arm (with a few patches, linked on first page), and tried it out. It made a significant difference. Posted it up on this thread, and had a lot of positive feedback. Wanted to get into Android development, so figured.. why not wrap a little UI around it. More positive feedback, so I threw it on the market as well.
I had no idea it would take off like this and was shocked when I saw it Thursday morning. I'm in the awkward position now of explaining why it seems to work for some people, and not for others, especially given the fact Dalvik doesn't have references to /dev/random as of ICS. Theories abound, but it looks like it might be an issue of polling the UI for input events when the entropy pool drops (which never happens so long as rngd is running).
I'm doing this as a hobby. I'm a *nix admin by trade, and can only spend time working on this stuff on evenings and weekends, and the last few weeks have been kinda nuts.
I want to stress to everyone that:
a) It doesn't work the way I thought it did on later Android builds, but it does reduce latency for me and many others even on these builds,
b) I'm offering (and always will offer) Seeder for free to everyone on XDA,
c) Like I say in the market description, if anyone has purchased it and it isn't working, PLEASE email me for a refund (and let me know what device you're on if you're willing).
I was one of the first to root the Captivate glide (my first Android phone), and submitted the A2DP bitpool patch; I was active in the n900 community. I hope everyone understands that I'm doing my best here!
I hope the technique proves useful to people, and if there is in fact contention at the kernel level, I hope it's solved so we all benefit.
Version 2.0.0 attached. No changes.
Version 2.0.0b1 attached. New performance profile selector, I/O queue extender, and power saving control. Improved root checking.
Version 1.4.0 attached. Major refactoring. Service control now fully asynchronous.
Version 1.3.1 attached. No changes from 1.3.1-beta.
Version 1.3.1-beta released. New root check method during ANR-sensitive code.
Version 1.3.0 attached. Proper IntentServices for process control, and notification on upgrade / loss of root / autostart failure.
Version 1.2.9 attached. Yet another update to the upgrade/autostart code.
Version 1.2.8 attached. Asynchronous startup of rngd during boot; this should solve the remaining autostart problems some users have reported.
Version 1.2.7 released. This version introduces a much more efficient suspend-on-sleep mode for rngd.
Version 1.2.6 released. This version reverts the suspend-on-sleep rngd change which may have been contributing to new latency. I'm sorting out a better way of implementing it.
Version 1.2.5 released. This version should fix the autostart failure some users have seen.
Version 1.2.4 released. This version implements a progress bar displaying your currently available entropy, as well as automatic rngd restart on upgrade.
Version 1.2 released. This version implements rngd suspend-on-sleep, and contains minor user interface updates, more robust process and superuser checks, and a new icon (thanks Nathanel!)
Version 1.1 released. This version uses the release signature, so you will need to uninstall the old XDA version first!
This version fixes the issue some users were seeing on later Jellybean ROMs, where the UI would misreport the RNG service status.
Caveats
There is a (theoretical) security risk, in that seeding /dev/random with /dev/urandom decreases the quality of the random data. In practice, the odds of this being cryptographically exploited are far lower than the odds of someone attacking the OS itself (a much simpler challenge). It's worth noting that as of ICS, Dalvik uses /dev/urandom exclusively, anyway, and that Linux is one of very few modern operating systems that even offer a blocking RNG device to begin with.
Support for rngd suspend-on-sleep was added to Seeder 1.2. It should no longer impact battery life while the device is asleep.
There has been a large amount of speculation on why/if this actually improves performance on ICS+ devices. I'm continuing to investigate and will post updates to this thread.
If you try it, let me know how it goes.
ROM builders - feel free to integrate this into your ROMs (either the .apk / application, or just the rngd binary called from init.d)!
If anyone's interested, I've launched a paid app on the Play store for non-xda users. As I add features I'll post the new versions here as a thanks to you guys (and xda community at large for being such a great resource). But if anyone's interested in the market's auto-update feature, just thought I'd mention it.
Cheers! :highfive:

This seems absolutely amazing!I think I'll try it out on the weekend, cheers!

Will this work for cwmr 6
Sent from my SGH-I927 using xda app-developers app

Hi,
I would try this, cause I experienced these lags, and they're really annoying, but I'd really need a simple instruction for what to do. You wrote how you managed to discover what to do and stuff, but I'm lost between the lines. Since I'm kind of a newbie, I'm kindly asking you to write some kind of instruction manual step by step, and forgive my ignorance

Laugher19 said:
Will this work for cwmr 6
Click to expand...
Click to collapse
Not yet. If a few people try it and report positive results, I'll make a flashable image. Stay tuned.
soadzoor said:
Hi,
I would try this, cause I experienced these lags, and they're really annoying, but I'd really need a simple instruction for what to do. You wrote how you managed to discover what to do and stuff, but I'm lost between the lines. Since I'm kind of a newbie, I'm kindly asking you to write some kind of instruction manual step by step, and forgive my ignorance
Click to expand...
Click to collapse
I updated the first post with instructions. Please be careful, though! Let me know if you need more detail.

lambgx02 said:
I updated the first post with instructions. Please be careful, though! Let me know if you need more detail.
Click to expand...
Click to collapse
I got troubles. Using Terminal Emulator I got an error message when I type the 3rd line ("cp /mnt/sdcard/rngd /system/xbin"), it says: "sh: cp: not found"

soadzoor said:
I got troubles. Using Terminal Emulator I got an error message when I type the 3rd line ("cp /mnt/sdcard/rngd /system/xbin"), it says: "sh: cp: not found"
Click to expand...
Click to collapse
Where did you transfer rngd to on your phone? Have to make sure the source path matches.

lambgx02 said:
Where did you transfer rngd to on your phone? Have to make sure the source path matches.
Click to expand...
Click to collapse
It does match, that's why I'm confused.. :\ which terminal do you use?

Will test this later, for sure! If all goes well, may I request permissions to include this with the MIUI build I will be learning to make and attempting to produce?
edit: My phone wasnt particularly laggy before except when playing games, but there is a noticeable difference after executing this binary. Noticed a few small hangs but unsure if it is related to this binary.

I've tested it ... integrated it into my rom and installed ... there was no lag even right after it first boot ... its incredibly smooth ... though I too noticed small hangs ... though I attributed this to the device getting ahead of itself ....
Sent from my SGH-I927 using xda premium

Yeah it kind of seems like its fine after settling a bit. Can't wait to see it in 0.7 thegreatergood.
Sent from my SGH-I927 using xda premium

Ok, everyone. I built a very simple Android app that bundles the rngd binary and starts/stops it. Details in first post.

lambgx02 said:
Ok, everyone. I built a very simple Android app that bundles the rngd binary and starts/stops it. Details in first post.
Click to expand...
Click to collapse
wow ... that was quick ... maybe i should look into a custom tweaking app for my rom ...

Zero Computing said:
Will test this later, for sure! If all goes well, may I request permissions to include this with the MIUI build I will be learning to make and attempting to produce?
Click to expand...
Click to collapse
Of course you can!
edit: My phone wasnt particularly laggy before except when playing games, but there is a noticeable difference after executing this binary. Noticed a few small hangs but unsure if it is related to this binary.
Click to expand...
Click to collapse
Yeah, sometimes we really do hit filesystem I/O limits, but at least this should help once everything has been cached.

Ok, autostart on boot is working.

Seems to be a little faster...game still lagging though guess I will give it time
Sent from my SGH-I927 using xda app-developers app

Trying it out. Definitely noticing faster returns to the home screen. I'm using the ICS "only one" build for galaxy note sgh-i717
.
Sent from my SAMSUNG-SGH-I717 using xda app-developers app

OMG! I downloaded via qr code. and OMG! My phone runs sooo much smoother than before!!

This is one of the best mod for glide ever. Things are much smoother and faster to access. ES file explorer, dialer and contact list comes up so fast.
Thanks for this, really appreciate the mod. I'm keeeping it .
Sent from my SGH-I927

Would this work on other devices?

[TEMPORARY HALT][ALPHA][3.4][ZRAM][SDCARDFS]Experimental Nexus 7 kernel build

Code:
*** Disclamer ***
[U][COLOR="red"]NOTE: This is an experimental build with some bleeding edge features enabled.[/COLOR][/U]
I'm not responsible for anything that may happen to
your tablet as a result of installing custom roms and/or kernels.
You do so at your own risk and take the responsibility upon yourself.
CREDITS:
Ziyan , Sheffzor for setting up their Unlegacy Android project, which is the base of this experimental build.
If you can afford to support some of the developers, please donate to them instead of me.
Shout-out to:
AndDiSa, ParrotGeek, daniel_hk, and franciscofranco for their involvement in Nexus 7 kernel/ROM development.
Features:
The same as Unlegacy Android's kernel, with the addition of ZRAM & ZSMALLOC from upstream kernel 3.10 , and with the addition of SDCARDFS.
Installation:
0. MAKE A BACKUP
1. This kernel is compatible with Unleagcy Android's ROM only, and nothing else.
2. If you have the above mentioned ROM installed, boot in to bootloader mode and flash the boot.img with the following fastboot command:
Code:
fastboot flash boot boot.img
3. If you were previously rooted, don't forget to re-apply root to avoid any related boot loops.
4. Altough ZRAM is added as a feature you have to actually set a size to it in Kernel Adiutor (or some other similar kernel manager app)Download#1/Download#2 and tick "Apply on boot" and reboot your device to turn it on.
Or alternatively create an init.d script to enable it with your desired size at boot.
You can verify if your swap/zram device is working by typing "free" or "vmstat" into a terminal emulator.
If the size of the swap device is anything but 0, it will work.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Zram is set to LZ4 compression and 4 streams by default, swappiness is set to 50.
5. [Optional] SDCARDFS is enabled by default , you can verify that its working by typing the following commands into a terminal emulator:
Code:
su
df -t sdcardfs
If some lines shows up like on the picture below then SDCARDFS works just fine.
6. Various ramdisk scripts like re-mounting the drives and trimming are currently not added, to avoid any bug reports related to these additions. You can still use SSD Boost or FSTrimmer app to achieve these effects. If this build proves to be stable enough we can look in to adding the scripts to the ramdisk.
7. Have fun
Bugs:
Same as on the base 3.4, for example I rarely encounter a hang/freeze with some graphical glitches, but it's pretty much the same with the unmodified base version.
Due to the lack of a Tilapia device, I was only able test the kernel on a Grouper.
SDCARDFS is highly experimental, it caused some issues on other devices for some users (like space not freeing up after deleting some files), although it works fine for me, you should bear this in mind when you install this kernel.
As mentioned above, you have to either enable swap for zram via an init.d script or via a kernel manager app like Kernel Adiutor.
This is despite the fact that the block device is added to the fstab and swapon_all is added to the init.grouper.rc . Still have to figure out how to get around this, but currently i don't have the time to do so.
Downloads:
Check the downloads tab at the topic title, or
click here for the download link
Sources:
https://github.com/csabaszalonna/android_kernel_nvidia_tegra3
Changelog:
2017.06.26
Initial release
Added and enabled ZRAM & ZSMALLOC from upstream 3.10
Added and enabled SDCARDFS
Enabled F2FS for both Cache & Data
XDA:DevDB Information
[TEMPORARY HALT][ALPHA][3.4][ZRAM][SDCARDFS]Experimental Nexus 7 kernel build, Kernel for the Nexus 7
Contributors
namerke, Ziyan, Sheffzor
Source Code: https://github.com/csabaszalonna/android_kernel_nvidia_tegra3
Kernel Special Features: SDCARDFS, ZRAM, F2FS CACHE/DATA
Version Information
Status: No Longer Updated
Created 2017-06-26
Last Updated 2017-11-10

Reserved

Looking forward to trying future versions of this kernel, but unfortunately on a talapia device it currently never leaves the bootloader screen (Google and the unlocked icon).

Geko45 said:
Looking forward to trying future versions of this kernel, but unfortunately on a talapia device it currently never leaves the bootloader screen (Google and the unlocked icon).
Click to expand...
Click to collapse
Well, as said in the list of bugs, tilapia is not tested at all due to lack of device.
But if you didn't perform a clean install than it can take it's time to get through the bootloader screen, even on grouper. So make sure you wait there for a while.
On clean install I didn't encounter this issue.

Aside from the freezing issue, this is way smoother than stock.
My current config includes
200MB Zram (swappiness 100 - like Andisa's)
CPU quiet policy: runnable (experiment in reducing the freezes)
interactive perameter 'midrange_go_maxspeed_load' reduced to 90 from its default of 95.
Root Killing SystemUI when the screen is off (Again to try to prevent freezing/need for manual reboot)
SSD Boost
Running this command at startup :
Code:
service call SurfaceFlinger 1009 i32 1
(old habit - suggestion of parrotgeek's to speed up rendering of transparency)
Current result: freezing maybe eliminated, time will tell...
Current theory: Freezing may be due to excessive background cpu load, ie. the system trying to do too much at once. SystemUI may have nothing to do with it, but I still have my suspicions.

35hrs uptime with the above config + forced GPU 2D rendering, frequent use, so far so good...

adstraylight said:
35hrs uptime with the above config + forced GPU 2D rendering, frequent use, so far so good...
Click to expand...
Click to collapse
why the force gpu 2d rendering?

abhifx said:
why the force gpu 2d rendering?
Click to expand...
Click to collapse
It was a thought to take some load off of the CPU, bear in mind I'm not a developer, so am working from basic principles, but it did seem to make everything run smoother. Could be wrong though, what do you think?
I should also add that /sys/block/zram0/max_comp_streams is set to 2, I don't remember doing this, but it could have changed when I was playing with bits of the parrotmod script file, and may have some bearing on the situation. In fact I think it was when I was trying to find an alternative to using Kernel Auditor to initiate the zram...
Uptime 58.5 hrs ?

adstraylight said:
It was a thought to take some load off of the CPU, bear in mind I'm not a developer, so am working from basic principles, but it did seem to make everything run smoother. Could be wrong though, what do you think?
I should also add that /sys/block/zram0/max_comp_streams is set to 2, I don't remember doing this, but it could have changed when I was playing with bits of the parrotmod script file, and may have some bearing on the situation. In fact I think it was when I was trying to find an alternative to using Kernel Auditor to initiate the zram...
Uptime 58.5 hrs
Click to expand...
Click to collapse
well 2d gpu acceleration should on by default, However the developers can use software rendering. This setting just overrides software rendering.
just to add that i am also not a developer.

abhifx said:
well 2d gpu acceleration should on by default, However the developers can use software rendering. This setting just overrides software rendering.
just to add that i am also not a developer.
Click to expand...
Click to collapse
Amateurs of the world unite!?
It was something I remembered from trying to optimise MM on grouper that made a lot of difference at points.

So I've stopped killing the systemui, rebooted, and have had 19hrs of uptime since, so I think we can discount that as a cause.

I have to say that the battery life with this configuration is extremely good. Do you think it would be possible to enable some overclocking?
The stability issue seems to be sorted now, and I see there's a commit under evaluation on the UA Gerrit that might consolidate things further, with regards to a possible memory leak. So it's all looking rather good ?

adstraylight said:
I have to say that the battery life with this configuration is extremely good. Do you think it would be possible to enable some overclocking?
The stability issue seems to be sorted now, and I see there's a commit under evaluation on the UA Gerrit that might consolidate things further, with regards to a possible memory leak. So it's all looking rather good
Click to expand...
Click to collapse
you should post your findings on main ulegacy thread too. maybe this will prompt the devs to incorporate these settings.
this thread has been great and i have finally fixed my broken grouper to try these roms and kernel again

abhifx said:
you should post your findings on main ulegacy thread too. maybe this will prompt the devs to incorporate these settings.
this thread has been great and i have finally fixed my broken grouper to try these roms and kernel again
Click to expand...
Click to collapse
My guess is that they're already aware of what's been posted here, how are you finding it?

adstraylight said:
My guess is that they're already aware of what's been posted here, how are you finding it?
Click to expand...
Click to collapse
they are relying more on changes pushed to their gerrit rather than tracking all the thread. so i dont know posting in their thread is also a good idea.. but hey its better than nothing.

@namerke great to see someone build something off of the work the 3.4 guys achieved. This was the sort of thing we hoped for from the beginning and I really am surprised that you're the only one so far, years after the project started, to brave the source code and use it for a project.
Also, does the original kernel not have zram at all, or have you simply updated the current code to upstream? Cheers

I am running @adstraylight suggested tweaks and its running Rock Solid. The only thing I did not do was reformat for F2FS since it wont work by default with Unlegacy. After the initial start the tablet stops having any system ui, force close, or mtp reboot issues. Boot is much faster and functions more like a normal tablet. I would recommend these changes to be incorporated into grouper unlegacy because as of now, running stock unlegacy with updated builds still has freezing, random rebooting and general issues with slowdowns. Honestly I still don't know why F2FS got scrapped for data and cache. I get that they are working on adding support for a lot of devices but it's just not useable in its current form with stock Unlegacy, unless you are okay with systemui freezes and random reboots.

New version is up, please refer to the #1 post for the updated changelog.
adstraylight said:
My current config includes
200MB Zram (swappiness 100 - like Andisa's......
Click to expand...
Click to collapse
Hi @adstraylight , thanks for all the feedback, it's been helpful , really, since i don't have much time to pressure test our device.
New version is including some of your suggestions to the interactive governor + some adjustments to it from Unlegacy-Android gerrit.
Also, @AndDiSa uses 250MB of ZRAM with swappiness of 60 by default , therefore this is the way I have configured the latest version since it seems to work just fine on 3.1 .
Number of ZRAM streams have been reduced to 1, just like @AndDiSa 's config, again , to reduce CPU load.
HTCDreamOn said:
Also, does the original kernel not have zram at all, or have you simply updated the current code to upstream?
Click to expand...
Click to collapse
Hi @HTCDreamOn , to be honest i didn't even really checked the capabilities of the base 3.4 regarding ZRAM.
I followed a simple logic when I decided to go with the 3.10 upstream version: it proved itself fast and reliable on my Nexus 5, and also since it's from the upstream, it's more recent
All these said, I suspect that the base is lacking some files to enable ZRAM by default but I'm not sure since as I mentioned I didn't really checked the base source regarding ZRAM.
chosin137 said:
The only thing I did not do was reformat for F2FS since it wont work by default with Unlegacy.
Click to expand...
Click to collapse
@chosin137 , thanks for the feedback. As it turns out, based on my experience F2FS on cache causes some instabilities on this version too, therefore I have removed the option to use in in fstab.grouper on the updated version.
Also, this way it will be closer to the base , which can help with merging if @Ziyan and @sheffzor decides to go that way.
Thank you all for the feedback, happy testing

Hi @HTCDreamOn , to be honest i didn't even really checked the capabilities of the base 3.4 regarding ZRAM.
I followed a simple logic when I decided to go with the 3.10 upstream version: it proved itself fast and reliable on my Nexus 5, and also since it's from the upstream, it's more recent
All these said, I suspect that the base is lacking some files to enable ZRAM by default but I'm not sure since as I mentioned I didn't really checked the base source regarding ZRAM.
Click to expand...
Click to collapse
Makes sense, I've seen a lot of kernels using zram and similar from 3.10. That could be it, it doesn't look like zram is enabled at all in the default kernel but I find it odd that it would be missing the files. I only just flashed the recent version of the ROM a few days ago so it's running fine on the stock kernel, will give yours a go once I've bogged it down with some more apps though.

sadly my experience is on the negative side as i can easily completely freeze my tablet. only reboot is the solution. i guess i have seen this issue more in the stock 3.4x kernel too so i guess its more of a rom / memory leakage issue. However the tab does feels smother than other 3.1x kernel based rom. so the tweaks does seem to help more. i might try flat rom+kernel for while, if things are better then i can blame gapps and remove it altogether (although i do want maps for navigation purpose)

Essential Tweaks

Hey everyone! Hope you're all doing fine. I just updated to Android 10, coming from AICP Pie, and I noticed that battery life took a serious hit compared to AICP. Now I know that AICP (and probably many other custom ROMs) use EAS by default, which could be credited for the great performance and battery life you get with these setups. This didn't stop me from conducting some tests and experimenting with some changes in order to try and improve the battery life I am getting on Android 10 (and possibly all previous versions of the stock ROM). Anyway, without further ado, here is a script that tweaks the phone a little, which should improve your phone's battery life on STOCK ROMs, mainly Android 10 but it is also applicable to Android 9, though I have mainly tested it on Android 10 and the deprecated developer previews and beta builds of Android 10. A link to download the script is provided down below, right below the prerequisites and instructions.
Prerequisites
1- An Essential PH-1 (of course!)
2- Magisk (make sure to have the latest version installed)
3- A terminal emulator app -- I use this one here:
https://play.google.com/store/apps/details?id=jackpal.androidterm
4- Any file manager app.
Instructions
1- Download the script from the link below.
2- For more convenience, move the script you just downloaded to the root of your internal storage (/sdcard) using any file manager if your choice.
3- Open the terminal emulator app.
4- Type "su" (without the quotes) and hit the enter/return key on your keyboard to grant it root access (Magisk could display a pop-up window asking whether you want to grant this app root access. Make sure to tap in Grant. This usually happens once).
5- Afterwards, type "sh /sdcard/essential-tweaks" (without quotes) and hit the enter/return key on your keyboard to execute the script.
6- Voila! You're done!
--> In case you think the script has caused any regressions your are dissatisfied with, simply reboot your phone since this script doesn't automatically get applied on boot.
--> In case you rebooted your phone and wish to re-apply the script, simply follow the same instructions again.
Download
G Drive: https://drive.google.com/file/d/101Z_Co7uVU_h2blanJ88MV8x9PpRcOvg/view?usp=drivesdk
Let me know your thoughts down below. Cheers!

Reserved

Reserved 2

Sounds interesting and I'd like to try it. I don't know if you know this though, but the file on Google Drive is set to "ask permission" to download it.

Tanner1294 said:
Sounds interesting and I'd like to try it. I don't know if you know this though, but the file on Google Drive is set to "ask permission" to download it.
Click to expand...
Click to collapse
Fixed. Sorry for inconvenience. Thanks for letting me know!
#justgoogledrivethings

Mostafa Wael said:
Hey everyone! Hope you're all doing fine. I just updated to Android 10, coming from AICP Pie, and I noticed that battery life took a serious hit compared to AICP. Now I know that AICP (and probably many other custom ROMs) use EAS by default, which could be credited for the great performance and battery life you get with these setups. This didn't stop me from conducting some tests and experimenting with some changes in order to try and improve the battery life I am getting on Android 10 (and possibly all previous versions of the stock ROM). Anyway, without further ado, here is a script that tweaks the phone a little, which should improve your phone's battery life on STOCK ROMs, mainly Android 10 but it is also applicable to Android 9, though I have mainly tested it on Android 10 and the deprecated developer previews and beta builds of Android 10. A link to download the script is provided down below, right below the prerequisites and instructions.
Prerequisites
1- An Essential PH-1 (of course!)
2- Magisk (make sure to have the latest version installed)
3- A terminal emulator app -- I use this one here:
https://play.google.com/store/apps/details?id=jackpal.androidterm
4- Any file manager app.
Instructions
1- Download the script from the link below.
2- For more convenience, move the script you just downloaded to the root of your internal storage (/sdcard) using any file manager if your choice.
3- Open the terminal emulator app.
4- Type "su" (without the quotes) and hit the enter/return key on your keyboard to grant it root access (Magisk could display a pop-up window asking whether you want to grant this app root access. Make sure to tap in Grant. This usually happens once).
5- Afterwards, type "sh /sdcard/essential-tweaks" (without quotes) and hit the enter/return key on your keyboard to execute the script.
6- Voila! You're done!
--> In case you think the script has caused any regressions your are dissatisfied with, simply reboot your phone since this script doesn't automatically get applied on boot.
--> In case you rebooted your phone and wish to re-apply the script, simply follow the same instructions again.
Download
G Drive: https://drive.google.com/file/d/101Z_Co7uVU_h2blanJ88MV8x9PpRcOvg/view?usp=drivesdk
Let me know your thoughts down below. Cheers!
Click to expand...
Click to collapse
Neat...
A kranel tweaker...
In my opinion:
The damn powerhint is probably the worst offender to battery...
Currently, with magisk, I just remove /vendor/etc/powerhint.xml
I am also using kernel touchboost so I can idle down to 300...
If your battery doesn't suck... You can switch back to 518 and 806 for minimum frequencies, disable msm touchboost, and kill the powerhint... And get MUCH closer to where you were with AICP on Pie

rignfool said:
Neat...
A kranel tweaker...
In my opinion:
The damn powerhint is probably the worst offender to battery...
Currently, with magisk, I just remove /vendor/etc/powerhint.xml
I am also using kernel touchboost so I can idle down to 300...
If your battery doesn't suck... You can switch back to 518 and 806 for minimum frequencies, disable msm touchboost, and kill the powerhint... And get MUCH closer to where you were with AICP on Pie
Click to expand...
Click to collapse
Is that similar to disabling perfd?
Because that is what I did (and incidentally what my script does).
Thanks a lot for your suggestion!

Mostafa Wael said:
Is that similar to disabling perfd?
Because that is what I did (and incidentally what my script does).
Thanks a lot for your suggestion!
Click to expand...
Click to collapse
No sir...
The powerhint has something to do with the PowerHals directly...
You'll notice if you watch any frequency monitor that when you touch the screen... It jumps to 1.1Ghz on both big and little ... That's NUTS...
It also will run the processor at 1.9 and 2.5 for 5 seconds on app launch... Also CRAZY and unnecessary
Perfd controls the profiles in /vendor/etc/... I think there's 8 of em...
And like mpdecision before it... It sucks...
On a side:
I've been on Q since beta 2... And have put together a magisk module that cuts frequencies down... 1.8 Max for little and 2.0 for big... Kills perfd... Kills the powerhint by replacing with a 0 byte file... Ups zram to 1 GB... And puts touchboost to 825 and 499...
I just incorporated your scheduler changes and I'll let you know what I come up with...
If you're interested in the module ... I'll share it .. just let me know
Edit: @KuranKaname approves the frequency choices BTW

rignfool said:
No sir...
The powerhint has something to do with the PowerHals directly...
You'll notice if you watch any frequency monitor that when you touch the screen... It jumps to 1.1Ghz on both big and little ... That's NUTS...
It also will run the processor at 1.9 and 2.5 for 5 seconds on app launch... Also CRAZY and unnecessary
Perfd controls the profiles in /vendor/etc/... I think there's 8 of em...
And like mpdecision before it... It sucks...
On a side:
I've been on Q since beta 2... And have put together a magisk module that cuts frequencies down... 1.8 Max for little and 2.0 for big... Kills perfd... Kills the powerhint by replacing with a 0 byte file... Ups zram to 1 GB... And puts touchboost to 825 and 499...
I just incorporated your scheduler changes and I'll let you know what I come up with...
If you're interested in the module ... I'll share it .. just let me know
Edit: @KuranKaname approves the frequency choices BTW
Click to expand...
Click to collapse
Yes I know about the max frequency values. These used to be the default in Kuran's AICP too
Interesting, so you mean to say that this is completely different from perfd? Well, I only disabled perfd and I am not seeing the phone jumping back to 1.1GHz while interacting with the screen or locking on max frequencies while launching apps.
Also, what command are you using to disable perfd on Q? I just found out that the usual "stop perfd" command is not working anymore like it used to on Pie :/
I used EXKM to disable it and it works just fine :good:
Let me know if my sched tweaks bring any further improvements to you. Cheers!
EDIT: these input boost frequency values used to be the ones Sultanxda go for too iirc right?

Mostafa Wael said:
Yes I know about the max frequency values. These used to be the default in Kuran's AICP too
Interesting, so you mean to say that this is completely different from perfd? Well, I only disabled perfd and I am not seeing the phone jumping back to 1.1GHz while interacting with the screen or locking on max frequencies while launching apps.
Also, what command are you using to disable perfd on Q? I just found out that the usual "stop perfd" command is not working anymore like it used to on Pie :/
I used EXKM to disable it and it works just fine :+1:
Let me know if my sched tweaks bring any further improvements to you. Cheers!
Click to expand...
Click to collapse
Interesting ..
stop perfd
getprop|grep perfd yields the service has stopped for me

rignfool said:
Interesting ..
stop perfd
getprop|grep perfd yields the service has stopped for me
Click to expand...
Click to collapse
Weird. I will check again when I am home.
Thanks for chiming in! :highfive:

Mostafa Wael said:
Weird. I will check again when I am home.
Thanks for chiming in! :highfive:
Click to expand...
Click to collapse
Interesting... I just put back the powerhint... While stopping perfd and now it's listening ... I wonder if I came up with that when I had the typo in my script...
Thanks for forcing me to debug...
---------- Post added at 02:30 PM ---------- Previous post was at 02:18 PM ----------
Mostafa Wael said:
Weird. I will check again when I am home.
Thanks for chiming in! :highfive:
Click to expand...
Click to collapse
OHHHH...
Are you using service.d to run your script?
If so... You need
while [ "$(getprop sys.boot_completed)" != 1 ];
do sleep 1;
done
sleep 5
Before... Otherwise init gonna reset your stuff...
And post-fs-data.d is WAAY too early

So I have been doing a lot of tracing and testing some new changes and, well, I think it is very difficult to squeeze any more battery life on stock ROMs. Which means that it is highly unlikely that this script is going to be updated with new additions as this is practically the best we could reach at the moment. However, I will keep digging deep and see if I can come up with any updates.
To put things into perspective, here is a quick comparison with the default stock ROM tunings.
By default, I would get an average active drain of 14%/h per charge cycle, peaking at 16%/h
After applying this script the average active drain rate would drop to around 12-13%/h, peaking at 15%/h.
In other words, there is around 1-2%/h improvement in active drain rate as per my usage.
Idle drain rate is fairly similar though.

Mostafa Wael said:
So I have been doing a lot of tracing and testing some new changes and, well, I think it is very difficult to squeeze any more battery life on stock ROMs. Which means that it is highly unlikely that this script is going to be updated with new additions as this is practically the best we could reach at the moment. However, I will keep digging deep and see if I can come up with any updates.
To put things into perspective, here is a quick comparison with the default stock ROM tunings.
By default, I would get an average active drain of 14%/h per charge cycle, peaking at 16%/h
After applying this script the average active drain rate would drop to around 12-13%/h, peaking at 15%/h.
In other words, there is around 1-2%/h improvement in active drain rate as per my usage.
Idle drain rate is fairly similar though.
Click to expand...
Click to collapse
hello. Thanks for your work. It's nice and works very well.
How I can add this script to autorun?
P.S. Here is screenshots of my battery life after tweaks

@Mostafa Wael Hey mate, do you remember what the experiment was that you wanted to do recently ?
Was meant to help with smoothness and battery on Android 10?

St.Noigel said:
hello. Thanks for your work. It's nice and works very well.
How I can add this script to autorun?
P.S. Here is screenshots of my battery life after tweaks
Click to expand...
Click to collapse
I really don't have any idea, I just run then every time after boot via terminal emulator ?

CamoGeko said:
@Mostafa Wael Hey mate, do you remember what the experiment was that you wanted to do recently ?
Was meant to help with smoothness and battery on Android 10?
Click to expand...
Click to collapse
Well, it was a desperate attempt by me to try and squeeze more juice on Android 10 custom ROMs, not sure it will work out on stock ROM. Basically, I am experimenting with different values for the cpusets and stune settings of each cgroup.
I'm still evaluating whether it has a significant impact or not. So far, it is almost the same...

Mostafa Wael said:
Well, it was a desperate attempt by me to try and squeeze more juice on Android 10 custom ROMs, not sure it will work out on stock ROM. Basically, I am experimenting with different values for the cpusets and stune settings of each cgroup.
I'm still evaluating whether it has a significant impact or not. So far, it is almost the same...
Click to expand...
Click to collapse
If you're running Artemis... You're wasting you're time...
Military Dictator @KuranKaname does not allow for the powerhal to accept adjustments from stune other than what HE deems required ...
You MIGHT be able to adjust scheduler values and have them mean something ...

rignfool said:
If you're running Artemis... You're wasting you're time...
Military Dictator @KuranKaname does not allow for the powerhal to accept adjustments from stune other than what HE deems required ...
You MIGHT be able to adjust scheduler values and have them mean something ...
Click to expand...
Click to collapse
Cpuset and stune values are open (besides the top-app stune boost)

I'm using elementalx kernel on android 10 nov update, and my battery drain in deep sleep is unusually high at 2 - 2.5% per hour.
I'm wondering if this script conflicts with anything with the kernel.
I took a look at the script and it looks like some of the settings I can apply in the kernel manager.

[MOD] [A11-A12/A13, Magisk 23+] PK's Tuning Script v16/v17 [2022-05-26]

A11 & A11 - use v16
A13 - use v16
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
94pksp4v16.sh
Shared with Dropbox
www.dropbox.com
94pksp4v17.sh
Shared with Dropbox
www.dropbox.com

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!
- 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.

ooh interesting! would this play nice with the blackened mod found in this forum?

pwnsicle said:
ooh interesting! would this play nice with the blackened mod found in this forum?
Click to expand...
Click to collapse
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:

I use this Script with fsociety Kernel 1.27 and it works fine.
Thx for it
Gesendet von meinem Pixel 4 XL mit Tapatalk

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

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

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

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

Running great on fsociety!)

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

pwnsicle said:
ooh interesting! would this play nice with the blackened mod found in this forum?
Click to expand...
Click to collapse
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.
xFirefly93 said:
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:
Click to expand...
Click to collapse
See above. Should be fine to run both... might even be best for some users! Let us know if it doesn't work!
MarcoG: said:
I use this Script with fsociety Kernel 1.27 and it works fine.
Thx for it
Gesendet von meinem Pixel 4 XL mit Tapatalk
Click to expand...
Click to collapse
Glad to hear it!
Curiousn00b said:
Welcome to the Pixel 4 XL community. Also coming from the Pixel 2 XL as well, looking forward to testing this out.
Click to expand...
Click to collapse
Thanks. Hope you like it!
2WildFirE said:
I'm on flame using this script and seems to work fine here.
It feels a bit snappier.
Thanks for your work.
Click to expand...
Click to collapse
Glad to hear it - it should...
CyberpodS2 said:
Welcome brother... Nice to see another Taimen dev jump into the pool here!
Click to expand...
Click to collapse
Thanks! Great to see you again, too. Athouth, technically, I'm not a Dev
bl4dy_pt said:
I'm on p4 with kiri, so good so far, let's see how will this improve battery life, thanks
Click to expand...
Click to collapse
Probably won't help much, but I'm working on some improvements for V2 (probably tomorrow or the day after!)
FlatOutRU said:
Running great on fsociety!)
Click to expand...
Click to collapse
Thanks for letting me know!
chopt51 said:
Stock ROM only? Or will it work in pixeldust too.
Click to expand...
Click to collapse
Any ROM!

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...

Any testing with kirisakura's kernel? You said not to mix things

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

tlxxxsracer said:
Any testing with kirisakura's kernel? You said not to mix things
Click to expand...
Click to collapse
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.
woundman said:
I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.
Click to expand...
Click to collapse
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.

woundman said:
I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.
Click to expand...
Click to collapse
AFAIK - only the /data partition is using the "newer" f2fs filesystem on the three latest Pixel line-ups..

xFirefly93 said:
AFAIK - only the /data partition is using the "newer" f2fs filesystem on the three latest Pixel line-ups..
Click to expand...
Click to collapse
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.

Thanks for the mod. How can one confirm if this is actually running?

sharpz811 said:
Thanks for the mod. How can one confirm if this is actually running?
Click to expand...
Click to collapse
Look for the log as in the pic. Then view it with your text viewer. It should say script successful :good: