KERNEL ❯ MI A1 ❯❯❯ Velocity Kernel • r9 • August 15

[kdrag0n]

KERNEL ❯ MI A1 ❯❯❯ Velocity Kernel • r9 • August 15

Velocity Kernel • Mi A1
by kdragon and tytydraco​

Flash at your own risk.

This kernel is abandoned. I suggest using other kernels such as Canting. Sorry for the inconvenience.

The original post follows.

Introduction
Velocity Kernel was made to provide the best possible experience on all devices. We strive to provide the perfect balance of performance and battery life. Features are also plentiful, but features that nobody uses will not be included. We also completely debloat all our kernels and aim for small sizes relative to other kernels. Due to the small size and careful debloating, boot time is also improved.

Compatibility
This single kernel ZIP supports both custom ROMs and Treble custom ROMs (GSIs). Simply flash the kernel after flashing your ROM of and it should work. Pie is fully supported.
The stock ROM is not supported.

Features

​ ​ ​ ​ • Latest upstream Linux LTS 3.18.118
​ ​ ​ ​ • CPU overclock to 2208 MHz for a good performance + battery balance
​ ​ ​ ​ • GPU overclock to 700 MHz
​ ​ ​ ​ • Undervolted CPU by 150 mV
​ ​ ​ ​ • Improved 3.5mm jack output
​ ​ ​ ​ • Energy Aware Scheduling
​ ​ ​ ​ • CPU governors: elementalx, zzmoove, yankactive, relaxed, alucard, nightmare, chill, blu_active, darkness, intelliactive, bioshock, impulse, ironactive, ondemandplus
​ ​ ​ ​ • EAS CPU governors: electroutil, schedutil, pwrutilx, sched, helix_schedutil, energy-dcfc, alucardsched, darknesssched
​ ​ ​ ​ • IO schedulers: fiops, zen, sioplus, row, tripndroid, maple, cfq, noop, deadline, bfq, fifo
​ ​ ​ ​ • Updated ExFAT drivers that support TRIM (faster long-term performance)
​ ​ ​ ​ • Compiled with latest Clang 8 revision 339049
​ ​ ​ ​ • Small size
​ ​ ​ ​ • Faster boot
​ ​ ​ ​ • Fast wakeup
​ ​ ​ ​ • Low latency
​ ​ ​ ​ • 500 Hz for maximum performance-latency-battery balance
​ ​ ​ ​ • ZRAM compressors: lzo, lz4, lz4hc, zstd (higher compressing)
​ ​ ​ ​ • Reduced pop when plugging headphones in
​ ​ ​ ​ • KCAL advanced color control
​ ​ ​ ​ • Wakelock blocker
​ ​ ​ ​ • Customizable CRC check and Fsync
​ ​ ​ ​ • Adreno Idler
​ ​ ​ ​ • Backlight dimmer (extremely low brightness)
​ ​ ​ ​ • Adreno Boost
​ ​ ​ ​ • Sound output control
​ ​ ​ ​ • Forced USB fast charge
​ ​ ​ ​ • Westwood TCP congestion control
​ ​ ​ ​ • Improved output on 3.5mm jack
​ ​ ​ ​ • Improved scrolling performance
​ ​ ​ ​ • Various optimizations from Google Pixel kernels
​ ​ ​ ​ • Faster NEON accelerated random data generator
​ ​ ​ ​ • Good battery life
​ ​ ​ ​ • Vibration intensity control
​ ​ ​ ​ • Double tap to wake
​ ​ ​ ​ • Latest WireGuard VPN snapshot
​ ​ ​ ​ • Removed legacy drivers
​ ​ ​ ​ • Sweep2wake, sweep2sleep, and doubletap2wake gestures
​ ​ ​ ​ • Updated Wi-Fi drivers
​ ​ ​ ​ • Optimized memory page copying
​ ​ ​ ​ • TCP ECN for faster internet on busy networks
​ ​ ​ ​ • DTS-Eagle support
​ ​ ​ ​ • Improved security
​ ​ ​ ​ • Full Kali NetHunter support (Bluetooth & Wi-Fi dongles)
​ ​ ​ ​ • Countless other improvements and optimizations
​ ​ ​ ​ • Flash and forget

Downloads
Downloads can be found here on GitHub.
The first release listed is the latest version.

