What you need to know about custom kernels

With an incredible 13 million lines of code, the Linux kernel is one of the biggest open source projects in the world, possibly. Initially put together by Trovalds, the originally intended Linux kernel currently supports about 30 different architectures with no cross-platform intentions.

If you’re on XDA, you probably have heard about kernels before. The amazing custom kernel that offers a lot of features including but not limited to, more battery life, a smoother interface, maybe exFAT or OTG support, custom color controls, wake-up gestures etc. So, what exactly are custom kernels, and where did a kernel’s entire image get into Android?

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

As you can see, either way the kernel arrives at the second tier. That means that the kernel is the middle man if there is any contact between the operating system and the hardware (such as a volume increase trigger) or between the hardware and the operating system (such as an insertion of a USB device).

So, the next time you increase the volume on your Android device, what actually happens is that Android sends a request to the kernel indicating that the volume needs to be increased, and since the kernel manages the hardware, it raises the voltage for the speaker (which translates loosely into sending a request for a ‘ volume increase ‘ to the speaker); or the time you plug-in a USB device into your OTG-enab

The boot sequence for an Android device looks something like this:

BIOS->Bootloader->Kernel->Operating System.

Google wanted to go with the linux kernel when Android was brought up, a move that was rightly made. The’ mainline’ linux kernel is the kernel used in desktops that can be compiled and run from the linux branch of Trovalds, whereas the kernel of Android is a fork with (relatively) few additions off this mainline kernel. The key reason we can’t run the mainline kernel (the one running on desktops) is due to the lack of support for some of those elements that are required 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.

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