Everything you need to know about custom kernels

With an astounding over 13 million lines of code, the Linux kernel is easily one of the world’s largest Open Source projects. Initially put together by Trovalds, the Linux Kernel originally intended with no cross-platform intentions now supports around 30 different architectures.

Tux the penguin, Mascot of Linux.

If you’re on XDA, you’ve probably already heard of kernels. The awesome custom kernel which offers a ton of features including but not limited to, more battery life, a smoother experience, exFAT or OTG support maybe, custom color controls, wake gestures, etc. So, what exactly are custom kernels, and where did the entire picture of a kernel come into Android?

Since the inception of computers and devices, there has been a three-tier interaction model.

As you can see, the kernel comes at the second tier either way. Which means that if there was any interaction between the operating system and the hardware (like a volume increase trigger), or between the hardware and the operating system (like a USB device insertion), the kernel is the middle man.

So, the next time you increase the volume on your Android device, what actually happens is that Android sends a request to kernel stating that the volume needs to be increased, and since the kernel handles the hardware, it increases the voltage for the speaker (which loosely translates to sending a ‘volume increase’ request to the speaker); or the time when you plug-in a USB device in you OTG-enabled smartphone (or insert/remove a memory card), the kernel tells the operating system that a USB device has been plugged in (or a memory card inserted/removed) and Android can do the necessary things like mounting the SDCard, etc.

The boot sequence for an Android device looks something like this:
BIOS->Bootloader->Kernel->Operating System.

The BIOS is locked down code on the device, by the OEM which is used to load up the Bootloader which does some stuff to help load up the kernel. Once the kernel takes over, it loads the drivers for file systems, etc. and eventually, the Operating System kicks in.

Google decided to go with the linux kernel while bringing up Android, a decision rightly made. The ‘mainline’ linux kernel is the kernel that’s used in desktops which can be compiled and run from Trovalds’ linux branch whereas Android’s kernel is a fork off this mainline kernel with (relatively) few additions. The main reason why we can’t run the mainline kernel (the one that runs on desktops) is due to lack of support for these certain elements needed for Android.

1. The android binder, an Android-specific interprocess communication mechanism, and remote method invocation system. If android decides to write to the display, the OS and the GPU talk through the binder. That should fairly give the idea that *almost* all communications are made through binders.
2. ashmem/pmem/ion: memory allocators specifically designed for android
3. logger: to write various logs like kmsg, radio, events, etc.
4. wakelocks: ever wondered why you get that facebook message on your phone even though it seems to be turned off? voilà. wakelocks at work. (psst. the facebook for Android application holds a LOT of wakelocks, but that’s discussion for another day)
5. oom handling: OOM stands for Out Of Memory. Since Android devices run low on memory, this is a process killer, the Linux LMK (Low Memory Killer). This is what prevents the device from hanging up by clearing a few running background apps when you open too many of them.
6. support for YAFFS/JFFS/ file systems: If you’re running older devices, you are probably running a device with flash file systems. These are different from the conventional ext2/3 file systems, and need to be supported by the kernel.

Now that we know kernels deal with hardware, why do we need custom kernels? In our take at What makes custom ROMs popular, we outlined a few cases where Custom ROMs are better than the stock provisions. In a similar manner, custom kernels are better in more than a few ways with android. You can tweak various features like:

• the minimum and maximum frequencies that the CPU can scale up or down to
• how busy the CPU should be before it enables extra cores that it normally has disabled to save battery
• the frequency the CPU should boost to whenever it detects touch input (to ensure a smoother wake up)
• the CPU governor (which determines how quickly it tends to ramp up the frequency or not) that should be used
• change the voltage of the CPU during all possible frequencies
• the maximum frequency of the GPU
• enable USB fast charge
• configure the I/O scheduler that is used

You can also have features like KnockOn (first featured in LG G2) or custom color controls for your device.

There are different custom kernels, giving you a plethora of choices to pick from. You can either go for a high-performance, overclocked gaming kernel, or a under-clocked battery booster, or go with a fair share of both. If you can’t decide, you can very well go ahead and build your own custom kernel with the features you like since most OEMS release the sources for their devices’ kernels.