TechDomino
We’ve heard some rumors from different sources (including WSJ) a few months ago that Android 5.0 “Key Lime Pie” will be better for lower-end devices, particularly devices with low amounts of RAM. A lot of people have been skeptical about this, but if Google adopts the Linux kernel 3.8, or even a newer one such as 3.10, which is meant to become a “long term release”, and would fit perfectly for the major releases of Android, then we can see exactly why and how KLP will be improved for lower-end devices.
However, 3.10 wasn’t released too long ago, and I’m not sure Google will have time to support it in KLP for this fall’s release. But we do know Google has been working at least on kernel 3.8. Some very interesting changes have been added to kernels 3.7 and 3.8, when it comes to ARM support that Android could benefit greatly from, so let’s talk about those.
Kernel 3.7
Linux kernel 3.7 brings support for the 64-bit ARMv8 architecture, which may or may not mean that KLP is ready for ARMv8 chips, but it should be because early next year we should start seeing ARMv8 chips, especially from Qualcomm. Qualcomm makes custom chips on ARM’s architecture, and that gives them a time to market advantage over other OEM’s who use stock CPU cores (much like it happened with Krait vs Cortex A15). Plus, if KLP comes out this fall, it would take OEM’s around spring or so to release it, so just in time to be ready for ARMv8 chips.
Kernel 3.7 also brings multi-platform support and it makes it a lot easier for OEM’s to have one “master image” at the very least for all or most of their devices (even if there still won’t be a master Android image for all OEM’s, the way Windows is – at least not yet). It supports something called “device tree”:
“Device Tree helps to consolidate code for boards within one SoC family and allows you to boot on future ones without kernel changes. Multi-platform helps to consolidate across SoC families. Moving platform code out into drivers supports the other two and allows to consolidate code across CPU architectures.” – Linaro.
This could make it easier for OEM’s to upgrade their devices, because instead of upgrading a dozen different ROMs, they can upgrade just one “master ROM”, for all or most of their devices (depending how different some chips are in some devices). That means faster upgrades, and also just as important – more upgrades for mid-end and lower-end devices, which are really getting ignored by most manufacturers, because they only prioritize the development for their flagships.
Kernel 3.8
The kernel 3.8 also brings a couple of major improvements, of which one sounds very inline with what some of the reports about KLP were saying – that it will be much better for devices with low amounts of RAM. Kernel 3.8 will save a lot of RAM, which could make Android 5.0 possibly even more efficient as Android 2.3 was for lower-end devices.
This is why OEM’s were stuck with releasing Gingerbread devices for a long time, even after Android 4.0 was out, because 4.0 needed significantly more resources on lower-end devices, and some of that was because of all the extra polish Android 4.0 received over Android 2.3.
If Android 5.0 will be a very lean mobile OS again, and this time with full GPU acceleration and Project Butter, Android could start working very well even on under $100 devices, especially when combined with Cortex A7 (and soon Cortex A53) chips at the low-end (ARMv6 chips should really be left to die – that architecture is more than a decade old, and many apps aren’t even supporting it anymore).
The second major change kernel 3.8 could bring to Android 5.0 is support for Samsung’s open source F2FS file system, which as the name implies, it’s a “Flash Friendly File System”.
F2FS is based on Log-structured File System (LFS), which supports versatile “flash-friendly” features. The design has been focused on addressing the fundamental issues in LFS, which are snowball effect of wandering tree and high cleaning overhead.
Since flash-based storages show different characteristics according to the internal geometry or flash memory management schemes aka FTL, F2FS and tools support various parameters not only for configuring on-disk layout, but also for selecting allocation and cleaning algorithms.
Kernel 3.8 also includes support for Tegra’s open source drivers, but Nvidia has been so slow improving those (probably on purpose), that it’s unlikely it will be of any use to anyone (don’t expect open source Tegra 4 drivers anytime soon).
So there it is: 64 bit and device tree support, lower RAM usage and a faster and more efficient file system for Android devices. Those are some of the major changes that we can expect from Android 5.0 “Key Lime Pie”, and that’s without taking into consideration any of the actual “user-centric” features, and possibly some changes in the UI (especially for larger screens if they intend to push Android to notebooks). Excited about KLP yet?
