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.
Related
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?
Welcome to Z-Kernel's thread!
Features
- Base kernel fully updated to linux-tegra-nv-3.1 (bug fixes & performance improvements)
- Simplified board codes
- Cleaned up Acer specific code
Click to expand...
Click to collapse
Changelog
r2:
- Restarted kernel development (r1's features not implemented yet)
- Base kernel fully updated to linux-tegra-nv-3.1 (bug fixes & performance improvements)
- Simplified board codes
r1:
- CPU OC to 1.6 ghz by default (should be stable)
- GPU OC support up to 700MHz (default is 520 mhz)
- Overclocked LP core from 500 to 620 mhz
- Custom user voltage control for CPU and Core components such as EMC, GPU, and LP (faux123)
- Dynamic FSYNC
- Optimized KSM
- Optimized ZRAM
- Compiled using latest Linaro toolchain with optimized compiler flags
- Optimized SLUB and use SLUB by default instead of SLAB
- Glibc memcpy and memmove
- Deadline improvements for solid state drives
- Proportional Rate Reduction for TCP
- Tegra 3 variant display (faux123)
- Optimized swahb32 byteswap helper
- Asynchronous I/O latency improved through removal of plug in do_io_submit()
- allow use of an I/O controller's native max block size
- Optimized ARM RWSEM algorithm
- timer: optimize apply_slack()
- Optimized crypto algorithms
- Optimized AES and SHA1 routines
- LowMemoryKiller fixes and improvements
- Lock performance governor to all 4 cores
- Many scheduler improvements and optimizations
- updated bcmdhd driver (wifi)
- over 450 changes committed, so the above list isn't complete
Click to expand...
Click to collapse
Complete list of changes can be found in the commit log: https://github.com/Ziyann/android_kernel_acer_t30
I'm not responsible if anything bad happens with your device!
This build has been tested on CM11 only, so if you run into something with other ROMs, report it and I will see what I need to change to cooperate with it.
XDA:DevDB Information
Z-Kernel, Kernel for the Acer Iconia A700 and A510
Contributors
Ziyan
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R2
Stable Release Date: 2014-07-30
Created 2014-09-23
Last Updated 2014-09-23
Nice, if it's working fine, I hope you will also support the A510/A511
Shreps said:
Nice, if it's working fine, I hope you will also support the A510/A511
Click to expand...
Click to collapse
Of course, I'll see what can I do when I get everything (OC, UV, ...) working here waiting for a tester...
it is indeed slow. even when completely debloated plus stripped of "essential" system components that I personally do not use. I will try this right away. will report back within an hour in this post.
@Ziyan
it boots, runs, everything seems standard. not seeing any performance increases though. same ol' 10 to 15 fps is there anything more you wish for me to test with it? I replaced this tab a while ago with galaxy note pro 12.2 so I can't really use it enough to check for random reboots
Sterist said:
@Ziyan
it boots, runs, everything seems standard. not seeing any performance increases though. same ol' 10 to 15 fps is there anything more you wish for me to test with it? I replaced this tab a while ago with galaxy note pro 12.2 so I can't really use it enough to check for random reboots
Click to expand...
Click to collapse
Thanks, that's good, it means I can continue improving it. I need to check the kernel periodically after a big bunch of commits, because if something gets broken, it can be hard to find what causes it if from a thousand things I'll push a new version and changelog later today or tomorrow.
sounds good. quote this post when it's uploaded, it'll send me am email notification and I can get right on it.
Sterist said:
sounds good. quote this post when it's uploaded, it'll send me am email notification and I can get right on it.
Click to expand...
Click to collapse
Here's a new version. Before testing it, please make some benchmarks with the previous version (mainly 3D), because - if everything works as it should -, the GPU is now working at 520 mhz instead of 416. It should also have CPU overclocking and voltage control support, so please install Trickster Mod, or something like that from Play Store to see if it works (screenshots are welcome). If it works (i'd be a bit surprised lol it was too easy), please run some benchmarks again to see if there's a noticeable difference. I've got 12 pages of commits waiting to be merged, so yeah, if something got broken, I better fix it now :silly:
Ziyan said:
Here's a new version. Before testing it, please make some benchmarks with the previous version (mainly 3D), because - if everything works as it should -, the GPU is now working at 520 mhz instead of 416. It should also have CPU overclocking and voltage control support, so please install Trickster Mod, or something like that from Play Store to see if it works (screenshots are welcome). If it works (i'd be a bit surprised lol it was too easy), please run some benchmarks again to see if there's a noticeable difference. I've got 12 pages of commits waiting to be merged, so yeah, if something got broken, I better fix it now :silly:
Click to expand...
Click to collapse
just woke up and leaving for work in 20 minutes. when I get there and settle in (about an hour and 20min from this post) I'll test it
which benchmark though, antutu?
Sterist said:
just woke up and leaving for work in 20 minutes. when I get there and settle in (about an hour and 20min from this post) I'll test it
which benchmark though, antutu?
Click to expand...
Click to collapse
Yeah, antutu will do, just note the invidual points
Ziyan said:
Yeah, antutu will do, just note the invidual points
Click to expand...
Click to collapse
woah woah... I just went to download the second version and the tab was dead from 77% last night, still warm.
there's a wake problem, screen will turn on one time after booting up but only that one time
and a sleep problem, after manually turning the screen off it will not turn back on (and kills battery very quickly!)
Sterist said:
woah woah... I just went to download the second version and the tab was dead from 77% last night, still warm.
there's a wake problem, screen will turn on one time after booting up but only that one time
and a sleep problem, after manually turning the screen off it will not turn back on (and kills battery very quickly!)
Click to expand...
Click to collapse
Thanks for the report, I'll investigate the problem tomorrow (it's 01:30 AM here :silly. If you could take a dmesg (while turning the screen off, then trying to turn it back on), or last_kmsg, that would be great help! If you don't know how, refer to section 2 and 3: http://forum.xda-developers.com/showthread.php?t=1520508
Ziyan said:
Thanks for the report, I'll investigate the problem tomorrow (it's 01:30 AM here :silly. If you could take a dmesg (while turning the screen off, then trying to turn it back on), or last_kmsg, that would be great help! If you don't know how, refer to section 2 and 3: http://forum.xda-developers.com/showthread.php?t=1520508
Click to expand...
Click to collapse
higher score / lower 3D performance is v1
lower score / higher 3D is v0
recent apps cleared and CPU set to 1400 performance and ROW
no app gives OC/UV options with v1
I don't have access to a pc at work so can't run dmesg properly for this, and I'm having trouble reproducing the sleep crash now
this is probably all exactly what you did not want me to say lol
edit: so, I got it to crash again (yay!) but can't get klast to work (read only fs) I tried mounting various directories as RW but honestly I have no idea which to do... and here's dmesg which may or may not contain what you need.
I know it might be a little early to ask but any chance you could implement Frandom?
Sterist said:
(cut)
edit: so, I got it to crash again (yay!) but can't get klast to work (read only fs) I tried mounting various directories as RW but honestly I have no idea which to do... and here's dmesg which may or may not contain what you need.
I know it might be a little early to ask but any chance you could implement Frandom?
Click to expand...
Click to collapse
Thanks for the detailed report, I think I revert Franco's hotplugging driver for now, seems like it's on a rampage. May try again in the future.
As for the last_kmsg, your first command was correct, it's just that it doesn't always get created.
We'll see about Frandom when we get things working nice
Here's a build with the stock hotplugging driver, report back if it still crashes.
Ziyan said:
Thanks for the detailed report, I think I revert Franco's hotplugging driver for now, seems like it's on a rampage. May try again in the future.
As for the last_kmsg, your first command was correct, it's just that it doesn't always get created.
We'll see about Frandom when we get things working nice
Here's a build with the stock hotplugging driver, report back if it still crashes.
Click to expand...
Click to collapse
ok I let it idle for about 30 minutes (that was enough to crash every time I left it alone at work) and so good so far.
still no OC/UV though
edit... idle 2 more hours and no problems
Sterist said:
ok I let it idle for about 30 minutes (that was enough to crash every time I left it alone at work) and so good so far.
still no OC/UV though
edit... idle 2 more hours and no problems
Click to expand...
Click to collapse
Great, let's see if CPU OC/UV works with this one. If it does, don't forget to run a benchmark, as GPU OC didn't work till now
Ziyan said:
Great, let's see if CPU OC/UV works with this one. If it does, don't forget to run a benchmark, as GPU OC didn't work till now
Click to expand...
Click to collapse
still no CPU OC/UV. also, that 52mhz step has never worked on any ROM or kernel I've tried, that may extend battery life
Sterist said:
still no CPU OC/UV. also, that 52mhz step has never worked on any ROM or kernel I've tried, that may extend battery life
Click to expand...
Click to collapse
Ok, it must work now.
About 52 mhz, it's so low that any small background work would ramp up the CPU to hispeed_freq, so in the end, it would shorten battery life. The same thing happens with Galaxy Nexus if we go down to 180 mhz, which is a lot, compared to 52 mhz
I've added about 200 commits since your last try (this is a great daily activity :silly, the kernel is getting to be on pair with a Nexus 7 kernel soon if we get OC/UV and some more extra things working :highfive:
Ziyan said:
Ok, it must work now.
About 52 mhz, it's so low that any small background work would ramp up the CPU to hispeed_freq, so in the end, it would shorten battery life. The same thing happens with Galaxy Nexus if we go down to 180 mhz, which is a lot, compared to 52 mhz
I've added about 200 commits since your last try (this is a great daily activity :silly, the kernel is getting to be on pair with a Nexus 7 kernel soon if we get OC/UV and some more extra things working :highfive:
Click to expand...
Click to collapse
ok so UV menu now loads but doesn't look to work quite right - not usable. this is the menu I was looking for that did not load before
OC still does not work though
about 52 (51 actually) every time it is selected, after I leave the screen and come back 102 becomes the selected minimum automatically, even if lock frequency at 51
need benchmark? and ty ty your time!
Sterist said:
ok so UV menu now loads but doesn't look to work quite right - not usable. this is the menu I was looking for that did not load before
OC still does not work though
about 52 (51 actually) every time it is selected, after I leave the screen and come back 102 becomes the selected minimum automatically, even if lock frequency at 51
need benchmark? and ty ty your time!
Click to expand...
Click to collapse
At least we're making progress :good: try this one, and also try trickster mod (specific and general menu).
Benchmarks are welcome, those 200 commits should improve performance a bit, though I think most of them can only be seen in real usage (low memory killer, zram, ...)
Ziyan said:
At least we're making progress :good: try this one, and also try trickster mod (specific and general menu).
Benchmarks are welcome, those 200 commits should improve performance a bit, though I think most of them can only be seen in real usage (low memory killer, zram, ...)
Click to expand...
Click to collapse
bootloop, won't get past Acer logo
benchmark is from the last kernel
REQUIREMENTS.
MUST BE ROOTED WITH RECOVERY.
HAVE INIT.D SUPPORT for method 1.
HAVE TERMINAL EMULATOR for method 2.
NOTE: This may work for all android devices but is only tested on a LG G3 D851. If it works for you let us know.
So far others have used it on Sony and Samsung devices with great results.
ORIGINAL THREAD HERE
http://forum.xda-developers.com/showthread.php?t=3107282
[mod] increase fps 5/12/2015
GENERAL DISCLAIMER.
XDA and I are NOT responsible if anything wrong happens to your device by using this mod. Always make sure you have a backup ready if needed.
ABOUT THIS MOD.
Here is a very simple mod that I wanted to share. This is what has been labeled in the past as the build property to remove a FPS cap on all android devices. This doesn't actually do that but you will see an increase in frames per second by adjusting the EGL swap interval. Unfortunately, this property has always had big issues with visual artifacts that made it useless to use.
I found it frustrating that we could obtain such a high FPS but plagued with issues. So I spent some time and found a new value. One that could actually work on all android devices. Instead of 1 for stock or 0 for modified. Here is the new value...
debug.egl.swapinterval=-60
A general description...
https://www.khronos.org/registry/egl/sdk/docs/man/html/eglSwapInterval.xhtml
While other negative values may work, -60 brought the most bang for the buck when it came to benchmarks. I am truly excited about finding a way to make it work and although it's just a new value, I would appreciate if you could give me credit if using this property as it is the first time it will actually work the way we want it. This value didn't just fall from the sky. Certainly no need to ask for any permissions.
WAYS TO USE THIS MOD.
I figured many people would at least like to try this out so I made it as easy as possible for newer and more advanced users. The mod is actually really easy to apply. Simply add the property to your build.prop file and reboot or use one of methods below.
METHOD 1.
Use the proper flashable zip to install into init.d so the mod is ready directly after a reboot.
METHOD 2. (recommended)
Use the proper flashable zip to install into /system/xbin and call upon it when needed and disable it when not needed.
INSTALLATION.
Method 1
1. Download https://www.androidfilehost.com/?fid=23991606952603390
2. Flash in recovery.
3. Reboot.
METHOD 2.(recommended)
1. Downloadhttps://www.androidfilehost.com/?fid=23991606952602432
2. Flash in recovery.
3. After you reboot open Terminal Emulator and type the following without the quotes.
4. Type "su" and press the enter key.
5. Type "unlockfps" and press enter. This will activate the property for higher fps.
To deactivate type "lockfps"
NOTE: You may need to toggle your screen off/on to fully activate the mod using method 2.
You will also need to activate the mod again after a reboot. The setting won't survive a reboot with method 2.
UNINSTALL
METHOD 1.
Version 1.1
https://www.androidfilehost.com/?fid=23991606952603391
METHOD 2.
https://www.androidfilehost.com/?fid=23991606952602429
CHANGELOG
Method 1 version 1.1- Fixed permissions.
I have had people tell me battery life is better and some say it's worse. You be the judge and let us know.
Happy Flashing!
Mine
Mine too
Looks interesting I'm gonna try it on m8 thanks for this.
---------- Post added at 08:41 PM ---------- Previous post was at 08:33 PM ----------
How does it affect benchmarks
smeejaytee said:
Looks interesting I'm gonna try it on m8 thanks for this.
---------- Post added at 08:41 PM ---------- Previous post was at 08:33 PM ----------
How does it affect benchmarks
Click to expand...
Click to collapse
People have noticed an increase in most graphic benchmarking. If you run Quadrant you will see it clear as day.
Don't trust benchmarks because they are variable (they will never show the same result with two simultaneous tests), the most important part is the feeling and the changes you can see.
I had some problems with my status bar which suffered of some slowdowns. After the installation of your mod, they disappeared on my Galaxy Young ! Thanks a lot. :highfive:
BlackGunZ said:
Don't trust benchmarks because they are variable (they will never show the same result with two simultaneous tests), the most important part is the feeling and the changes you can see.
I had some problems with my status bar which suffered of some slowdowns. After the installation of your mod, they disappeared on my Galaxy Young ! Thanks a lot. :highfive:
Click to expand...
Click to collapse
Very true. You will feel the difference in transitions and overall fluidity.
faster, but destroys gameplay by making them go into a time warp thing
Jazznax said:
faster, but destroys gameplay by making them go into a time warp thing
Click to expand...
Click to collapse
I agree.
I am using galaxy note 4, dynamic Kat custom rom, and ael custom kernel straight out of the box.
I have been running this same exact setup for over a month straight now.
I play MC4 (modern combat 4) religiously, i probably put in about 3-4 hours a day m-f.
I play with a ps3 controller using the six axis controller app on play store.
I installed this thinking this would make gameplay better, I installed using all 3 methods and get the same results with gameplay.
It seems to make any game sort of stutter I guess you would call it.
Benchmarks, system, and everything else seems to work excellent though.
So pretty much everything except gameplay works great, so overall great mod, but is there any other inputs beside -60 that might benefit gameplay more @razz1?
If so, I'd be happy to test it out.
psycho4us4 said:
I agree.
I am using galaxy note 4, dynamic Kat custom rom, and ael custom kernel straight out of the box.
I have been running this same exact setup for over a month straight now.
I play MC4 (modern combat 4) religiously, i probably put in about 3-4 hours a day m-f.
I play with a ps3 controller using the six axis controller app on play store.
I installed this thinking this would make gameplay better, I installed using all 3 methods and get the same results with gameplay.
It seems to make any game sort of stutter I guess you would call it.
Benchmarks, system, and everything else seems to work excellent though.
So pretty much everything except gameplay works great, so overall great mod, but is there any other inputs beside -60 that might benefit gameplay more @razz1?
If so, I'd be happy to test it out.
Click to expand...
Click to collapse
Looks like it's going to work a little different on some phones. Unfortunately so far I haven't seen that issue on my G3. I would imagine we could adjust it somewhere else in the negative range to fix games on some devices. If you want to test things out, the best way would be for you to play with different negative numbers. Maybe -60 isn't the perfect value for a Note 4, but close.
If anybody needs to tweak it they can use Terminal Emulator and play with some values.
1. Open terminal.
2. Type "su"
3. Press enter/return key
3. Type
"setprop debug.egl.swapinterval"
4. Press Space bar to enter a space.
5. "Your new value"
6. Press enter/return key.
7. Test your game.
Try different values till the issue goes away.
Stock value is 1.
Don't bother with 0.
That's about all I can do to help those that have issues in games as I don't have every device. New values would just be a shot in the dark for me. I personally think it's a property that's worth the time to get right on your phone. People in the LG G3 forum have no issues and are very happy with it. It makes a considerable overall difference.
smeejaytee said:
Looks interesting I'm gonna try it on m8 thanks for this.
---------- Post added at 08:41 PM ---------- Previous post was at 08:33 PM ----------
How does it affect benchmarks
Click to expand...
Click to collapse
so do you see any difference? our M8 its already fast so l dont think we will see any difference at all xD
Jazznax said:
faster, but destroys gameplay by making them go into a time warp thing
Click to expand...
Click to collapse
What phone are you using?
psycho4us4 said:
What phone are you using?
Click to expand...
Click to collapse
Me myself an using a moto x 2014
razz1 said:
REQUIREMENTS.
MUST BE ROOTED WITH RECOVERY.
HAVE INIT.D SUPPORT for method 1.
HAVE TERMINAL EMULATOR for method 2.
NOTE: This may work for all android devices but is only tested on a LG G3 D851. If it works for you let us know.
So far others have used it on Sony and Samsung devices with great results.
ORIGINAL THREAD HERE
http://forum.xda-developers.com/showthread.php?t=3107282
[mod] increase fps 5/12/2015
GENERAL DISCLAIMER.
XDA and I are NOT responsible if anything wrong happens to your device by using this mod. Always make sure you have a backup ready if needed.
ABOUT THIS MOD.
Here is a very simple mod that I wanted to share. This is what has been labeled in the past as the build property to remove a FPS cap on all android devices. This doesn't actually do that but you will see an increase in frames per second by adjusting the EGL swap interval. Unfortunately, this property has always had big issues with visual artifacts that made it useless to use.
I found it frustrating that we could obtain such a high FPS but plagued with issues. So I spent some time and found a new value. One that could actually work on all android devices. Instead of 1 for stock or 0 for modified. Here is the new value...
debug.egl.swapinterval=-60
A general description...
https://www.khronos.org/registry/egl/sdk/docs/man/html/eglSwapInterval.xhtml
While other negative values may work, -60 brought the most bang for the buck when it came to benchmarks. I am truly excited about finding a way to make it work and although it's just a new value, I would appreciate if you could give me credit if using this property as it is the first time it will actually work the way we want it. This value didn't just fall from the sky. Certainly no need to ask for any permissions.
WAYS TO USE THIS MOD.
I figured many people would at least like to try this out so I made it as easy as possible for newer and more advanced users. The mod is actually really easy to apply. Simply add the property to your build.prop file and reboot or use one of methods below.
METHOD 1.
Use the proper flashable zip to install into init.d so the mod is ready directly after a reboot.
METHOD 2. (recommended)
Use the proper flashable zip to install into /system/xbin and call upon it when needed and disable it when not needed.
INSTALLATION.
Method 1
1. Download https://www.androidfilehost.com/?fid=23991606952603390
2. Flash in recovery.
3. Reboot.
METHOD 2.(recommended)
1. Downloadhttps://www.androidfilehost.com/?fid=23991606952602432
2. Flash in recovery.
3. After you reboot open Terminal Emulator and type the following without the quotes.
4. Type "su" and press the enter key.
5. Type "unlockfps" and press enter. This will activate the property for higher fps.
To deactivate type "lockfps"
NOTE: You may need to toggle your screen off/on to fully activate the mod using method 2.
You will also need to activate the mod again after a reboot. The setting won't survive a reboot with method 2.
UNINSTALL
METHOD 1.
Version 1.1
https://www.androidfilehost.com/?fid=23991606952603391
METHOD 2.
https://www.androidfilehost.com/?fid=23991606952602429
CHANGELOG
Method 1 version 1.1- Fixed permissions.
I have had people tell me battery life is better and some say it's worse. You be the judge and let us know.
Happy Flashing!
Click to expand...
Click to collapse
Keep smiling brother, may your equipment production certificate of my work, but the feeling is not obvious. Motorola x 2013
On Galaxy Nexus with CM12.1 diffrence is visible, thanks man
Works fine in my galaxy tab pro 8.4
, thanks!!!!!!
CikiPiki said:
so do you see any difference? our M8 its already fast so l dont think we will see any difference at all xD
Click to expand...
Click to collapse
Not tried it yet been messing with something else ATM lol might try it today if I get 5 mins.
OK so I flashed this and it does make a difference, things feel faster and gaming performed seems better also.
Thanks for this
help
the links are dead, please repost
seems like the site was down last night, just dled and going to give this a try
I'm on a nexus 5, 5.1.1, euphoria rom with elementalX kernel.
-60 makes my games go crazy. -1 seems to be normal. -2 goes crazy, but if I decrease more (like from -1 to -2, to -3, -4 etc.) then it goes crazier the more I decrease the value. Also, I didn't really notice any improvements on the fluidity of my UI.
Hi,
I am back with one of my builds. Again this is just result of my hobby, feel free to use it, but do it on your own risk. Also any updates will be probably sporadic.
I wanted to publish my build as quickly as possible, becasuse I promised in another thread. So I simply took, what I have (and I am using right now). As a result there some detail I`d like to change for public release like this for the future (e.g. all the special feature enabled by default, the big dmesg buffer). Be careful. I`ll try to do better version as soon as possible. I don`t recomend this for begginers. Be sure you have backup.
This build is based on the official LineageOS code and contains several of my changes. In some cases it could be considered as fix, improvement, but sometimes a hack or even even security risk, so please read carefully following list. All the changes I did because I wanted the system on my device behave that way (at least time to time). Take it or leave it. Please note, that all the features are enabled by default. Be careful.
- built-in root support
- RIL is based on stock KitKat version (works better for me than the official version)
- the sensors libraries are also from stock KitKat (same reason as above )
- barometer sensor is correctly recognized by the system
- the menu button does, what it always did
- notification led brightness can be configured by user
- entering safe mode by holding specific keys during boot can be disabled by setprop persist.safe_mode_disabled true (this has always only annoyed me, but be sure you know you are doing)
- device wakeup by power button can be disabled when proximity and light sensors are blocked (e.g. in a pocket). Execute setprop persist.pwrbtn_proximity_block true
- external sdcard can be made world writeable by setprop persist.world_writable_sdcard true (be careful with this one, this opens a security risk)
- the notification led can blink when the battery is fully charged - enable by setprop persist.blink_when_charged true
- F2FS support
- the notification icons are also on the lock-screen as they ware in
previous Android versions. The carrier name is moved above the clock
(this cannot be turned off)
- the dmesg buffer size is increased to 16M. I set this for debugging
and remove it in next published build.
- ramdisk LZMA compression support
- sdcardfs support - This is faster replacemnt for the FUSE filesystem. I backported this for higher kernel version. Although I`ve been using this for several months without any problem, please consider this experimental. Enable with setprop persist.sys.sdcardfs
force_on
- mount directories for sdcard are protected against writing while the sdcard is not mounted (this solves a race condition problem which allows some apps to create files in there)
- there some other small changes related to my multiboot envrionment, czech translation, carrier name, etc.
Source code
In the installation zip there is a directory code_info with following content:
roomservice.xml - roomservice.xml for the build
commits - list of git repositories and commits used for the build
patches - directory tree with structure reflecting the source and containing
patches for individual projects. The idea (not always followed) is that one patch is one feature,if possible.
code1.diff - all the patches from patches directory together
code2.diff - changes which are not in patches directory
diff-commits.txt - obsolete, I`ll remove this one in the future or maybe use
it again
The only bug I know about is occasional crash of MTP, but I didn`t notice any negative consequences. There may some problem with battery charging (the display turns on time to time without no obvious reason during charging), but it may be some hardware error (bad cable or charger).
Since this is based on official LineageOS, thanks to everyone who contributed to it.
I am using this build for over a week without any problem, except those mentioned above.
Continue here, for the latest build.
UPDATE:
I totally forget about this yesterday - here are the proprietary files I used for this build proprietary-files-ocm13-skk-ril.tgz It is a mixture from the CM 13 official build and KitKat stock files, with modified ks file (then connect symbol is replaced with xonnect, so it doesn`t crash), maybe some other files and changes. I really don`t remember, I put this together during a long period of time. If you find any of your work inside, please accept my apologies and let me know. From my point of view it just works. If you want to apply the patches, then you will most probably want to change the hardcoded full path to these files in device/samsung/i9305/extract-files.sh.
UPDATE:
If you want to use anything from my patches, feel free to do so, just follow the license of the original project.
I tested it for about 4 hours for modem stability, taking the logs. All SAHARA transfers were ok, with no errors and retries. I should have mentioned your name in some post earlier
gongrats and many thanks @p.a.n. Your rom runs very well, its awesome. :good:
Do you mind, if I take your sources or parts of it or some files from your rom.zip for my builds? If I do so, I will mention you and what I took and give you credits.
rodman01 said:
gongrats and many thanks @p.a.n. Your rom runs very well, its awesome. :good:
Do you mind, if I take your sources or parts of it or some files from your rom.zip for my builds? If I do so, I will mention you and what I took and give you credits.
Click to expand...
Click to collapse
Thanks Use whatever you want from it just follow the license of the original project (I updated OP with similar note).
Help??? How to fix gps on this Rom plzz
Great work p.a.n.
Using for 24 hours no problems yet and seems very smooth.
Used it for a few hours with the built-in kernel then switched to Boeffla to get Boeffla Sound etc.
Very nice to have the customisable LED again as it was missing from the official LineageOS.
More importantly for me, the magnetic compass seems to work properly. I couldn't get it to work on official, nor on Rodman's RR.
No issues with GPS for me.
I had to install 'The SELinux Toggler' to set permissive so I could get Viper4Android to work (as with official) but I expected that.
One other thing, the MTP crash is the 'MTP host' app. I just disable this as it's only needed if you need your phone to be an MTP host for something like a digital camera, which I don't. It doesn't affect connections to your PC.
Is there an issue with the automatic execution of init.d scripts? I'm on Boeffla so it may just be that. Luckily you can tell Boeffla app to execute them anyway.
@Glenn2, thanks for testing I am not completely sure about it, but if I remember well, the compass problem is caused by the opensource sensor library (I think that just replacing the/system/lib/hw/sensors.smdk4x12.so with the one from my build should fix that). But the problem is not actually with the compass sensor, that one is ok, but in the opensource version there are missing some "fake" sensors, which provide calculated data based other "real" sensors. One of them provides orientation information, often used in apps as compass. Try some app (e.g. Androsens2) which lists all the sensors and you`ll see the difference - the "fake" ones have iNemo in their name.
I actually don`t care about the MTP crashes. It mostly happens after uninstalling some app, which doesn`t happen too often and otherwise I haven`t noticed any negative related to that. It is just annoying popup for me.
What do you mean by the question about init.d scripts?
p.a.n said:
What do you mean by the question about init.d scripts?
Click to expand...
Click to collapse
I have a couple of scripts and they were not running on boot. I don't know if Boeffla kernel affects busybox. I remedied this by telling the Boeffla Config app to run init.d scripts when it launches.
Also, I had a power manager service wakelock that kept my phone awake for hours, only a reboot cleared it. I had this happen a couple of times on official LineageOS too. Not the famous mdm_hsic_pm0 which now seems to be cured at long last! I had a period of no signal when I was on the London Underground, maybe that was the cause.
Glenn2 said:
I have a couple of scripts and they were not running on boot. I don't know if Boeffla kernel affects busybox. I remedied this by telling the Boeffla Config app to run init.d scripts when it launches.
Click to expand...
Click to collapse
There is /system/etc/init.d/* scripts, which run OK, or at least /system/etc/init.d/00banner does. There is also /system/etc/init.d/90userinit, which executes /data/local/userinit.sh. I remember that seme previous CM version there was also a user defined init.d somewhere in /data. This may what has changed, but I am not if this is your case.
Glenn2 said:
Also, I had a power manager service wakelock that kept my phone awake for hours, only a reboot cleared it.
Click to expand...
Click to collapse
This on is also often on the top of my kernel wakelock list, but never that bad, always with reasonable times.
Glenn2 said:
Not the famous mdm_hsic_pm0 which now seems to be cured at long last!
Click to expand...
Click to collapse
Yes, the solution has been sitting in the Samsung kernel source for a long time ...
Glenn2 said:
Great work p.a.n.
Using for 24 hours no problems yet and seems very smooth.
Used it for a few hours with the built-in kernel then switched to Boeffla to get Boeffla Sound etc.
Very nice to have the customisable LED again as it was missing from the official LineageOS.
More importantly for me, the magnetic compass seems to work properly. I couldn't get it to work on official, nor on Rodman's RR.
No issues with GPS for me.
I had to install 'The SELinux Toggler' to set permissive so I could get Viper4Android to work (as with official) but I expected that.
Click to expand...
Click to collapse
Do you install the last rom ??? Or not
It is worth pointing out that after backing and restoring between roms, the SELinux attributes for efs files can become not correct. That can lead to something like this :
Code:
06-28 04:17:43.705 3799 3799 W ks : type=1400 audit(0.0:30): avc: denied { read } for name="efs1.bin" dev=mmcblk0p11 ino=8200 scontext=u:r:qcks:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
Code:
06-28 04:17:43.712 3799 3799 E kickstart: Requested ID 16, file "/tombstones/qcks/efs1.bin"
06-28 04:17:43.712 3799 3799 E kickstart: ERROR: function: open_file:80 Unable to open input file /tombstones/qcks/efs1.bin. Error 13: Permission denied
It results in not working RIL because of enforced SELinux. Running restorecon fixes the problem.
moad gastro said:
Do you install the last rom ??? Or not
Click to expand...
Click to collapse
I don't know what your question means, as there is only one ROM. I installed from the link in the OP (dated the same date as the OP).
Still using this ROM, and still very few problems.
The day before yesterday it crashed with the screen off. Had to hold power button in to restart.
And yesterday the damn wakelock. It got stuck at a time when I had no signal, and also I used the camera, so either may be relevant. It didn't seem to cause any drastic battery drain though (see images attached). I suppose when the CPU is awake but only at 200MHz and not doing much it uses little more than when it is sleeping?
Regarding init.d scripts. I added one to /system/etc/init.d that simply writes a file to /data when it runs, to test that it DID run. Script starts #!/system/bin/sh
Results:
1) rom with its own kernel - didn't run
2) rom with Boeffla kernel - didn't run
3) rom with Boeffla kernel and Boeffla Config app set to execute init.d scripts itself - did run
One more, just for fun!
Two days ago I was at the Wimbledon tennis, and the location service and/or weather widget decided I was in Boulogne-Billancourt (Paris) instead! I then opened and closed Maps, refreshed the widget and it changed to the correct location!
..
Hi,
I'm trying to install the current build using TWRP 3.0.2-1, but it gets stuck at the "Patching system image unconditionally..." step with the progressbar at around 40%. It's been sitting there for about 10 minutes. Does anyone know how that'd be fixable?`
Cheers
Latest build is ok for me. I've flashed it using TWRP 3.1.0 build from rgib
https://drive.google.com/drive/folders/0B7pwslEEF0l4Yzk2Nm1jOGRDQVU
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: