[One (M8) Android Development] fizbanrapper:
Team-M8 AOSP kernel

What is it?

This project was initially based on Unicornblood kernel from DirtyUnicorns (@smac0628), which is current with linux 3.4.110. She and I are working together on this project to make a better experience for users.

We aim to include as many tweaks as possible to this AOSP kernel while maintaining stability. We also make extensive efforts to properly give credit the authors of the many features we've added (picked only the original author's commits, instead of kanging entire files).

Settings have intentionally been chosen which favor battery life over performance. With that said, you can definitely squeak out a little better battery life, or you can have some fun and get killer performance instead.

Features:

Hotplugs (only enable one!, more on the way):

IntelliPlug

Great balance between battery life and performance. It is also a popular hotplug driver from faux123.

MSM Hotplug

Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.

Alucard Hotplug

A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.

Zen Decision

ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.

Hybrid Hotplug/Governor (Disable all hotplugs if you're going to use this)

zzmoove

The ZZmoove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:

CPU Governors (more on the way):

A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.

Abyssplugv2

AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.

alucard

A favourite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.

badass

Badass removes all of this "fast peaking" to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)

Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu

dancedance

Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.

darkness

It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests

elementalx

If you are an owner of a nexus device, you probably have heard of a governor named ElementalX. Named after the kernel, elementalX is based on interactive but with some additional performance tweaks. This governor focuses on performance and not battery savings!

hellsactive

A heavily modified intelliactive governor by @hellsgod that has been tweaked to improve battery life. Hellsactive is less aggressive compared to intelliactive so the battery life will be more like the original interactive.

intelliactive

Based off Google's Interactive governor with the following enhancements:

1. self-boost capability from input drivers (no need for PowerHAL assist)

2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq

3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.

This is a more performance oriented CPU governor that still has great battery life like the original Interactive.

intellidemand

Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.

To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.

intellimm

A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.

nightmare

A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.

ondemand

Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.

smartmax

Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.

yankactive

A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.

yankdemand

Full stock (JB) ondemand governor with changed default tunable values aimed at lower battery consumption

interactive

Google's own take on a CPU governor. Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.

Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.

Interactive is the default governor of choice for today's smartphone and tablet manufacturers.

performance

The performance governor locks the phone's CPU at maximum frequency.

The descriptions in this post were created by @gsstudios and can be found here:

http://xdaforums.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957

Voltage Control (UV/OV)

OC to 2880 MHz

UC to 268 MHz

Set Max frequency in Screen-Off state

As the name says, you get to set a different governer when screen is off. This will override what you chose in the governer choice. Pretty nifty arrangement so that you can flip from a performance governer when on screen and a power save governer when screen is off. This feature was added to the kernel because it was either the developers intention or by popular demand.

Force Fastcharge

A. When set, the phone will charge off of the PC USB ports as if it is connected to wall outlet. This does turn off your access to the phone internal memory and SD card. If you want to access the internal storage on PC then you have to turn this off.

NOTE – Weather to turn on or off, has to be done before connecting to PC. Changing this after connecting has no effect.

Kexec hardboot patch (can be flashed as primary bootimage in multirom)

GPU Governors:

cpubw_hwmon

A hardware (HW) monitor based governor that attempts to determine bandwidth needed by CPU and other hardware. This is a unique GPU governor that is highly customisable, however it is known to be unstable on some devices.

msm_cpufreq

The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.

msm-adreno-tz

The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life.

userspace

This governor basically allows the user is able to set a desired frequency for the GPU to run at.

powersave

Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.

performance

As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.

simple_ondemand

KCal display adjustments

IO Schedulers:

Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.

I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:

- To minimise time wasted by hard disk seeks.

- To prioritise a certain processes' I/O requests.

- To give a share of the disk bandwidth to each running process.

- To guarantee that certain requests will be issued before a particular deadline.

bfq

Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

Benefits:

- Has a very good USB data transfer rate.

- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)

- Regarded as a very precise working Scheduler

- Delivers 30% more throughput than CFQ

- Being constantly updated

- Good for multitasking, more responsive than CFQ

Disadvantages:

- Not the best scheduler for benchmarks

- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.

cfq

Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Benefits:

- Has a well balanced I / O performance

- Excellent on multiprocessor systems

- Regarded as a stable I/O scheduler

- Good for multitasking

Disadvantages:

- Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.

- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks

- Under constant load, the phone will experience increased I / O latency due to the way how the scheduler tries to create 'fairness'

deadline

The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

Benefits:

- Nearly a real-time scheduler.

- Excels in reducing latency of any given single I/O

- Best scheduler for database access and queries.

- Does quite well in benchmarks, most likely the best

- Like noop, a good scheduler for solid state/flash drives

Disadvantages:

- If the phone is overloaded, crashing or unexpected closure of processes can occur

fifo

First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.