Credits
Without the help and contributions of these people, this kernel would not exist:
​ ​ ​ ​ • nathanchance: upstreaming, kbuild commits, Flash kernel, many other commits
​ ​ ​ ​ • ghpranav: MetaPhoenix kernel, wake gestures on kernel_tissot (savoca, showp1984, ryan-andri), EAS, help, and more
​ ​ ​ ​ • franciscofranco: config options, fsync control, many other commits
​ ​ ​ ​ • Flex1911: Void kernel, base commits
​ ​ ​ ​ • flar2: old wake gestures, many other commits that shaped the kernel
​ ​ ​ ​ • frap129: Maple I/O scheduler (base for Marrow), Electron kernel, many other commits
​ ​ ​ ​ • Alek Dev: overclocking values for CPU and GPU, undervolting and overvolting values
​ ​ ​ ​ • nine7nine: EAS governors, EAS commits, optimized ext4 fsync, many other commits
​ ​ ​ ​ • gougous3: help with tuning Spectrum profiles, helix_schedutil tunables, ideas
​ ​ ​ ​ • Everyone else mentioned in Git history

Join our Telegram group here for betas

Enjoy!

Donate to support future development

XDA:DevDB Information
Velocity Kernel, Kernel for the Xiaomi Mi A1

Contributors
kdragon, tytydraco
Source Code: https://github.com/kdrag0n/velocity_tissot

Kernel Special Features:

Version Information
Status: Abandoned
Current Stable Version: r9
Stable Release Date: 2018-08-15

Created 2018-05-25
Last Updated 2019-01-23

 

[kdrag0n]

Changelogs
r9 • August 15, 2018

​ ​ ​ ​ • Linux 3.18.118
​ ​ ​ ​ • CAF LA.UM.6.6.r1-09200-89xx.0
​ ​ ​ ​ • Updated Wi-Fi drivers
​ ​ ​ ​ • Compiled with Clang 8 revision 339049
​ ​ ​ ​ • Significant increases in security
​ ​ ​ ​ • Faster app opening
​ ​ ​ ​ • Smoother UI
​ ​ ​ ​ • Faster wakeup (power + fingerprint)
​ ​ ​ ​ • Lower latency
​ ​ ​ ​ • Balanced custom 500 Hz timer
​ ​ ​ ​ • Improved battery life
​ ​ ​ ​ • Optimized low memory killer
​ ​ ​ ​ • Disabled unnecessary CPU bug workarounds (overhead)
​ ​ ​ ​ • Disabled useless drivers
​ ​ ​ ​ • Fixed USB OTG (flash drivers, etc)
​ ​ ​ ​ • Optimized default settings
​ ​ ​ ​ • Improved reliability of default settings
​ ​ ​ ​ • Removed 307 MHz CPU underclock (detrimental to battery due to no undervolt)
​ ​ ​ ​ • Turned CPU overclock down to 2208 MHz for stability and battery
​ ​ ​ ​ • Turned GPU overclock down to 700 MHz for stability and battery
​ ​ ​ ​ • Enabled TCP ECN for slightly faster speeds on congested networks
​ ​ ​ ​ • Reduced chance of videos not playing
​ ​ ​ ​ • Added sdFAT driver for SD cards on some ROMs
​ ​ ​ ​ • Undervolted CPU by 150 mV
​ ​ ​ ​ • Added Kali NetHunter support (IPC, Bluetooth, Wi-Fi)
​ ​ ​ ​ • Improved audio jack quality
​ ​ ​ ​ • Added DTS-Eagle (DTS Headphone-X) support
​ ​ ​ ​ • Improved overall smoothness
​ ​ ​ ​ • Removed UKSM (additional overhead even when not in use)
​ ​ ​ ​ • Enabled fully multi-threaded IO
​ ​ ​ ​ • Improved boot speed
​ ​ ​ ​ • Removed hotplugs (this has been proven to actually be detrimental to battery, as well as performance)
​ ​ ​ ​ • Added ironactive and ondemandplus CPU governors
​ ​ ​ ​ • Fixed simple_ondemand GPU governor
​ ​ ​ ​ • Tuned Spectrum GPU settings
​ ​ ​ ​ • Fixed "There's an internal problem with your device" message on Treble ROMs
​ ​ ​ ​ • Fixed many more bugs
​ ​ ​ ​ • Removed non-functional Intellithermal
​ ​ ​ ​ • Fixed Bluetooth Low Energy + Wi-Fi co-existence on Pie

Older versions:

r8 • June 19, 2018

​ ​ ​ ​ • ​Linux 3.18.113
​ ​ ​ ​ • Updated Qualcomm code to latest CAF LA.UM.6.6.r1-08900-899xx.0
​ ​ ​ ​ • Enabled Large Receive Offload
​ ​ ​ ​ • Improved idle battery life
​ ​ ​ ​ • Fixed lazyplug
​ ​ ​ ​ • New hotplugging settings using msm_hotplug
​ ​ ​ ​ • Added fingerprint boost
​ ​ ​ ​ • Improved wakeup times
​ ​ ​ ​ • Improved CFQ and BFQ performance
​ ​ ​ ​ • Added dynamic schedtune input boost
​ ​ ​ ​ • Disabled unnecessary CPU bug workarounds (not applicable to Snapdragon 625)
​ ​ ​ ​ • Switched to AOSP clang 7.0.2
​ ​ ​ ​ • Reduced 3.5mm jack background noise

r7 • June 6, 2018

​ ​ ​ ​ • Updated to Linux 3.18.112
​ ​ ​ ​ • Disabled ZRAM (negative impact on 4 GB RAM devices)
​ ​ ​ ​ • Disabled wake gestures by default
​ ​ ​ ​ • Added CPU governors: elementalx, zzmoove, yankactive, relaxed, alucard, nightmare, chill
​ ​ ​ ​ • Increased default I/O performance
​ ​ ​ ​ • Removed custom marrow and microfreq governors
​ ​ ​ ​ • Fixed random reboots
​ ​ ​ ​ • Reverted to default 84% vibration strength
​ ​ ​ ​ • Improved performance on default profile
​ ​ ​ ​ • Enabled Adreno Idler
​ ​ ​ ​ • Improved idle battery life (fixed heavy drain)
​ ​ ​ ​ • Enabled idle IO scheduler switcher
​ ​ ​ ​ • Decreased entropy pool thresholds
​ ​ ​ ​ • Improved wakeup time
​ ​ ​ ​ • Fixed flashing on latest Resurrection Remix
​ ​ ​ ​ • Likely fixed video playback
​ ​ ​ ​ • Disabled compressed disk cache

r6 • May 29, 2018

​ ​ ​ ​ • Reverted to 100 Hz for maximum performance
​ ​ ​ ​ • Removed unused module support (0.2 MB smaller)
​ ​ ​ ​ • Microfreq GPU governor made more aggressive
​ ​ ​ ​ • Aggessively tuned helix_schedutil and autosmp on Balanced profile
​ ​ ​ ​ • Fixed almost all random reboots (hopefully)
​ ​ ​ ​ • Extra compiler optimizations
​ ​ ​ ​ • Switched back to clang as it seems to be smoother
​ ​ ​ ​ • Other Spectrum profiles tuned
​ ​ ​ ​ • Completely fixed Wi-Fi MAC address

r5 • May 28, 2018

​ ​ ​ ​ • Fixed all performance issues
​ ​ ​ ​ • Geekbench: 928 single-core, 4433 multi-core
​ ​ ​ ​ • Antutu: 81868
​ ​ ​ ​ • Fixed Spectrum profiles not setting on boot
​ ​ ​ ​ • Heavily tuned Spectrum profiles
​ ​ ​ ​ • Revamped Balanced profile to maximize performance and battery

r4 • May 27, 2018

​ ​ ​ ​ • Switched to GCC 8.1
​ ​ ​ ​ • Added sweep2sleep, sweep2wake, doubletap2wake gestures
​ ​ ​ ​ • Tweaked Spectrum profiles for much better performance and battery where applicable
​ ​ ​ ​ • Fixed broken Wi-Fi MAC address
​ ​ ​ ​ • Output version and build date when flashing
​ ​ ​ ​ • Fixed double tap to wake

r3 • May 26, 2018

​ ​ ​ ​ • Fixed data corruption when encrypted
​ ​ ​ ​ • Upstreamed to 3.18.110
​ ​ ​ ​ • Optimized memory page copying
​ ​ ​ ​ • Switched to Linaro GCC 7 compiler for fluidity
​ ​ ​ ​ • Added stock ROM support framework (disabled at the moment)

r2 • May 25, 2018

​ ​ ​ ​ • Enabled Integrity subsystem

r1 • May 24, 2018

​ ​ ​ ​ • Initial release
​ ​ ​ ​ • Linux 3.18.109

 

