[MODS DELETE THIS THREAD] exNoShadez-eas - Google Pixel XL ROMs, Kernels, Recoveries, & Other

Mod edit: Thread closed on owner's request.
exNoShadez-EAS Kernel
Hey Pixel XL forum. I'm a Pixel/Sailfish owner, who also enjoys hacking on kernel code. I recently released a Kernel in the Google Pixel forum => but we are all using the same kernel, sooo.... I thought after pushing my second stable release, that I should probably post on the XL forum too.
My kernel is a bit different than most kernels available, you will quickly notice. Lots of interesting features and some unique ones too.
FEATURES
- Current LTS release -> Linux-3.18.114
- Energy Aware Scheduling
- Schedutil (default Cpu Governor)
- RCU infrastructure backport (with expert mode enabled)
- Cpu-Boost / Input Boosting (enabled by default)
- BINFMT_MISC support (NOT mounted on boot).
- Kernel Hardening/Protection (CopperheadOS/Grsec/Pax Marlin kernel hardening features)
- leds-qpnp: Notification LED control - V1.1c (Boeffla) - Adapted for Marlin
- Binder_rt = My own re-implementation of AOSP Binder that uses rt_mutexes; supporting priority inheritance
- Improved scheduling/determinism for high priority threads/tasks
- Backported Scheduling, Locking and Workqueue subsystem code from Newer Linux kernels.
- Audio Driver enhancements / backports (from Wahoo/Pixel 2)
- Sound/Audio driver Tweaks (bug fixes, scheduling improvements)
- forced Interrupt threading enabled
- Wifi Mac Address Randomization
- WireGuard (VPN) kernel module support
- KCal Advanced Colour control
- Improved ASLR (in kernel)
- USB Fast Charge
- Wake Gestures
- GCC 6/7+ Fixes
- Built with GCC-8.x-dev
- and more
Contains code from everywhere: Code Aurora, Flar2/Marlin, CopperheadOS, AOSP, Project-EAS, Freak7/Kirisakura, Linaro, Pixel 2 kernel sources, mainline linux and elsewhere. Modifications and backports by me, as well.
BACKGROUND
I wanted a kernel for My Pixel that had 'all of the things', it didn't exist... So I'm working on my own kernel. I try to balance Security/hardening, experimental features with high Performance and battery life. <- not an easy task! ... Some of the security features do come with overhead, but if you use apps that are CPU heavy / processing and/or require low latency - they will perform well (at the cost of chewing some battery life, of course).... Battery life and SOT are very reasonable though.
WARNING / VERY IMPORTANT: This kernel isn't compatible with installing TWRP ~> meaning; you must use the fastboot version of TWRP (used in RAM) , flash the kernel and NOT install TWRP to your system (the kernel is too big for TWRP to co-exist).... This may sound inconvenient, but there are a number of valid reasons to avoid reducing a kernel's size in order to support TWRP installation, in the boot partition.
***Fun facts on not supporting TWRP below => 2nd post: PLEASE READ: to understand my motivation***
TWRP REMOVAL
*To remove TWRP from your system; You need the stock boot.img from your running/current firmware (which is inside of the factory image zips) or use the Nov Stock boot.img provided here. Then it's as simple as flashing the boot.img to wipe TWRP;
fastboot flash boot_a /path/to/boot.img
fastboot flash boot_b /path/to/boot.img
Stock 8.1 July 2018 Boot.img => https://github.com/nine7nine/Apps/raw/master/MarlinStockJulyBoot.img
Now you can proceed with using the TWRP fastboot boot.img to flash my kernel, magisk/supersu or whatever else....
Fastboot twrp boot image => https://dl.twrp.me/marlin/twrp-3.2.2-0-marlin.img
WARNING: This shouldn't need to be said, but we did have someone on the Pixel forum who did this, so I'm adding a sticky/warning here; do NOT EVER re-lock your bootloader after flashing any kind of custom software, kernels, etc to your device - *it will brick your phone*. Meaning you are screwed would need an RMA / replacement device ... everyone in the XDA community should know better, but still; worth mentioning....
IMPORTANT:
Before asking questions; Please read through the thread (starting with the last few pages) - I shouldn't need to be repeatedly answering the same questions over and over again. It's good practice to get into the habit of reading through threads before asking questions in any thread on XDA, as more often then not; you're question has probably been answered. Thanks!
EXNS-EAS KERNEL DOWNLOAD:
JULY 2018 OREO 8.1 RELEASE exNoShades-eas Kernel Flashable zip
https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_v2.8.2_f94351f.zip
It is stable, high performance and very responsive...
Important: You will need root; I don't support non-rooted devices && some features require it. I recommend using Magisk; https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589 ...
NOTE: Make sure to flash the latest Magisk beta *before* flashing the kernel zip ...
More Background / Important Notes:
Binder_RT:
My own port and re-implementation of the Binder Kernel Driver; a slightly modified version of The AOSP binder.
Binder_RT uses rt_mutexes as oppsed to mutexes for locking in Binder, ion, ashmem, etc... rt_mutexes support priority inheritance and should improve determinism in Binder, speed up IPC, Ion and Ashmem => Allowing applications that require low-latency, tight deadlines, low jitter and deterministic behaviour to perform better ~ This re-implementation is proving to be the great for those types of applications. The goal here is to help ensure that the Kernel and Binder's high priority && time critical threads and tasks are properly prioritized... Example; audio buffers arriving on time / no buffer underruns... *Further development work is planned to research, experiment with and improve Binder_RT.
rt_mutex documentation, for those interested;
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex.txt
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex-design.txt
CPU-Boost / Input Boosting:
Touch inputs boost CPU frequencies (thus improves performance and responsiveness).
# Cpu-boot / Input boost settings
write /sys/module/cpu_boost/parameters/input_boost_enabled 1
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1363200 1:0 2:1900800 3:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 100
IO/ CPU Governors:
This kernel doesn't include a thousand io/cpu governors. IO-wise; CFQ is the default, but we've got a few in there. chose your poison, but know that the majority of my testing is centered around cfq and deadline. CPU Governor-wise the common Linux CPU governors are there; along with Sched and Schedutil....
Stick with Schedutil - on idle, it draws very little power and in most 'peak performance situations, it should do very well..... I'm getting great battery life, sot and performance.
Managing Kernel Settings:
Get EX Kernel Manager - my original code on github was forked from EX kernel, before rebasing it - but EXKM will give you access to 99% of my kernel's settings.
My 8.1 Kernel Sources: https://github.com/nine7nine/Marlin_exns-eas
Donations via PayPal very much appreciated. I do put a significant amount of energy and time into researching, development, testing / QA and also providing support/help to end-users... It's definitely not mandatory to donate; but If you appreciate the effort, see value or benefits from using my kernel on your device and can afford to; Use the "Donate to me" button or the below link... It makes a big difference. thanks!
https://www.paypal.me/jrdnjhnstn