Benefits:

- Serves I/O requests with least number of cpu cycles.

- Is suitable for flash drives because there is no search errors

- Good data throughput on db systems

Disadvantages:

- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance

- Not very good at multitasking

fiops

This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) ioscheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.

Benefits:

- Achieves high read and write speeds in benchmarks

- Faster app launching time and overall UI experience

- Good battery life

Disadvantages:

- Not very common in most kernels

- Not the most responsive IO scheduler (Can make phone lag)

- Not good at heavy multitasking

noop

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Benefits:

- Serves I/O requests with least number of cpu cycles.

- Is suitable for flash drives because there is no search errors

- Good data throughput on db systems

- Good battery life

- Does great in benchmarks

- Also a very reliable IO scheduler

Disadvantages:

- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance

- Not the most responsive I/O scheduler

- Not very good at multitasking (especially heavy workloads)

row

The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.

Benefits:

- Faster UI navigation and better overall phone experience

- Faster boot times and app launch times

Disadvantages:

- Not great for heavy multitasking

- Slower write speeds

sio

Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Benefits:

- It is simple and stable.

- Minimized starvation for inquiries

- Good battery life

Disadvantages:

- Slow random write speeds on flash drives as opposed to other schedulers.

- Sequential read speeds on flash drives are not as good as other IO schedulers

tripndroid

A new I/O scheduler based on noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR

Benefits:

- Great at IO performance and everyday multitasking

- Well rounded and efficient IO scheduler

- Very responsive I/O scheduler (Compared to FIOPS)

Disadvantages:

- Not found in all kernels

- Performance varies between different devices (Some devices perform really well)

vr

Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.

Benefits:

- Generally excels in random writes.

Disadvantages:

- Performance variability can lead to different results (Only performs well sometimes)

- Sometimes unstable and unreliable

zen

ZEN scheduler is based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as no-op blended with VR features.

Benefits:

- Well rounded IO Scheduler

- Very efficient IO Scheduler

- More stable than VR, more polished

Disadvantages:

- Performance variability can lead to different results (Only performs well sometimes)

- Not found in all kernels

LED Control

Z-Ram

Q. What is ZRAM?

A. ZRAM basically compresses unused apps within the system RAM. This allows the system to swap less needed processes to the zram partition for faster access at a later time, instead of killing them. This does take up some of your ram though, so I imagine that the value you are setting is determining exactly what percentage of your ram that the zram partition is allotted.

FSYNC

TCP Congestion Algorithms:

Congestion control strategies (or algorithms) are used by TCP, the data transmission protocol used by many Internet applications. The main goal of a TCP algorithm is to avoid sending more data than the network is capable of transmitting, that is, to avoid causing network congestion. Different algorithms respond differently to network loads, but they are all based on the same principle of avoiding network congestion.

Things to look out for in TCP algorithms include (but not exclusively):

- Download/Upload speeds - The higher the number, the better

- Latency - The lower the number, the better

bic

Binary Increase Congestion control (BIC):

BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.

lp

Low Priority (LP):

A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.

highspeed

High speed (HSTCP):

High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.

htcp

Hamilton TCP (HTCP):

HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.

hybla

Hybla:

Penalizes connections that use satellite radio. Not usually used with phones. ;)

illinois

Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.

scalable

Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.

vegas

One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.

veno

Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.

westwood

A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.

yeah

A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.

reno

Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.

cubic

One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.

Sweep to Wake, Sweep to Sleep, Double-tap to Wake (for these features, please build from branch master-s2w)

How do you get it?

That's a hard question to answer, surprisingly. You're free to flash the zip file below, but it's only the zImage. While this zip will include nearly everything you'll want or need, what you need for OC/UC is part actually of the dts. The dts is another piece that gets packed together with the zImage to make the boot.img. Unfortunately there's all sorts of ramdisk & permissions issues which can be caused by flashing a boot.img, so it's not recommended.

Please make a nandroid before doing anything! Backing up the boot partition takes all of a second and 16 megs of storage. Just do it! Also, do not hold us responsible for anything that happens to your device. It's worked fantastically for us, but you're flashing at your own risk.

Downloads for MM

Download for LP (no Sweep to Wake)

Download for LP (with Sweep to Wake)

The very best method of getting the kernel, is to have it compiled with the ROM itself (as with all kernels).

O.P. is a WIP. Will be adding and editing a lot, especially at first.

Special thanks to @izzaeroth for assisting with the Anykernel zip.

XDA:DevDB Information

Team-M8 AOSP kernel, Kernel for the HTC One (M8)

Contributors

fizbanrapper, smac0628, amirfida

Source Code: https://github.com/Team-M8/android_kernel_htc_msm8974/tree/master

Kernel Special Features:

Version Information

Status: Beta

Created 2015-11-10

Last Updated 2016-08-16