Saturday, August 31, 2013

The Android ION Memory Manager

Lately there's been quite a bit of discussions about Android "ION". What exactly is ION? Is it just some fancy name or is there more to it?

Let's talk about some history of Android first.

Since the very beginning, vendors of Android devices like HTC, Samsung or Motorola all use different System on a Chip (SoC) solutions from Qualcomm (MSM/Snapdragon), Nvidia (Tegra) and TI (OMAP). Each SoC has its own kernel drivers for managing memory buffers (chunks of scratchpad memory) used by Graphic Processing Unit (GPU), Audio processing, and Camera Stills and Video processing.

Every vendor had their own version of memory management, such as PMEM for Qualcomm, NVMAP for Nvidia and CMEM for TI - private memory not shared with anyone else. Each Android graphics, audio and camera libraries had to be customized to work with each of the SoC's own flavour of memory management, which makes it a nightmare for the Android Maintainers to maintain the fragmentation and compatibility issues abound. However, this was the case for all pre-Ice Cream Sandwich OS like Froyo, Gingerbread or even Honeycomb.

For Android 4.0 (aka Ice Cream Sandwich), Google was finally fed up with the private memory manager structure and decreed that all newer devices with Android 4.0 native should use the new, so called "ION" memory manager.

So what is exactly the Android ION?

In a simple words, Android ION removes ARM specific dependencies. The ION memory manager provides a common structure for how memory will be managed and used by GPU, Audio and Camera drivers. Common functions are:

  • memory allocation / de-allocation
  • Direct Memory Access Pools
  • user-space (Android libraries) memory passing to/from kernel space

With these common functions and structures defined, kernel drivers from each SoC manufacturer needed to rewrite their drivers to be compatible with Ice Cream Sandwich. Once the drivers adopted to the new common structure, the graphics, audio and camera libraries can now be more generic and could care less about the nitty-gritty details of how different SoC vendors' drivers worked.

It was painful at first, but it was a necessary move for Google to impose to all the SoC vendors. Now looking back, this new ION manager enabled manufactures and third party Android projects (like Cyanogen-mod) to quickly bring up newer Android releases for various devices and also reduce the "hidden" Android fragmentation.

If you want to take a look at the code of the ION memory manager, please visit faux123 github - MSM ION

I hope you enjoyed my first Kernel GeekTalk series... more to come soon!

Have any questions or comments? Feel free to share! Also, if you like this article, please use the media sharing buttons (Twitter, G+, Facebook) under this post!