[kdrag0n]

FAQ

Q: What ROMs are supported?
A: Treble GSIs and custom ROMs.

Q: What is the difference between all the EAS governors?
A: In terms of aggression, alucardsched > electroutil > (pwrutilx / schedutil) > darknessched. For more information, consult this post:

So this post will be dedicated to information about EAS in general.

Another amazing write up about alucardsched by a talented new dev @joshuous:

This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.

Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.

Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.

How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph

Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.

Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.

Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):

This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.

As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.

AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.

This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.

helix_schedutil explained by @Kyuubi10

To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity

Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.

Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:

"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load

"maxfreq + (maxfreq >> bitshift)"

Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.

Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.

The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8

If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".

Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.

Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.

Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.

Update to the explanation:

After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.

The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)

The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50

Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.

correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.

While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.

As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.

The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.

Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core

here is some Information about pwrutil governor:

This new governor is based on schedutil.

A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.

Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).

UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.

 

[NotAllan]

Cool ! New kernel, will test now. Thanks dev

 

[CaioFerreira]

Nice to see EAS for our device, performance should overtake battery I assume.

 

[GamingDevilsCC]

Awesome, good job op!

 

[Ayush061]

Velocity Kernel • Mi A1
Introduction
Velocity Kernel was made to provide the best possible experience on all devices. We strive to provide the perfect balance of performance and battery life. Features are also plentiful, but features that nobody will use are outdated. We also completely debloat all our kernels and aim for small sizes relative to other kernels. Due to the small size and careful debloating, boot time is also improved.

Compatibility
At the moment only custom ROMs are supported. If there is enough demand, support for stock may be added.
Unofficial Project Treble devices are supported. Treble support is dynamically enabled if a Treble ROM is installed and your device has Treble. No special ZIP is necessary.

Where to flash in boot.img?

 

[tytydraco]

I'm one of the devs for this kernel.
Here's some things we'd like to hear back about from this kernel:

- Any random reboots / kernel panics?
- Does YouTube ever black out?
- Is your idle battery good?
- Do you get scroll lag?
- Does DT2W work properly?

These were all things we were experimenting with, so let us know if things are broken. Thanks and enjoy!

 

[kdrag0n]

Where to flash in boot.img?

It's a zip to flash in TWRP, not boot.img.

 

[Ayush061]

It's a zip to flash in TWRP, not boot.img.

Okay got yah

 

[Dasseem]

After flashing the Kernel, data got corrupted with display unable to decrypt message. Even the correct password didn't work in recovery. Fortunately able to recover phone by flashing stock ROM.

 

[kdrag0n]

Phone got corrupted, not accepting my password in recovery too.

That should never happen. Does booting TWRP from fastboot work? Does tAndroid not boot anymore?

 

[Necio7]

Phone got corrupted, not accepting my password in recovery too.

me too, I had to delete my data

 

[Dasseem]

That should never happen. Does booting TWRP from fastboot work? Does tAndroid not boot anymore?

Thankfully fastboot was working, flashed stock ROM.

Booting TWRP from fastboot didn't help since the it didn't accept my password. Had to flash stock.

 

[simorangkir_dcs]

Flashed this kernel on top of Mint, so far no issue. Watched YouTube for 20 minutes, taking photos, everything seems fine.

 

[TatsuyaKaneki2015]

Any tried to flash this on AEX? without bootloop?

Sent from my [device_name] using XDA-Developers Legacy app

 

[simorangkir_dcs]

Any tried to flash this on AEX? without bootloop?

I'm using aex latest build. No bootloop.

 

[kdrag0n]

Any tried to flash this on AEX? without bootloop?

Sent from my [device_name] using XDA-Developers Legacy app

I was able to use it just fine on the latest AEX 5.5. Which kernel did you switch from?

 

[TatsuyaKaneki2015]

I was able to use it just fine on the latest AEX 5.5. Which kernel did you switch from?

Franco planning to flash it but little hesitant . I dont wanna get bootloop. But anyways it should work fine right im going to clean flash anyway installing latest AEX rom and installing this?

Sent from my [device_name] using XDA-Developers Legacy app

 

[kdrag0n]

Franco planning to flash it but little hesitant . I dont wanna get bootloop. But anyways it should work fine right im going to clean flash anyway installing latest AEX rom and installing this?

Sent from my [device_name] using XDA-Developers Legacy app

Yes, that should work fine.