Why TWRP Installations are NOT supported:
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
(and why I'm not using it!)
Most custom/android kernel devs are using the above configuration in kernel compilation, which is arguably very BAD... I understand that boot partitions are small and the desire to install TWRP to them, thus there is a need to reduce the kernel's size....and yes, this will achieve that - However;
1. SUSE, RedHat, etc (Enterprise linux) disable CONFIG_CC_OPTIMIZE_FOR_SIZE -> it's original use case has proven to be invalid. Even Google (in their own documentation) advise against using this; https://source.android.com/devices/tech/perf/boot-times ....
2. It suppresses useful compiler warnings....
3. As SOCs have become more powerful, google has come to the same conclusion that Enterprise Linux did back in 2012.
4. by turning off CONFIG_CC_OPTIMIZE_FOR_SIZE, we achieve better performance, boot time and better cache utilization.
Clark Williams / Redhat Bugzilla said:
* Cause: CONFIG_CC_OPTIMIZE_FOR_SIZE set with assumption that smaller code would yield hot cache lines and good performance
* Consequence: this config caused gcc to generate jump-to-jump code which causes cache line bouncing, hurting performance
* Fix: turn off CONFIG_CC_OPTIMIZE_FOR_SIZE
* Result:slightly larger kernel but better cache utilization
Click to expand...
Click to collapse
(The Above is quoted from Clark Williams, A Senior Software Architect @ RedHat -> https://bugzilla.redhat.com/show_bug.cgi?id=796297)
I know of no other way to significantly reduce kernel size. Disabling some debugging, unneeded features, etc helps - but not enough.... I am focusing on optimization, using newer builds of GCC/Linaro, performance enhancements, fixing compilation errors, etc, etc -> these things are more important than trying to support TWRP installation.
Therefore; I do NOT support installing TWRP....

This sounds incredible. All those features.. and then some. Hard for me to test as I rarely use my PC but I may have to go and give this a try.
Edit: would it be possible to create a build for those who do want to use TWRP? Would be great to do some benchmarks (real work using DiscoMark and synthetic using geekbench/AnTuTu/etc) to see differences between the two.

All those features are welcome in this poor Oreo pixel community! thanks for your work..
i'll try it as soon as possible!

spr33 said:
This sounds incredible. All those features.. and then some. Hard for me to test as I rarely use my PC but I may have to go and give this a try.
Edit: would it be possible to create a build for those who do want to use TWRP? Would be great to do some benchmarks (real work using DiscoMark and synthetic using geekbench/AnTuTu/etc) to see differences between the two.
Click to expand...
Click to collapse
No. like I said. I don't/won't support installing twrp. it would require reverting a bunch of patches/ work that I've already put in... and also not using linaro GCC 7.2.1 compiler, either...
the time invested would be a complete waste for me and I would have maintain another separate branch. test another build, etc, etc'... i'm not doing it. my current goal is to reduce my branches into one single branch/build;. ... which will end up hopefully being binder_rt... not create more.
feature wise, pretty much a 'best of' what any other custom kernel offers for Marlin, all of the hardening stuff (I think I'm the only Marlin kernel on XDA with that), etc... afaict, I'm the only one rolling in EASv1.4, cpu-boost, dynamic stune boost; all of which I've ported myself... some of the audio driver stuff I personally ported (more coming) and binder_rt is my baby; I ported aosp binder and researched / Inplemented all of the changes to Binder...
in my yet-to-be-released binder builds I also have backported a large chunk of the linux locking, workqueues and scheduling code and some other bits from newer mainline linux kernels (which allow me to pull in some new features and use them).
so I'd rather work on this kind of stuff, over caring about twrp, doubling my workload to support running synthetic benchmarks between gcc's -Os vs. -O2 optimization levels...

Thanks for the new kernel. Sounds very interesting. Can't try it atm because i am on dp1 from 8.1. Hope you gonna also support 8.1 when official sources are out. For me battery life is already great on dp1.

housepabldroid said:
All those features are welcome in this poor Oreo pixel community! thanks for your work..
i'll try it as soon as possible!
Click to expand...
Click to collapse
haha. pixel community isn't too bad. there's just not a lot of custom oreo ROMs.... myself, I wouldn't want to run any of those custom roms anyway. they usually are built without odexing or proper signiture key signing = less secure and way less optimized... Stock ROM is great, just needs root and a few apps to modify / customize it a bit.
for me, the kernel has always been the issue. lol... therefore, roll my own. lol....
ya, for sure give it a try... I honestly would say binder_rt is the best build... the 'stable build' is a bit of a misnomer - all of the builds are stable, just the binder ones are running more experimental code... binder_rt blows the socks off any other Marlin kernel for certain kinds of workloads... I'm aiming fir it to become my default build...

Donric13 said:
Thanks for the new kernel. Sounds very interesting. Can't try it atm because i am on dp1 from 8.1. Hope you gonna also support 8.1 when official sources are out. For me battery life is already great on dp1.
Click to expand...
Click to collapse
yup. I have to wait until kernel sources are released. you got it!. but when they are / 8.1 is released; I will be upgrading to 8.1, so no worries - there will be an 8.1 version...
I've heard heard that battery life is pretty good on 8.1, there's a thread in the pixel forum about it... but by what they were saying, it didn't seem that much better than what I see from my kernel.....
I'm more interested to see what performance improvements are in 8.1 kernel sources... I've found stock kernel to be a bit crappy for some stuff...
well, if at some point you are bored and want to test my kernel on 8.1, go for it. ya never know: maybe it will work. the reason I say that?
IIRC - it was tested with my old kernel / sources build... could've been a bug, not present in the new one.... or something else. IdK.. being as I'm on 8.0 I can't even look into why that might be or have been...
just make sure if u do ever try it, keep the stock boot.IMG for 8.1 around, in case it doesn't work..... and report back, if it does work. lol

Gotta say super smooth. Thanks for sharing. Maybe it's just a glitch in ex kernel manager but zram "stopping..." Or nothing to worry about.

JS.zip said:
Gotta say super smooth. Thanks for sharing. Maybe it's just a glitch in ex kernel manager but zram "stopping..." Or nothing to worry about.
Click to expand...
Click to collapse
Ah yes, I should've mentioned that ~ zram is working fine - but EXKM is being denied permission to read those files on the file system - I think it's due to a change in cgroups code (from merging in EASv1.4), but I haven't gotten to the bottom of it yet....
No worries though ~ I HAVE completely verified that zram is working, mounted swapon and behaving as it should... Honestly, the defaults for zram are fine ~ if they ever weren't; you would have bigger problems on your hands, that changing swapping wouldn't help. lol
Which build are you using? (just curious)

nine7nine said:
Ah yes, I should've mentioned that ~ zram is working fine - but EXKM is being denied permission to read those files on the file system - I think it's due to a change in cgroups code (from merging in EASv1.4), but I haven't gotten to the bottom of it yet....
No worries though ~ I HAVE completely verified that zram is working, mounted swapon and behaving as it should... Honestly, the defaults for zram are fine ~ if they ever weren't; you would have bigger problems on your hands, that changing swapping wouldn't help. lol
Which build are you using? (just curious)
Click to expand...
Click to collapse
Thanks that's what I thought. The bad boy "Binder RT" lol

JS.zip said:
Thanks that's what I thought. The bad boy "Binder RT" lol
Click to expand...
Click to collapse
bad boy eh? haha.
Ya, no worries - I check that sort of stuff, when it crops in... fixing that particular issue just hasn't been a huge priority, over other stuff that I'm working on. (and because I think it's pointless that EXKM even displays it to begin with - it just gives users the false impression that they are tweaking something, that in 99.99999% of cases - is absolutely pointless to touch).
Anyhoo, cool - let me know how things are working out with the binder_rt build, as you get some more use in ~ I really want it to become my main focus / implementation. (I personally won't be going back to using any other build day to day, anyway.)

nine7nine said:
bad boy eh? haha.
Ya, no worries - I check that sort of stuff, when it crops in... fixing that particular issue just hasn't been a huge priority, over other stuff that I'm working on. (and because I think it's pointless that EXKM even displays it to begin with - it just gives users the false impression that they are tweaking something, that in 99.99999% of cases - is absolutely pointless to touch).
Anyhoo, cool - let me know how things are working out with the binder_rt build, as you get some more use in ~ I really want it to become my main focus / implementation. (I personally won't be going back to using any other build day to day, anyway.)
Click to expand...
Click to collapse
I just wanted to point out that I grabbed your stock kernel from the OP and had planned to use that to flash my stock image. However, I happened to have the latest boot.img release decompressed on my drive so I compared it to the one I had on hand.
MD5 for your Stock Image: 7A2D92981FDE96E5D60D806019ACFA0C
MD5 for Google's Stock Image: BF9EDA2888C8C6A1FCD0A7DB6E37F739 (Latest November build)
Now I don't want to sound like the suspicious type, because in reality the stock kernel you provided is just to get TWRP off the device before flashing your kernel, but I'm forced to ask why your stock image is not identical with the main stock image? Unless your stock kernel isn't from the latest release but instead from a prior month or something of that nature (It would take me quite awhile to download the other month's releases just to check so I was hoping to ask you instead)

AlkaliV2 said:
I just wanted to point out that I grabbed your stock kernel from the OP and had planned to use that to flash my stock image. However, I happened to have the latest boot.img release decompressed on my drive so I compared it to the one I had on hand.
MD5 for your Stock Image: 7A2D92981FDE96E5D60D806019ACFA0C
MD5 for Google's Stock Image: BF9EDA2888C8C6A1FCD0A7DB6E37F739 (Latest November build)
Now I don't want to sound like the suspicious type, because in reality the stock kernel you provided is just to get TWRP off the device before flashing your kernel, but I'm forced to ask why your stock image is not identical with the main stock image? Unless your stock kernel isn't from the latest release but instead from a prior month or something of that nature (It would take me quite awhile to download the other month's releases just to check so I was hoping to ask you instead)
Click to expand...
Click to collapse
Easy explanation - I'm on Sailfish, you aren't; so the md5 wouldn't match...
I can do one of two things; you can post a upload/link to your boot.img and I will replace the link for Marlin's nov boot.img (adding it to my github) OR I will remove the link from the post and Marlin users will have to fend for themselves. (have to download 1.8GB firmware themselves for a boot.img... Obviously i'm NOT downloading your guys Nov Firmware images).
nothing suspicious at all here, dude.
EDIT: I've removed the link to the sailfish Nov boot.img, as a sign of good faith; I can replace it with the Marlin Nov boot.img - but that will require you to post a download/link to me, so I can add it in. thx

nine7nine said:
Easy explanation - I'm on Sailfish, you aren't; so the md5 wouldn't match...
I can do one of two things; you can post a upload/link to your boot.img and I will replace the link for Marlin's nov boot.img (adding it to my github) OR I will remove the link from the post and Marlin users will have to fend for themselves. (have to download 1.8GB firmware themselves for a boot.img... Obviously i'm NOT downloading your guys Nov Firmware images).
nothing suspicious at all here, dude.
EDIT: I've removed the link to the sailfish Nov boot.img, as a sign of good faith; I can replace it with the Marlin Nov boot.img - but that will require you to post a downlink to me, so I can add it in. thx
Click to expand...
Click to collapse
No problem, I download every Marlin release so I'll just update my AFH folder to include the monthly kernel release and users can download it from there. You can either link to my folder or download from it to add to your repository; either one is fine with me Thanks, and I do appreciate what you're doing but I have a 'verify first' stance since these devices are a big part of people's lives. I'm going to give your kernel a spin now, I appreciate you getting back to me so quickly. If only AFH was this fast, I just spent 25 minutes trying to get it to create an empty folder...
Link to Marlin Stock Images: https://www.androidfilehost.com/?w=files&flid=231142
Edit: I attempted to flash the "exNoShadez_eas-3.18.83_Binder_b0b66e0.zip" from the fastboot installed version of TWRP after flashing the stock boot to slot_a and slot_b, but it is failing with an error that states, "New image larger than boot partition. Aborting..." Then updater process Error 1. Any idea what would cause that?

AlkaliV2 said:
Edit: I attempted to flash the "exNoShadez_eas-3.18.83_Binder_b0b66e0.zip" from the fastboot installed version of TWRP after flashing the stock boot to slot_a and slot_b, but it is failing with an error that states, "New image larger than boot partition. Aborting..." Then updater process Error 1. Any idea what would cause that?
Click to expand...
Click to collapse
Hey, I added your nov boot.img to the OP. put it on github to save a few clicks for people.
The error you are seeing would suggest that TWRP is installed to the system. That is the only time anyone has ever bumped into that message. So, I'm not sure what's going on with your end but it would seem you have twrp actually installed...?!
the TWRP that you are supposed to use, is this one;
https://dl.twrp.me/marlin/twrp-3.1.1-1-fastboot-marlin.img
that loads and runs from RAM. twrp can't be "installed from fastboot" ~ it installs to the boot partition; leaving not enough room for the kernel.

nine7nine said:
Hey, I added your nov boot.img to the OP. put it on github to save a few clicks for people.
The error you are seeing would suggest that TWRP is installed to the system. That is the only time anyone has ever bumped into that message. So, I'm not sure what's going on with your end but it would seem you have twrp actually installed...?!
the TWRP that you are supposed to use, is this one;
https://dl.twrp.me/marlin/twrp-3.1.1-1-fastboot-marlin.img
that loads and runs from RAM. twrp can't be "installed from fastboot" ~ it installs to the boot partition; leaving not enough room for the kernel.
Click to expand...
Click to collapse
Yeah, that actually explains it. I was using a kernel with TWRP installed last go round and now it seems just flashing the factory boot.img is not getting rid of the installed TWRP. I'll figure out how to get TWRP removed for good this time; thank you for letting me know where to look.

AlkaliV2 said:
Yeah, that actually explains it. I was using a kernel with TWRP installed last go round and now it seems just flashing the factory boot.img is not getting rid of the installed TWRP. I'll figure out how to get TWRP removed for good this time; thank you for letting me know where to look.
Click to expand...
Click to collapse
Yup. TWRP can't be installed along side. Running it from RAM has to be used. ie: I don't support TWRP installations. lol
Flashing the factory boot.img DOES get rid of TWRP for good ~ you just have to make sure to use the TWRP fastboot boot.img for flashing my kernel after (since fastboot/twrp doesn't install to the boot partition)...
I've added a link to the OP to Marlin's twrp fastboot boot.img....
I also updated all of the download links and double-checked to make sure that all of the Marlin zips are packed properly with AnyKernel2 + relabelling every file on my github (by re-packing all of them all... This is mostly just paranoia on my part - but now that I'm supporting 2 devices, best to make sure that nothing gets tangled together.)

@everyone
just a few notes, since you guys are just getting exposure to my kernel, the way I do things; in regards to development, etc.
-> I post test builds (this usually happens when I make big changes.). reports are helpful on these builds.
-> Development happens fast; *I routinely add new features, bug fixes, etc and i'm almost always ahead on LTS updates over the Stock kernel.
examples;
=> lts -3.18.83 build available on the day of release
=> my Binder_rt branch is currently 140+ commits (code changes) ahead of the the other branches.
(changes since in the current downloads/releases)
=> There are a number of bug fixes, a few added features (mostly in-kernel stuff), some optimizations *and* there are massive upgrades to parts of the kernel's subsystems. (100+ commits are related to that)...
(changes since the current downloads/releases)
NOTE: The binder Branch (non-rt) will see the majority of the above changes code, but the Stable branch will only see a subset of these commits + bug fixes.
I probably won't roll out a test build for Binder_rt builds, until I've had the newest code running for a couple of days.... At that point, once things have proven to be stable good ~ i'll roll out a test build for anyone who wants to help out and dogfood test builds....
Then, I will push back changes back into the Binder builds, Stable, etc... I usually try and line up actual releases to LTS and/or => more importantly monthly android security / firmware updates....
**So the gist is; there will be frequent updates. Update as you see fit - anyone who wants to help out - run test builds and report back issues.

So pending a detail or two, I likely will be phasing out my other builds in favor of the Binder_rt build.
- I've had quite a lot of feedback via the Pixel forum, PMs and email (and a couple of friends using it too).
- The Binder_rt build seems to be very stable for everyone.... not too mention just all around better.
- there seem to be no drawbacks and quite a few benefits to that build over the others.
The one thing I'm waiting on is; I've joined the Android Kernel Developers Google Group and am currently waiting to see if I can't get some help with porting a missing Kernel function into Marlin's sources ~ this particular kernel function is what's stopping me from having Binder be sync'd with the AOSP binder implementation.... I'm hoping to resolve this sooner than later, at which point I will be able to merge in those commits (and test them).
In the meantime I'm working on a few backports to the audio driver and a few other bits (taken from Wahoo/Pixel 2 kernel sources). I've also pulled in a few fixes to binder from Wahoo, as well....
So I might post a test build for Binder_rt tomorrow - as it's accumulated a number of changes, bug fixes, etc.... I'm not sure If I will have any resolution to the missing kernel function - but that doesn't affect pushing a test build....

Related

[Kernel] [.34] Undervolted @ Stock-8/29 - 950mV-The Original

What this kernel does is provide slightly less voltage to the processor. This should not be dangerous for anyone to try, however it may be unstable or just result in general weirdness on a few phones. If it does, all you have to do is revert back to the kernel you had before.
The upsides to less voltage are less heat as well as less power consumption. That means battery life
Remember, this one is running at stock speeds.
Get it on Koush's RomManager (download RomManager from the market) I'll post changelogs in this thread from now on, but keep the kernel on RomManager.
Changelog 8/29:
Lots of stuff.. I dunno.. Look at the CM6 kernel changelog (I've been working on that).
Biggest thing IMO is the usleep stuff which lowers CPU usage and therefore increases battery life.
Note: only tested on CM6. Let me know if you try it on any other roms.
Link: http://kanged.net/up/files/5/kernels/signed-August26-UV950.zip
Changelog 6/20:
Ermm.. I've been releasing my kernels on twitter.. but I'm finally happy with this one.
-Latest Cyan commits
-Minor voltage tweaking
-erm... yeah I dunno.
Get it here http://kanged.net/kmobs/signed-619UV-34.zip or from RomManager.
Changelog 5/14:
-Reinstated those commits reverted earlier.
-Updated to .33.4
-Only doing a 925mV kernel due to the results from the blind study
Changelog 5/1:
-Reverted the following commits thanks to intersectRaven. I think they were the reason for the excessive battery drain.
27dd25f80402a13f9d5c381eda07b560e5545fcc
1490683fb851b992722cbd175d3df087df833656
f2513498e961966d3209aacfffc43de4f41f2ece
-Updated to latest CM source (minus those commits)
Changelog 4/21:
Fixed the board-mahimahi.c in the 850mV kernel.
OLD updates and changelog:
http://iq0.org/story/yet-another-nexus-one-kernel-now-battery-saving
Note: Now offering a universal update.zip method for flashing the kernel (big thanks to Koush for this one)
Thank you www.tdrevolution.com for hosting my work.
Does it still have the highmem?
GEtting an access denied message, Seems the post doesnt exist
Great job. Will get you a logcat if I get any random weirdness.
Maybe now my battery can last longer then my G1 battery did when I am at work.
Anyone care to make an update.zip for those of us without computers nearby to check this out?
Tested and functional with Enomther 1.61. Thanks a lot
What is the CPU voltage and is the some app that can show it?
Running this new kernel at 576/245 mHz, wifi off, 3G connection, brightness set to automatic. will report back with battery life as soon as it runs out. lol
Off of charger: 11:34AM , Wednesday, February 17, 2010
Battery completely drained: TBA
DocRambone said:
Tested and functional with Enomther 1.61. Thanks a lot
What is the CPU voltage and is the some app that can show it?
Click to expand...
Click to collapse
Hey do report if there is any improvements... meanwhile can someone make it into to an update.zip for us?
mgear356 said:
Hey do report if there is any improvements... meanwhile can someone make it into to an update.zip for us?
Click to expand...
Click to collapse
I will, phone seem ok so far, BenchmarkPi at 2670
No slowdowns or reboots during benchmarks or gameplay. Phone feel cooler tho
I'll give this a shot.
Mi|enko said:
Does it still have the highmem?
Click to expand...
Click to collapse
just flashed it. yes it does. my phone hasnt exploded yet either...
Mi|enko said:
Does it still have the highmem?
Click to expand...
Click to collapse
Yes
To those asking for an update.zip: I don't to package this into something that will be easily flashable by all, including those that may not understand the risks (I don't think there are any with this kernel, but can't be sure). I want there to be some rudimentary knowledge of android before someone goes and flashes this and potentially messes up their phone.
Does that make sense? I feel that there should be a barrier to entry on kernels that OC and the like.
What voltages is it for different MHz?
great job, really need something like this... im trying it out! thanks
DocRambone said:
What voltages is it for different MHz?
Click to expand...
Click to collapse
Its not across the board, and I'm not home right now to tell you, but 245 is at 1.0 vs 1.05 and 998 is at 1.250 instead of 1.275
persiansown said:
Yes
To those asking for an update.zip: I don't to package this into something that will be easily flashable by all, including those that may not understand the risks (I don't think there are any with this kernel, but can't be sure). I want there to be some rudimentary knowledge of android before someone goes and flashes this and potentially messes up their phone.
Does that make sense? I feel that there should be a barrier to entry on kernels that OC and the like.
Click to expand...
Click to collapse
I do understand what your saying, I don't think its that much of a barrier though. There are many instructions throughout these boards that will let anyone who is even remotely interested flash a new kernel and push a .ko to their phone... The only reason why I want an update.zip is so that I can flash this on my phone to test it while I'm at work, it would also be nice to be able to switch quickly between kernels and whatnot. I don't have a computer that I can connect to via USB to run fastboot/adb so the only way I can get these on my phone is via a zip.
I don't think that a developer/hacker can be held responsible for others not knowing what issues can be caused by a voltage/clock tweak - especially with disclaimers up everywhere.
FettsVett said:
I do understand what your saying, I don't think its that much of a barrier though. There are many instructions throughout these boards that will let anyone who is even remotely interested flash a new kernel and push a .ko to their phone... The only reason why I want an update.zip is so that I can flash this on my phone to test it while I'm at work, it would also be nice to be able to switch quickly between kernels and whatnot. I don't have a computer that I can connect to via USB to run fastboot/adb so the only way I can get these on my phone is via a zip.
I don't think that a developer/hacker can be held responsible for others not knowing what issues can be caused by a voltage/clock tweak - especially with disclaimers up everywhere.
Click to expand...
Click to collapse
Oh I understand where you're coming from, and I would make you a private one, but I'm not home at the moment. However, for the general user, if they can't use fastboot, I don't want them anywhere near this. I hope someone makes you an update.zip!
I await the PM's!
Dear lord what am I going to do with this should I get my 2800mah battery? my phone will never die! lol
-Charlie
FettsVett said:
I await the PM's!
Click to expand...
Click to collapse
you can make one yourself.
grab boot.img from cyanogen's rom.
grab split_bootimg.pl from http://android-dls.com/files/linux/split_bootimg.zip
grab persiansown's zImage.
(in linux)
put all three in a folder. let's call it kernel.
while in the kernel folder:
./split_bootimg.pl boot.img
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel zImage-persiansown --ramdisk boot.img-ramdisk.gz -o boot-persiansown.img
(in windows)
download this: http://www.sendspace.com/file/kj2wi7
use winrar to open up that up, remove the boot.img in there and replace it with boot-persiansown.img (make sure it is named boot.img)
open up the update-script in META-INF folder (some levels down in there), and remove the format BOOT line (you'll be left with write_raw_image ... line), and save it.
grab this: http://www.relentlessaddictions.com/Androidstuff/signing.zip
unpack to your tools folder in your android-sdk folder distribution, and run autosign.bat. follow the prompts. once setup, you can right click on the .zip file with the boot.img in it to sign it, or you can execute from a cmd prompt: java testsign BOOT-IMG.zip
flash via custom recovery (which can flash .zip's signed with test keys).
you should be all set.
edit: mkbootimg can be found in prebuilt within AOSP distribution, or you can grab this precompiled one: http://forum.xda-developers.com/attachment.php?attachmentid=229872&d=1253485580

[kernel][v3.5] leanKernel: minimalistic kernel (1/28/16)

[kernel][v3.5] leanKernel: minimalistic kernel (1/28/16)
leanKernel is not for everyone.
My philosophy is to keep the kernel footprint as small as possible by trimming as much fat as possible, and at the same time keeping it stable, power efficient, and fast. leanKernel is designed to be a drop in replacement for stock kernel, and so it tries not to deviate too far from stock.
You will find that it's lacking some of the bells and whistles of other custom kernels, so if you like features you came to the wrong thread.
Here's a longer post on what leanKernel is about.
Also folks, please read the FAQ before asking questions.
INSTRUCTIONS
If you like to stay as close to stock as possible: 1) Download and flash the normal leanKernel build here (find the latest zip file) in recovery. 2) Reboot and enjoy better performance and battery life (hopefully). That's it! There's no need to flash stock kernel first, or to wipe caches.
If you like to customize, read through the feature list below, the FAQ (post #2), the changelogs, and optionally the entire thread. Then you'll know what to do.
DOWNLOAD (flash in recovery)
v1.x is for Android 5.0, and v2.x is for Android 5.1
main download
mirror (may need to refresh browser to see latest)
PREREQUISITE
Unlocked bootloader, custom recovery installed
Push bullet channel: imoseyon
FEATURES
custom voltage control - use your favorite app
updated to latest 3.10 Linux
interactiveX - screen_off_maxfreq support (default 2.2Ghz)
sw crypto drivers updated (to use arm NEON instructions) for better encryption/decryption performance. Sequential 180MB/s reads, 60MB/s writes (using dd)
latest Linaro gcc 4.9 toolchain (optimized for a15 - thanks to Christopher83)
fat trimmed and various performance tweaks
f2fs support (updated to latest source from Samsung)
force encryption turned off (changed to encryptable)
overclocked to 2.9ghz (experimental - available as a separate build for now)
underclocked to 223mhz (experimental - available as a separate build for now)
Async Fsync
init.d support
cpu-boost control - enable/disable via lkconfig
lkconfig script for customizing leankernel (open terminal app, become superuser, then type "lkconfig" without quotes)
patched mpdecision to prevent changing min/max freq provided as flashable zip (in util directory)
color control (thanks to @savoca)
charging led support
a lot of unnecessary stuff removed from stock kernel
some components updated to Linux 3.18
random generation optimization including e/frandom support
pc/usb charging with boosted current ~300-400mA
some selinux fixes, selinux is enforced by default - staying true to stock (you can easily disable using lkconfig)
SLUB allocator updated to Linux 3.18
wake gesture control from flar2, modified for leankernel (also disabled in-call)
vibe strength control
much of the code is up to date with latest from CodeAurora
(mostly for devs) /sys/module/selinux/parameters/force_audit sysfs node to audit all/hidden selinux denies.
power aware cpu scheduling
faux sound enable/disable by sysfs (and lkconfig)
wakelock control (smb135x, wlan_rx, msm_hsic and sensor_ind)
leanKernel core control script
user option to prevent mpdecision/msm_thermal from changing min/max frequencies: frequency mitigation preventer
supports kexec for multirom
LKCONFIG
You can use lkconfig script to make custom changes to leanKernel (along with popular apps like Kernel Tweaker and Trickstermod). To run lkconfig, open terminal app, "su" (without quotes) to become superuser, enter, and then type "lkconfig" without quotes, then enter.
Code:
[email protected]:/ $ su
[email protected]:/ # lk
leanKernel configurator
---
0) display current settings
1) cpu frequency control
2) wake gesture control
3) wakelock control
4) charging led
5) rgb/picture control (advanced)
6) rgb/picture control (simple)
7) vibe strength
8) power saving mode for cpu scheduler
9) faux sound control
10) selinux mode
11) min/max freq change prevention
21) check top 10 wake locks (ie. wakeup sources)
please enter a number (or press enter to exit):
CHANGELOG
https://github.com/imoseyon/leanKernel-shamu/wiki/Marshmallow-ChangeLog
Thanks to @guitarshredder87, @Wera750, @akellar, and @grisha1 for testing test builds!
XDA:DevDB Information
Leankernel: Minimalistic Kernel, Kernel for the Nexus 6
Contributors
Imoseyon
Source Code: https://github.com/imoseyon/leanKernel-shamu
Kernel Special Features:
Version Information
Status: Stable
Created 2014-11-26
Last Updated 2016-01-31
FAQ
I'm having trouble waking the phone sometimes. Help!
We haven't really figured out exactly what's causing it - but there seems to be evidence that it's not limited just to leanKernel. One thing to try: if your ROM has a feature that prevents accidental wakeups, disable it!
I can't seem to get min and max freq to stick! What are these mpdecision zip files in the util directory?
* Read this post: http://forum.xda-developers.com/showpost.php?p=58135730&postcount=1474
* Short version: This is actually by design of mpdecision. If you want this behavior to change, I recommend that you 1) flash latest stable leankernel, 2) flash the custom no-freq mpdecision, and then 3) disable cpu-boost via lkconfig. Do not disable mpdecision if you go this route. Also, if you flash ROM, you must re-flash custom mpdecision. To go back to normal, flash the stock mpdecision file.. Launch lkconfig, choose core control, and choose one of the options in core control.
Will flashing leankernel decrypt my phone storage?
If you're already encrypted, then it will stay encrypted after flashing kernel, *until* you format data. Once you format you will stay decrypted until you decide to encrypt again (see below). If you're already decrypted, leanKernel will not force encrypt automatically.
What do I do to encrypt again?
There are several ways to do this. One way (easiest for me at least) is to adb in (or in terminal emulator):
Code:
[email protected]:/ # start encrypt
You will see the phone hot boot and once it comes up you will be encrypted again. Keep in mind that if you want to decrypt again you'll have to wipe.
How do I check the PVS BIN of my cpu?
Code:
[email protected]:/ # cat /proc/cpu/msm_acpu_pvs
The number you get should range between 0 and 15 (inclusive). If you ended up with 15 congratulations. If you ended up with 0, go get it exchanged! Stock frequency/voltage table: http://pastebin.com/ZyGA9Tec
Which kernel control app do you recommend?
When v1.0 gets released it should come with "lkconfig" for tweaking some of the options. Otherwise, I tried Trickster and KernelTweaker, and they both seem to work ok.
What are ondemandX and interactiveX?
ondemandX and interactiveX are very very close to "stock" ondemand and interactive governors, respectively. The only difference is screen_off_maxfreq sysfs support. This means that it gives you the ability to limit phone's max frequency when screen is off. This feature could be effective in reducing battery usage, especially if you have a misbehaving app (or two) that consume cpu cycles while screen is off. The default value is 2265600 - if you change the value to your top speed you're effectively disabling the feature and restoring stock behavior completely. You can use an app like Trickster or Kernel Tweaker to modify screen_off_maxfreq.
HELP! I messed up with lkconfig - how do I go back?
Do not fret. Flash lkconfig_cleaner.zip from the "util" directory.
(If you want to do this manually), reboot the phone into recovery, mount /data, and delete everything in /data/data/leankernel. Once things are back to normal, re-run lkconfig to re-do your settings.
What is cpu-boost?
Read this post: http://forum.xda-developers.com/showpost.php?p=57215289&postcount=535
What is the best RGB setting?
http://forum.xda-developers.com/showpost.php?p=57265483&postcount=620 (old)
http://forum.xda-developers.com/showpost.php?p=59092146&postcount=3017 (new)
What is power aware scheduling?
Read this post: http://forum.xda-developers.com/showpost.php?p=58313978&postcount=1651
I missed your kernel when I switched to N5. Glad to have you here
hmm.. a kernel. since its the first one posted here, im trying it out
Hell yeah. Ready to flash
Sent from my AOSP on Shamu using XDA Free mobile app
If I flash this it will decrypt right cool
digweed4me said:
If I flash this it will decrypt right cool
Click to expand...
Click to collapse
It should not decrypt if you're already encrypted, unless you re-format/wipe. But no guarantees.
Imoseyon said:
It should not decrypt if you're already encrypted, unless you re-format/wipe. But no guarantees.
Click to expand...
Click to collapse
What app should we use to control? I remember you used to have your app right
holy **** Imoseyon. you made my Thunderbolt usable way back when. so glad to see you developing for the N6 now
digweed4me said:
What app should we use to control? I remember you used to have your app right
Click to expand...
Click to collapse
Flashed it and yes decrypted thanks a lot
IMO!! Good to see ya again man. Can't wait to run your work again.
Appreciate it!
digweed4me said:
What app should we use to control? I remember you used to have your app right
Click to expand...
Click to collapse
You mean lkconfig? Yeah that's coming later (along with a whole lot more).. If you're talking about f2fs, you'd want to use custom recovery but TWRP for shamu doesn't support f2fs yet - i had to do everything manually.
Imoseyon said:
It should not decrypt if you're already encrypted, unless you re-format/wipe. But no guarantees.
Click to expand...
Click to collapse
i am still encrypted, and did not decrypt after flashing. so, all worked as it should.
Can we flash on stock ROM or is a custom ROM required?
So let me see if I get this straight: I'm on stock, unlocked bootloader, rooted, and encrypted (as far as I know--I never decrypted), so if I flash this it won't decrypt my device? I was kinda hoping it would.
Secondly, I'm good to flash this with stock ROM? I'm hoping for a bit better battery life.
Thanks devs! I got a feeling development for our device is gonna be NUTS!!
You don't buy a Mustang for the gas mileage.
nycdiplomat said:
Can we flash on stock ROM or is a custom ROM required?
Click to expand...
Click to collapse
I'm on a stock ROM.
pathtologos said:
So let me see if I get this straight: I'm on stock, unlocked bootloader, rooted, and encrypted (as far as I know--I never decrypted), so if I flash this it won't decrypt my device? I was kinda hoping it would.
Secondly, I'm good to flash this with stock ROM? I'm hoping for a bit better battery life.
Thanks devs! I got a feeling development for our device is gonna be NUTS!!
You don't buy a Mustang for the gas mileage.
Click to expand...
Click to collapse
wipe before flashing, youll be decrypted. if you dont wipe, you stay encrpted.
pathtologos said:
So let me see if I get this straight: I'm on stock, unlocked bootloader, rooted, and encrypted (as far as I know--I never decrypted), so if I flash this it won't decrypt my device? I was kinda hoping it would.
Secondly, I'm good to flash this with stock ROM? I'm hoping for a bit better battery life.
Thanks devs! I got a feeling development for our device is gonna be NUTS!!
You don't buy a Mustang for the gas mileage.
Click to expand...
Click to collapse
AFAIK, there's no way to decrypt without having to wipe unfortunately. Going the other way (unencrypted to encrypted) is super easy though, and no data loss.
nycdiplomat said:
Can we flash on stock ROM or is a custom ROM required?
Click to expand...
Click to collapse
im on rastapop, an aosp based custom rom.
simms22 said:
wipe before flashing, youll be decrypted. if you dont wipe, you stay encrpted.
Click to expand...
Click to collapse
Thanks for your quick response. Wipe what tho? Cache, dalvik, and what else? Hope you don't mean all my data.
You don't buy a Mustang for the gas mileage.

Kexec-hardboot patch

In this post, I would like to explain what kexec-hardboot patch is.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 6. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a common thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot kexec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Unlike grouper's kexec-hardboot patch, this one only requires the host kernel to be patched. This is one of the improvements I made, and I think it is pretty significant.
To summarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Kernel patch: https://gist.github.com/Tasssadar/757c939f2d028c00d089, 5.1 AOSP kernel repo
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
# CONFIG_ATAGS_PROC is not set
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y #this one is turned on by default
All these options must be enabled.​
Userspace kexec binary: https://github.com/Tasssadar/kexec-tools
I had to change some things in kexec userspace binary because of some kernel bugs, complete description is in that repository.​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu --dtb
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
For hammerhead, I've improved the patch a bit - only the host needs to be patched now and I've added support for DTB.
For shamu, it's pretty much the same as for hammerhead.
@Tasssadar, I'm trying to incorporate the patch in my kernel (LiquidSmooth, which I compile in-line with the ROM - sources below), but I'm having issues actually booting into the secondary ROM.
Here is the portion of the log that contains the kexec call failure.
I just can't seem to figure out what my issue is - any ideas?
My device tree
My kernel source
Other potentially relevant info:
- Building the kernel in-line (using "make bootimage" for kernel incremental testing purposes)
- 5.0.2 base for host (my) kernel
- Using standard GCC for builds
- Updated to most recent MR TWRP and zip releases
Any help you might have to offer would be awesome!
CPA Poke said:
@Tasssadar, I'm trying to incorporate the patch in my kernel (LiquidSmooth, which I compile in-line with the ROM - sources below), but I'm having issues actually booting into the secondary ROM.
Here is the portion of the log that contains the kexec call failure.
I just can't seem to figure out what my issue is - any ideas?
My device tree
My kernel source
Other potentially relevant info:
- Building the kernel in-line (using "make bootimage" for kernel incremental testing purposes)
- 5.0.2 base for host (my) kernel
- Using standard GCC for builds
- Updated to most recent MR TWRP and zip releases
Any help you might have to offer would be awesome!
Click to expand...
Click to collapse
Looks like you didn't enable the config options mentioned in the first post. Also, please don't merge my hack to force-enable serial console, it doesn't play well with multirom. Also, you can enable the console by running "fastboot oem config console true", which I didn't know when I made that commit.
Tasssadar said:
Looks like you didn't enable the config options mentioned in the first post. Also, please don't merge my hack to force-enable serial console, it doesn't play well with multirom. Also, you can enable the console by running "fastboot oem config console true", which I didn't know when I made that commit.
Click to expand...
Click to collapse
[emoji33] [emoji40]
I literally can't even right now. Can't believe I missed that...rebuilding now, hopefully that takes care of it.
And thanks for the fastboot tip, I'll revert that hack.
Please keep the thread on topic for the section. If you aren't sure, read this: http://forum.xda-developers.com/nexus-6/devs-only/section-guidelines-read-t2959988
@Tasssadar, would this be better here in dev discussion (where I'm supposed to be an anal retentive moderator) or in "original development"? The reason for my asking is that your message states it's a release, as opposed to a discussion of the process of creating.
In the meantime, I've cleaned the thread...
Take care
Gary (posting as moderator of the dev discussion section.)
I put the patch here because it is quite different from most things posted in original development. It's pretty much for kernel devs only, and putting it in this section ensures it won't get lost (after couple of initial comments, there usually isn't any discussion related to this patch) and filters out most "thx" and "lolwhatsthis" posts (although obviously not all of them). I honestly didn't look up what's the exact goal of this section, it just seemed just right for this kind of thing. If you think it belongs to original development, feel free to move this topic.
Tasssadar said:
I put the patch here because it is quite different from most things posted in original development. It's pretty much for kernel devs only, and putting it in this section ensures it won't get lost (after couple of initial comments, there usually isn't any discussion related to this patch) and filters out most "thx" and "lolwhatsthis" posts (although obviously not all of them). I honestly didn't look up what's the exact goal of this section, it just seemed just right for this kind of thing. If you think it belongs to original development, feel free to move this topic.
Click to expand...
Click to collapse
Hey I don't know if you compile with ndk or cross compile for arm (statically or ndk) but I had to add some missing includes in *kexec/arch/arm/Makefile for kexec-tools to compile with the new board option. Just thought I'd mention.
https://github.com/Surge1223/androi...mmit/4b4629db76d64b7048274748d3e3366b52e1017d
Also, Ignore the other stuff. Testing kexec via module for locked devices so I have quite a bit of changes compared to regular kexec-tools.

[Q&A][ROM][STOCK, CUSTOM] Lenovo Tab 3 8/TB3-850F

Lenovo Tab 3 8/TB3-850F
Question & Answer Forum
Link & General Resource Guide
RE: Stock & Custom ROM(s)​
INTRODUCTION & PURPOSE:
I have started this thread as a Q&A forum and general info guide for my Stock 6.0 ROM for the Lenovo Tab 3 8, and as a forum for my stock-based custom ROM which is nearing completion. In addition, I have posted some useful threads for this device below. It has been brought to my attention by XDA Senior Member @pndwal, as well as other members, that topics regarding systemless rooting, dm-verity, force encryption, Trusted Execution Environment (/tee1 & /tee2), etc., need a dedicated forum for open discussion and brain-storming, all while adhering to XDA's policy of staying on topic in the device threads. In addition to the topics outlined, this forum welcomes any questions, concerns and colloquy regarding ROMs, kernels, recoveries, & other development for this device.
LENOVO TAB 3 8/TB3-850F LINKS:
Stock Android 6.0 ROM Thread: https://forum.xda-developers.com/android/general/rom-lenovo-tab-3-8-tb3-850f-t3617594
Bootloader, TWRP & Rooting: https://forum.xda-developers.com/android/general/guide-lenovo-tab3-8-tb3-850f-t3559786/page17
Unbricking/Restoration Tutorial: https://forum.xda-developers.com/android/help/lenovo-tab-3-8-tb3-850f-unbrick-root-t3598727
Stock Firmware Partition Images: https://forum.xda-developers.com/android/general/rom-lenovo-tab-3-8-tb3-850f-android-6-0-t3593043
Lenovo Tab 3 8" User Manual (PDF)
for TB3-850F & TB3-850M: English: https://drive.google.com/file/d/18gCTfuZecJnlB0ddBIN02YPaDpuvmzov/view?usp=drivesdk
Lenovo File Manager (APK): https://forum.xda-developers.com/android/general/app-lenovo-file-manager-lenovo-tab-3-8-t3706161
RULES:
Rule 1: Be respectful to XDA policies and to one another. We are all here to learn and to grow. The only stupid question is a question not asked;
Rule 2: Read Rule 1.
MotoJunkie01 said:
It has been brought to my attention by XDA Senior Member @pndwal, as well as other members, that topics regarding systemless rooting, dm-verity, force encryption, Trusted Execution Environment (/tee1 & /tee2), etc., need a dedicated forum for open discussion and brain-storming, all while adhering to XDA's policy of staying on topic in the device threads.
Click to expand...
Click to collapse
MotoJunkie01 said:
@pndwal I would like to invite you, first & foremost, to the ROM Q&A for this tablet. I'm hopeful that the Q&A will provide answers to relevant questions like yours, and provide input, user experiences, & ideas for future ROM development for the Tab 3 8.
Click to expand...
Click to collapse
A generous interpretation... Thanks for invitation. I'll be sure to come up with a curly one or two.
For now, could you give a rough idea of what needed changing to bypass force encryption? And also, reasons for pre-rooting? Thanks, PW.
pndwal said:
A generous interpretation... Thanks for invitation. I'll be sure to come up with a curly one or two.
For now, could you give a rough idea of what needed changing to bypass force encryption? And also, reasons for pre-rooting? Thanks, PW.
Click to expand...
Click to collapse
Reasons for pre-rooting are merely as a convenience to the user. Many users will use the stock build I compiled and root themselves, while others will take the more convenient route and flash the ROM which is pre-rooted. The advantages of the rooted ROM are that it will be moderately debloated, deodexed, zipaligned, and will of course have BusyBox binaries pre-injected and the Magisk Systemless User Interface installed.
To bypass force encryption, I first needed to bypass dm-veriity. Both are enabled by default on this tablet within the ramdisk/fstab. So the boot image needed to be unpacked, the values of "1" enabling both dm-verity & force encryption needed to be changed to values of "0", thus disabling both features. The boot image was then repacked and then archived within my ROM installation package (zip).
I'd also like to take a poll to ask whether members want Viper4AndroidFX v2.5.0.5 (with NEON audio drivers) on the custom ROM, in lieu of the Dolby Digital Sound audio package that comes pre-installed on the tablet. Any input would be appreciated.
MotoJunkie01 said:
I'd also like to take a poll to ask whether members want Viper4AndroidFX v2.5.0.5 (with NEON audio drivers) on the custom ROM, in lieu of the Dolby Digital Sound audio package that comes pre-installed on the tablet. Any input would be appreciated.
Click to expand...
Click to collapse
Viper can be installed as a module in magisk. PW
pndwal said:
Viper can be installed as a module in magisk. PW
Click to expand...
Click to collapse
Yes it can, but it breaks the stock camera completely, due to the SELinux policy mod which is installed by the module. If included as a feature of the ROM, I have a workaround which sets SELinux to permissive on boot, instead of permanently disabling the policy from within the kernel. This prevents breaking of the stock camera.
MotoJunkie01 said:
Yes it can, but it breaks the stock camera completely, due to the SELinux policy mod which is installed by the module. If included as a feature of the ROM, I have a workaround which sets SELinux to permissive on boot, instead of permanently disabling the policy from within the kernel. This prevents breaking of the stock camera.
Click to expand...
Click to collapse
I did that in past too. Don't think its needed now.
Viper working fine for me as Magisk module (phone and TB3-850f tablet). SELinux enforcing, camera working fine (incl. video), 2.5.0.4 driver, 2.5.0.5 app.
Seems SELinux policy change no longer required as V4A module for Magisk installs AML (Audio Modification Library) as Magisk framework which no longer requires permissive. Let me know if I'm missing something. PW.
pndwal said:
I did that in past too. Don't think its needed now.
Viper working fine for me as Magisk module (phone and TB3-850f tablet). SELinux enforcing, camera working fine (incl. video), 2.5.0.4 driver, 2.5.0.5 app.
Seems SELinux policy change no longer required as V4A module for Magisk installs AML (Audio Modification Library) as Magisk framework which no longer requires permissive. Let me know if I'm missing something. PW.
Click to expand...
Click to collapse
You are pretty well correct. But, in order to enjoy the full spectrum of the NEON audio drivers, SELinux must go permissive. The Viper version I am speaking of was compiled by Deuteronomy Sound Technologies (and Arise) and is known as Viper4 AriseFX (a modded, themeable, and undoubtedly the most feature packed Viper package available for Android). The Viper module available on Magisk is a bare bones package, and when used in combination with my patched boot image (due to SELinux policy) it breaks the stock camera and causes other instabilities within the ROM.
I'm working also on a custom kernel for the TB3-850F, which will have some audio tweaks available from the kernel itself, as well as some tuneable governors, preset TCP congestion algorithms, etc.
MotoJunkie01 said:
You are pretty well correct. But, in order to enjoy the full spectrum of the NEON audio drivers, SELinux must go permissive. The Viper version I am speaking of was compiled by Deuteronomy Sound Technologies (and Arise) and is known as Viper4 AriseFX (a modded, themeable, and undoubtedly the most feature packed Viper package available for Android). The Viper module available on Magisk is a bare bones package, and when used in combination with my patched boot image (due to SELinux policy) it breaks the stock camera and causes other instabilities within the ROM.
I'm working also on a custom kernel for the TB3-850F, which will have some audio tweaks available from the kernel itself, as well as some tuneable governors, preset TCP congestion algorithms, etc.
Click to expand...
Click to collapse
I see. Perhaps you could explain the benefits of neon audio - I wasn't aware.
Also, would permissive SELinux not break SafetyNet check? Thanks, PW.
pndwal said:
I see. Perhaps you could explain the benefits of neon audio - I wasn't aware.
Also, would permissive SELinux not break Safety net check? Thanks, PW.
Click to expand...
Click to collapse
Yes and no. Depending on how you set the SELinux policy. I've found that setting SELinux to permissive on boot only, by way of a third party app like Kernel Adiutor-Mod or The SELinux Toggler, does not break SafetyNet. However, permanently disabling SELinux as enforcing, by way of modding the kernel itself, has been reported to cause a SafetyNet fail on both custom and stock ROMs.
You raise a good question though, and it is a factor to which I'll be paying close attention during development for this tablet.
I think I've decided to include Viper4AriseFX in my ROM as optional, and available by flashing a separate zip installer subsequent to installing the ROM itself.
By the way @pndwal, you seem to know your way around Android pretty well. What are some other features you would like to see in a custom built ROM for the Tab 3 8?
MotoJunkie01 said:
Yes and no. Depending on how you set the SELinux policy. I've found that setting SELinux to permissive on boot only, by way of a third party app like Kernel Adiutor-Mod or The SELinux Toggler, does not break SafetyNet. However, permanently disabling SELinux as enforcing, by way of modding the kernel itself, has been reported to cause a SafetyNet fail on both custom and stock ROMs.
You raise a good question though, and it is a factor to which I'll be paying close attention during development for this tablet.
I think I've decided to include Viper4AriseFX in my ROM as optional, and available by flashing a separate zip installer subsequent to installing the ROM itself.
Click to expand...
Click to collapse
Optional install sounds like a good idea, especially if SELinux permissive is optional to. I'm hesitant to use permissive environment as many apps etc require enforcing, and attempts to circumvent this, eg Magisk's ability to hide permissive etc, are reportedly not foolproof.
Not sure about attraction with Neon and ARISE, but seems permissive SELinux requirement to use these may be short-lived anyway. See post from today, at https://forum.xda-developers.com/an...d-systems-auditory-research-t3379709/page3125
problem:
NEON Enabled: No
Enabled: No
Status: Abnormal
ETC...
How solve it please?
Magisk 14.3 thats why. You need permissive. ARISE hasnt been updated for the new changes to how magisk handles selinux. Just for now you'll need to switch to permissive to get viper to work. Hopefully we'll have a build up soon to make it work, I know that ZackPTG and Ghost started to update it although i'm not sure on progress.
Hope it helps, PW.
pndwal said:
Optional install sounds like a good idea, especially if SELinux permissive is optional to. I'm hesitant to use permissive environment as many apps etc require enforcing, and attempts to circumvent this, eg Magisk's ability to hide permissive etc, are reportedly not foolproof.
Not sure about attraction with Neon and ARISE, but seems permissive SELinux requirement to use these may be short-lived anyway. See post from today, at https://forum.xda-developers.com/an...d-systems-auditory-research-t3379709/page3125
problem:
NEON Enabled: No
Enabled: No
Status: Abnormal
ETC...
How solve it please?
Magisk 14.3 thats why. You need permissive. ARISE hasnt been updated for the new changes to how magisk handles selinux. Just for now you'll need to switch to permissive to get viper to work. Hopefully we'll have a build up soon to make it work, I know that ZackPTG and Ghost started to update it although i'm not sure on progress.
Hope it helps, PW.
Click to expand...
Click to collapse
I've got Viper4AriseFX fully functional with Magisk v14.3. SafetyNet pass. I'm using a method which does not permanently set SELinux to permissive, but which toggles it to permissive only upon boot.
My pre-patched boot image is probably key to the successful installation as well. I'll list a complete change log of the exact mods once my beta release is ready. From what I'm gathering on logcat, Viper4AriseFX is "seeing" SELinux as permissive, while other system components are seeing the policy as enforcing. I believe I've stumbled upon the key to this SELinux policy dilemma.
MotoJunkie01 said:
By the way @pndwal, you seem to know your way around Android pretty well. What are some other features you would like to see in a custom built ROM for the Tab 3 8?
Click to expand...
Click to collapse
No really unique ideas, but interested in improved performance (speed and battery), battery being pretty good already.
MT8161p CPU specs say Quad-Core, 1.3 GHz, but TB3-850f is limited to 1.0 GHz, so a kernel modified to allow overclocking should achieve 30% boost easily (and CPU can usually go ~30% higher than specs, so perhaps 1.7 GHz or so would be achievable) unless I'm missing something.
Could improve Adoptive Memory (SD) handling, but may have to wait for port to N or O for this as anomalies with handling Dev. manifest values to make moveable apps automatically go to SD (as well as not allowing some even to be moved manually that should move fine) seem to an Android M limitation. (Works beautifully/ as expected on my phone with lineage N, and if Dev. hasn't enabled 'move apps to SD', can 'Force allow apps on external' in Developer Options [Makes any app eligible to be written to external storage, regardless of manifest values].) Guess N / O may be a way off, but would be nice.
Lenovo is now pushing ~30MB OTA update to TB3-850F_S100031_171010_ROW, so you'll probably want to capture / incorporate this in your ROM. (Is it possible to modify OTA update to allow flashing on rooted devices without restoring stock recovery? [Edit: Seems this would require merging differential update with complete files updated, and likely should only be flashed as complete ROM unless stock restored. Saw this: https://twrp.me/faq/officialota.html]) This is not available as a complete downloadable ROM on Russian Websites (lenovo-forums.ru or 4pda.ru) or others as yet as far as I can see.
Hope ideas are helpful, PW.
pndwal said:
No really unique ideas, but interested in improved performance (speed and battery), battery being pretty good already.
MT8161p CPU specs say Quad-Core, 1.3 GHz, but TB3-850f is limited to 1.0 GHz, so a kernel modified to allow overclocking should achieve 30% boost easily (and CPU can usually go ~30% higher than specs, so perhaps 1.7 GHz or so would be achievable) unless I'm missing something.
Could improve Adoptive Memory (SD) handling, but may have to wait for port to N or O for this as anomalies with handling Dev. manifest values to make moveable apps automatically go to SD (as well as not allowing some even to be moved manually that should move fine) seem to an Android M limitation. (Works beautifully/ as expected on my phone with lineage N, and if Dev. hasn't enabled 'move apps to SD', can 'Force allow apps on external' in Developer Options [Makes any app eligible to be written to external storage, regardless of manifest values].) Guess N / O may be a way off, but would be nice.
Lenovo is now pushing ~30MB OTA update to TB3-850F_S100031_171010_ROW, so you'll probably want to capture / incorporate this in your ROM. (Is it possible to modify OTA update to allow flashing on rooted devices without restoring stock recovery? [Edit: Seems this would require merging differential update with complete files updated, and likely should only be flashed as complete ROM unless stock restored. Saw this: https://twrp.me/faq/officialota.html]) This is not available as a complete downloadable ROM on Russian Websites (lenovo-forums.ru or 4pda.ru) or others as yet as far as I can see.
Hope ideas are helpful, PW.
Click to expand...
Click to collapse
You may have read the wrong specs. There has been much confusion between the TB3-850M (which runs on the MT8161p), and the TB3-850F (which runs on the MT6735m). A lot of online sources have misstated the board platforms on these two tablets.
My TB3-850F build.prop clearly lists the board platform as MT6735m, as does the hardware reading given by the SP Flash Tool when I sync the device on my PC. I wish mine did have the MT8161 (1.3GHz) versus the 1.0GHz of my MT6735.
But just to be certain there are not variants of the TB3-850F, read your build.prop via file explorer or build prop editor and let me know if yours is in fact the MT8161p.
Thanks for the heads up on the OTA. I wasn't aware of it and I'll definitely be updating my stock ROM thread accordingly.
Oh to answer your question on the OTAs, yes you can flash an OTA to a rooted/modified device by editing the updater-script and omitting the crypto-hash checks performed during the typical OTA installation, and by editing the incremental target and source lines (or omitting them entirely).
Just got the 33mb OTA captured. Looks like there are the usual bug fixes & stability improvements, but also the KRACK exploit has been patched, the partition index updated, and kernel updates. I'm currently compiling an up-to-date stock ROM with TWRP flashable installer.
MotoJunkie01 said:
You may have read the wrong specs. There has been much confusion between the TB3-850M (which runs on the MT8161p), and the TB3-850F (which runs on the MT6735m). A lot of online sources have misstated the board platforms on these two tablets.
My TB3-850F build.prop clearly lists the board platform as MT6735m, as does the hardware reading given by the SP Flash Tool when I sync the device on my PC. I wish mine did have the MT8161 (1.3GHz) versus the 1.0GHz of my MT6735.
But just to be certain there are not variants of the TB3-850F, read your build.prop via file explorer or build prop editor and let me know if yours is in fact the MT8161p.
Thanks for the heads up on the OTA. I wasn't aware of it and I'll definitely be updating my stock ROM thread accordingly.
Oh to answer your question on the OTAs, yes you can flash an OTA to a rooted/modified device by editing the updater-script and omitting the crypto-hash checks performed during the typical OTA installation, and by editing the incremental target and source lines (or omitting them entirely).
Click to expand...
Click to collapse
Yes, I'd forgotten this confusion.
Actually, didn't check online sources, but assumed Phone Tester was reporting correctly. It gives CPU Info: MT8161p.
Just checked Kernel Auditor which gives MT8161p as vendor, but MT6735 as hardware.
CPU-Z gives MT6735 as SoC.
My build.prop also gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P.
Russian 4PDA forum gives 850f Processor Type: MT8161, with MT8735 for 850M variant. (http://4pda.ru/devdb/lenovo_tab3_8:850f)
So it's hard to know what or who's correct, but looks to me that newer CPUs have likely been installed on boards originally designed for MT6735. (My CPU could actually be MT8735 as given by build.prop if Lenovo had excess chips from 850M, or simply decided to use these in both models. - I guess they may even have started with MT6735 for 850f before progressively using MT8161 and MT8735.)
So seems to me to be in the realms of possibility that a kernel allowing overclocking may just render spectacular results (as long as later CPUs were in fact used, and these are not crippled by an older board chipset.) But then, I may be way off base . . . Let me know your thoughts. PW.
pndwal said:
Yes, I'd forgotten this confusion.
Actually, didn't check online sources, but assumed Phone Tester was reporting correctly. It gives CPU Info: MT8161p.
Just checked Kernel Auditor which gives MT8161p as vendor, but MT6735 as hardware.
CPU-Z gives MT6735 as SoC.
My build.prop also gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P.
Russian 4PDA forum gives 850f Processor Type: MT8161, with MT8735 for 850M variant. (http://4pda.ru/devdb/lenovo_tab3_8:850f)
So it's hard to know what or who's correct, but looks to me that newer CPUs have likely been installed on boards originally designed for MT6735. (My CPU could actually be MT8735 as given by build.prop if Lenovo had excess chips from 850M, or simply decided to use these in both models. - I guess they may even have started with MT6735 for 850f before progressively using MT8161 and MT8735.)
So seems to me in the realms of possibility that a kernel allowing overclocking may just render spectacular results (as long as later CPUs were in fact used, and these are not crippled by an older board chipset.) But then, I may be way off base . . . Let me know your thoughts. PW.
Click to expand...
Click to collapse
Yeah I agree with you wholeheartedly that overclocking - at least moderately - could provide some benefit. I'm seeing that our current 1.0GHz maximum clock could safely be overclocked to about 1.33GHz. Definitely something I will be considering. I've been able to optimize this device's meager 1GB RAM by zipaligning the apk files, and by setting a maximum background process limit to build.prop. I've also found that setting the stock kernel's Adaptive Low Memory Killer to Very Aggressive helps as well.
I've installed the OTA and it seems to improve general stability of the device, and provides us with much needed security patches. I'll be updating my stock ROM to the most recent version later today. Here is a link to the captured OTA if anyone is interested in exploring it. However, in order to flash it to a rooted/modified device, the updater-script first needs to be modified. But again, I'll have the updated build posted later today.
OTA_TB3-850F_S100031_171010_ROW: https://drive.google.com/file/d/11xo-7X06ST1RV8X5TJHjM5o2MHfcsNhl/view?usp=drivesdk
MotoJunkie01 said:
Yeah I agree with you wholeheartedly that overclocking - at least moderately - could provide some benefit. I'm seeing that our current 1.0GHz maximum clock could safely be overclocked to about 1.33GHz. Definitely something I will be considering. I've been able to optimize this device's meager 1GB RAM by zipaligning the apk files, and by setting a maximum background process limit to build.prop. I've also found that setting the stock kernel's Adaptive Low Memory Killer to Very Aggressive helps as well.
I've installed the OTA and it seems to improve general stability of the device, and provides us with much needed security patches. I'll be updating my stock ROM to the most recent version later today. Here is a link to the captured OTA if anyone is interested in exploring it. However, in order to flash it to a rooted/modified device, the updater-script first needs to be modified. But again, I'll have the updated build posted later today.
OTA_TB3-850F_S100031_171010_ROW: https://drive.google.com/file/d/11xo-7X06ST1RV8X5TJHjM5o2MHfcsNhl/view?usp=drivesdk
Click to expand...
Click to collapse
Great. What do you make of build.prop entry: ro.lenovo.cpuinfo=MT8735P? PW.
pndwal said:
Great. What do you make of build.prop entry: ro.lenovo.cpuinfo=MT8735P? PW.
Click to expand...
Click to collapse
It's simply a typo that was made in build.prop I believe. Going by ro.board.platform, they seem to have it correct with the 6735 entry. I was just messing with some components of the unpacked boot image from this device, and it seems that except for the SoC differences, the 850M and 850F are otherwise identical. Of course, the 850M, by way of its mt8161p, has full SIM & 4G/LTE data support. In our variant, the SIM slot (next to the micro SD card slot) is blocked off, whereas it's fully accessible in the 850M.
P.S, if you're rooted, add this line to build.prop and let me know if you see a difference in RAM optimization: ro.config.low_ram=true

Development [Kernel][GKI][05.03.2023][Android 13] Kirisakura 1.0.3 for Sony Xperia 1 IV aka "Nagara"

Kirisakura-Kernel for the Sony Xperia 1 IV
Hello everyone,
To keep it short: Here is Kirisakura- GKI - Kernel for the Sony Xperia 1 IV aka Nagara. Nagara is the internal codename for this years development platform of Sony Mark IV devices.
I would appreciate if everybody that flashes the kernel, reads at least once through this opening post and the following ones.
Kirisakura - Kernel is designed to bring a handful of beneficial features to the device, while ensuring excellent performance and smoothness to get you safely through the day!
If you expect a custom kernel to magically improve your devices battery life manifold and this is your only priority then this might not be the right place for you.
There´s also a cpu-battery saver mode that cuts back the CPU max- freqs, but without the disadvantages like delayed notifications from built into the system user-space power-saving modes.
If that got your curious, I welcome you to continue reading if you´re still interested!
Now lets continue with a list of features in the next paragraph!
Main Features:
- Based on kernel/common 5.10.149
- compiled with Clang 12.0.5
- CPU-Battery saver to be able to restrict max cpufreqs on the fly, without enabling powersaving modes that might cause missed notifications (see second post)
- SSG IO scheduler for reduced overhead and less CPU cycles (more lightweight and android optimized)
- Power saving workingqueues enabled by default
- Change various drivers to use power efficient workingqueues. This compliments EAS in general
- implement LRNG (thanks @arter97, see arter kernel OP for more info )
- Enable support for TTL spoofing
- wakelock blocker with the ability to block any wakelocks (dangerous, use with caution)
- please read [URL="https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/"]this for further info
- f2fs improvments for better efficiency
- scheduler improvements
- psi fixes
- Flashing the kernel will keep root!
- Flashable via EXKM, FKM or TWRP (if available) on a rooted system!
Flashing Guide, Download and Changelog
Requirements:
- unlocked Bootloader
- USB-Debugging in developer options enabled
- latest adb and fastboot binaries
- working adb and fastboot environment
- magisk root
- a backup of stock boot.img or your magisk patched boot.img in case you want to go back to stock.
How to flash the Kernel:
1. Download the latest kernel.zip and make sure you have properly updated to the latest matching Firmware (check the feature list for the current firmware the source is based on). When there´s an OTA update for the Sony Xperia 1 IV it takes Sony a while to release the source code for the new OS and me a while to build a new kernel. If you don´t want to face any issues, wait until I either release an updated kernel or give green light because there were no kernel changes.
If you want to be sure there are no issues, always make sure to run the firmware the kernel is built for!
If you feel adventurous and try in advance, make sure you have a backup ready!
2. Flash the kernel.zip via latest TWRP (if available), EXKM or FKM app and do a full reboot.
3. Reboot and profit.
DOWNLOAD:
Download is located always in this folder, or attached to the release posts in case AFH is wonky.
https://www.androidfilehost.com/?w=files&flid=335705
Important: Read after Download
Please take a look at the second post after flashing the kernel!
Changelog:
Android 12
1.0.0 Initial Release
Android 13
1.0.0 https://forum.xda-developers.com/t/...-xperia-1-iv-aka-nagara.4480653/post-87711541
1.0.1 https://forum.xda-developers.com/t/...-xperia-1-iv-aka-nagara.4480653/post-87945391
1.0.3 https://forum.xda-developers.com/t/...-xperia-1-iv-aka-nagara.4480653/post-88241223
Donations:
Donations are not mandatory but very welcome if you want to support development or just buy me a coffee/tea
If you like my work: http://paypal.me/freak07
Credits:
Sony for the development device, giving me the opportunity to create this project!
@osm0sis for all his work, including the ak3 installer!
@tbalden for being the best HTC, Pixel, OnePlus and now Asus wingman!
@LeeDroid and @mwilky for their awesome roms and work I used on multiple devices!
@Captain_Throwback for all the mentoring and guidance!
@Eliminater74 for bringing me into the game and the Inspiration
@nathanchance for his upstream guidance and assistance
@RenderBroken for helping me out
@flar2 for all his work
@joshuous for all the help he provided to me in the past!
@arter97 for giving me advice
@kdrag0n for his help and advices!
@topjohnwu for magisk!
Source Code: https://github.com/freak07/Kirisakura_GKI_Nagara
F.A.Q:
Question: Is root preserved when flashing this kernel?
Answer: Yes, the AnyKernel.zip will detect root and keep it.
Question: Safetynet does not pass on my phone since I unlocked the phone, why is this so?
Answer: Google introduced hardware backed attestation recently. Unfortunately the old kernel tricks to still get safetynet passing won´t work. Instead you will have to rely on some magisk modules. Short guide in post #4 below.
Question: How do I return back to stock or another kernel.
Answer: Extract boot.img from the matching firmware you are on (you can do so by using this tool or similar ones found on XDA and when googling around) and flash via fastboot. If you want to keep root flash back the magisk_patched_boot.img. Or dirty flash your rom and re-root.
Question: Why is having Magisk installed mandatory for this kernel?
Answer: The kernel uses a ramdisk overlay to apply some settings after boot. If you are not rooted these settings will not get applied and you miss some of the optimizations.
Question: How to report bugs properly?
Answer: Have a look at post #3 in the linked thread. The linked guide is a pretty good starting point.
Before reporting any bug make sure you´re running on a stock configuration. That´s means you´re not using any mods, tweaks in kernel managers or other root tweaks , magisk modules, scripts or other modifications that alter various functions like sound mods, data traffic, sleeping behaviour, scheduler, magical battery tweaks etc.
Try to describe the issue as detailed as possible! Give your exact setup, like rom, magisk version, kernel version.
Is the issue reproducible? Does it happen frequently?
Provide logs, otherwise debugging is a lot harder. If you can already reproduce the issue and provide logs it greatly limits the amount of time I have to spent until I figure out how to reproduce it.
Feature Documentation:
Here´s a brief documentation about some of the features included in the kernel that can be changed as the user desires.
They can be accessed via either terminal, scripts or for example EXKM manager ( tools -> user settings).
CPU-Frequency Limiting:
Another option is CPU-Freq Limiting. You can now limit the CPU frequency to a few different levels with a sysfs interface. Original implementation is from @tbalden, I only changed it to be accessible via traditional root methods.
Main Switch:
sys/module/cpufreq/parameters/batterysaver
Set this option to "1" to enable the feature
Max-Frequency Selection (Input boosts, such as scrolling boost or app launching boosts will still apply, if touch boost restriction is not set to 1)
sys/module/cpufreq/parameters/batterysaver_level
Set this to "1" to restrict the max CPU-Freqs to 1,6GHZ/1,9GHZ/2,22GHZ (Little Cluster/Big Cluster/Prime Core)
Set this to "2" to restrict the max CPU-Freqs to 1,4GHZ/1,6GHZ/1,8GHZ (Little Cluster/Big Cluster/Prime Core)
Set this to "3" to restrict the max CPU-Freqs to 1,1GHZ/1,1GHZ/1,1GHZ (Little Cluster/Big Cluster/Prime Core)
Touch-Boost Restriction
sys/module/cpufreq/parameters/batterysaver_touch limiting
Set this to "1" to restrict the powerhal from boosting over the limit defined in batterysaver_level
Set this to "0" to allow the powerhal to boost above the values defined in batterysaver_level, but only during interaction with the Phone!
Screenshots:
View attachment 5309899View attachment 5309901View attachment 5309903
This is for example very useful during gaming to prevent additional heat, if not the highest performance from the CPU is required. Check if the game is running fine on level 1 or 2, and you´ll notice much less heat. Powerdraw will be reduced as well.
Another very useful trick while doing video calls or long extended navigation sessions with google maps to preserve battery or keep the phone from heating. Especially during summer if the ambient temperatures are high.
This is a very easy way to preserve battery or reduce heat without toggling the battery save mode in settings as that restricts background data usage, which can lead to delayed notifications.
How to pass Safetynet after unlocking the bootloader
With the introduction of hardware backed safetynet attestation, passing safetynet has become a lot more complicated.
Some probably remember a while ago, flashing a kernel that forced some flags was enough to pass it. However these days are gone.
Below is a short guide how to pass safetynet on phones that are flagged to use HW attestation (such as the ROG 5).
1. Make sure you´re running latest magisk canary.
2. In Magisk Manager enable both zygisk and deny list.
4. Download the latest Universal Safety Net Fix from @kdrag0n ´s github for zygisk cand flash it in Magisk Manager. Reboot.
5. Profit
Oh, my God! thank you so much for making the IV kernel
am I right to assume that CPU frequency limiting can help the phone not overheat when taking photos?
You are Awesome
tomatoketchup said:
am I right to assume that CPU frequency limiting can help the phone not overheat when taking photos?
Click to expand...
Click to collapse
yes. it should at least slow down the heat buildup. that´s the main goal behind it.
please note that 4k 120fps recording or other demanding tasks might not work without stutters if CPU gets restricted too much.
Apart from app loading times, if the usage is not super demanding level 3 works without major stutters in the UI on 120fps refresh rate.
htcmage said:
Oh, my God! thank you so much for making the IV kernel
Click to expand...
Click to collapse
Thaiban said:
You are Awesome
Click to expand...
Click to collapse
Freak07 said:
yes. it should at least slow down the heat buildup. that´s the main goal behind it.
please note that 4k 120fps recording or other demanding tasks might not work without stutters if CPU gets restricted too much.
Apart from app loading times, if the usage is not super demanding level 3 works without major stutters in the UI on 120fps refresh rate.
Click to expand...
Click to collapse
excellent <3, I don't need 4K 120fps recording I actually only do 1080p 24 because I like stabilization. so going to flash 64.0.A.8.25 and this kernel after that. million thanks!
It's a small amount, but I donated it, thank you always
htcmage said:
It's a small amount, but I donated it, thank you always
Click to expand...
Click to collapse
Thank you very much! I greatly appreciate it.
Hahaha... Hello my good friend @Freak07. Didn't know you were into Sony as well.
@Freak07 can you port it to xperia pro i ?
Developer, I have a question
If I use my work profile (shelter or island apk) I can't get into the settings menu I get a popup stating that the system UI is shutting down, maybe it's kernel related?
Should I uninstall Uperf before flashing?
Also thanks for this excellent work.
great work!Thx
to those who flashed, how is battery live ?
ist compüatible with latest sony update?
Would be interested to know, if it supports the old android kernels feature to emulate CD and DVD. Its a feature that DriveDroid needs to emulate a bootable DVD drive from an *.ISO hosted from an android device over USB. it was present in my older devices until XZ1 Compact and i was able to boot my pc off from a iso file hosted on my android device. It was much convinient than using silly PXE boot over eth0
No more update ?
Mrxyzl said:
No more update ?
Click to expand...
Click to collapse
OP will update when new Kernel sources are released and he has time. Mentioned in the first post.

Categories

Resources