Linaro supercharging Android and showing the power of Open Source

This article may contain personal views and opinion from the author.
Linaro supercharging Android and showing the power of Open Source
Those of you who pay attention may have noticed that Google and Apple have settled into an interesting routine with their respective updates for mobile products. Apple tends to focus on big software updates one year and big hardware updates the next. On the other hand, Google seems to have gotten into a routine of pushing a big feature/UI update, and follow that with a performance/under-the-hood update. Froyo and Ice Cream Sandwich have been feature/UI updates, while Gingerbread was a performance update. And, we expect Jelly Bean to also primarily be a performance update, especially since it is expected to be an incremental number (Android 4.1) rather than a full number bump (of course, that statement assumes a simple logic behind Google's version numbering system, when in reality it probably took a team of engineers to design the algorithm which decides the version numbering sequence). 

There will likely be a couple of features added to Jelly Bean, because it's hard to get people excited about a mostly under-the-hood update, but we don't expect too much. More than likely, we'll finally see the rumored Google newsstand magazine solution, and maybe some refinements to existing apps (like perhaps the somewhat useless stock People app (and we will keep ragging on Google for the failures of the People app until it is fixed, because carrier hooks aren't what we want.)) We don't expect the rumors of the dual-boot with Chrome OS to come to pass, but that is possible. Really, we expect Jelly Bean to be all about performance, and on that topic, it's reasonable to assume that a lot of the performance boosts we'll see will be due to the work of the Linaro team because of the process behind open source. We reached out to Linaro, and they gave us some great info on the project. 


The Linaro team is a group of about 120 members who are dedicated to optimizing open-source software for use on ARM processors. The company is a not-for-profit organization that has been focused on helping partners optimize software for various hardware configurations, and is not affiliated with Google. Linaro has officially been working on optimizing Ubuntu Linux and Android and the results have been extremely impressive. And, we mean impressive, like making Ice Cream Sandwich run between 1 and 5 times faster depending on the metrics used to test. The improvements are mostly with the CPU, though there has been solid graphical updates, and supposedly an increase in SunSpider performance by around 30%, which is pretty amazing. 

The team achieves these improvements by optimizing the GNU Compiler Collection (GCC) toolchain, the Linux kernel, ARM power management, graphics and multimedia interfaces. The first line of optimization is a pretty simple one: use the latest stuff. Simply by using the latest Linux kernel (and leveraging that open source work from others), or using the newest version of the GCC tools to compile Android, everything runs faster. Of course, on top of that, Linaro does dig into the code itself (with about 1,500 lines of "generic Linaro optimization changes" made) to optimize the software even more.

And, the key to the optimizations is that they have been written for the "generic ARM technology that is common to all ARM SoC vendors", which allows the results to be seen on any ARM-based device. Of course, there are specific optimizations done to compensate for the idiosyncrasies of various iterations of ARM processor (like the different timing of Cortex A8 vs A9). The team has been working to ensure proper optimization on all ARM SoCs, and is looking forward to optimizing for the Cortex A15 which will be the basis of the next gen SoCs, like the Exynos 5 series, and OMAP 5 chipsets. Linaro has been getting resources (hardware, engineers, etc.) from certain manufacturers to help optimize the code including Samsung, Texas Instruments, Freescale, and ST-Ericsson. However, the company does not receive anything from NVIDIA or Qualcomm, and so does not officially optimize for those chips. Of course, because the Linaro work is all open source, NVIDIA and Qualcomm can still use it if they wish. 

Beyond optimizing the actual binary code, the Linaro team is also looking to help make updates more efficient. According to the team, one trouble in updating Linux system software is that the "closed blobs" (binary large object), which are used to optimize software for various hardware configurations, can cease to work when the kernel is updated, because there is no standardized interface for these blobs. With that in mind, the team has been working on Unified Memory Management (UMM), which should allow for easier updating of the kernel without causing trouble with the blobs. Remember, Android was running on variations of the Linux 2.6.x kernel all the way until Ice Cream Sandwich (the seventh major revision), which finally got the Linux kernel to 3.0.1 (although the newest stable kernel right now is 3.4.2, and Linaro uses kernel v3.2). 


Of course, none of this work would matter all that much, except for one big key to the Android ecosystem: it's open source. Because of this, Linaro's work has already started being baked-in to new AOKP and CyanogenMod custom ROMs, and users are already seeing noticeable improvements in the speed of the system. Beyond the benefits for the mod community right now, this work has big implications for all Android users going forward. Linaro has been submitting its work to the upstream repositories for the GCC toolchain, Linux kernel, and most importantly for us, the Android Open Source Project (AOSP). 

According to Jean-Baptiste Queru, our favorite Technical Lead for AOSP, as of June 6th, at least two of the changes submitted by Linaro had already been accepted and merged into Android. It's hard to find exactly what changes were submitted, accepted, and merged, because there is a lot of activity in AOSP, and Linaro code is submitted by a number of different team members. So far, the known accepted changes have been bug fixes related to GCC compiling, and likely wouldn't have an impact on performance, but as Google accepts more Linaro submissions, there's a fair chance that the optimizations will make their way upstream to Android proper. Given how soon the expected launch of Jelly Bean is, it may not be feasible to expect the Linaro optimizations to be part of that code, so the next version of Android (presumed to be Key Lime Pie) may be a more likely place to find the improvements. 

There is always the chance that we won't see any of Linaro's changes, and that Google may make similar changes itself. Or, various manufacturers could submit more work to AOSP, which would both add optimizations for various hardware, and also make updates faster because manufacturers would already have needed changes baked-in to stock Android. Given the changes that were accepted from Linaro, it's safe to say that Jelly Bean will be using the newest GCC tool to compile, which will help in some ways, it's just a matter of what else Google has done. 

This is the power and the visibility problem in open source. Anyone can get in and make changes and improvements to the code, which can go a long way to crowd-sourcing the work of squashing bugs, or fixing security problems (as we've already seen). Unfortunately, because everything is open, we see the bigger improvements out in the wild a long time before they may be folded into the main code tree. Linaro is doing great work, but its best work may be relegated to CyanogenMod and AOKP for a long time before we see them filter into the main Android system, especially given the much slower update cycle that Google has transitioned into. 


So, now it's time to see what Google can do with this work. Linaro has undoubtedly made optimizations that make Android faster, and has submitted that work to the Android Open Source Project. Given that there are already builds of AOKP and CyanogenMod out for the Galaxy Nexus, Google could certainly have Linaro baked-in to a theoretical Android 4.0.6 update and pushed out to unlocked Galaxy Nexus users within weeks, but that's pretty unlikely to happen. 

Still, no matter if or when the work is merged into the main Android code tree, Linaro is going to keep working. And, based on what the team has accomplished so far, we're pretty intrigued to see what they can do moving forward. If nothing else, now is a great time to be part of the mod community in Android, because your favorite custom ROMs are likely to be getting a speed boost soon enough thanks to Linaro. 

sources: Linaro & Jean-Baptiste Queru (via Rashidi Zin)



23. nicholassss

Posts: 368; Member since: May 10, 2012

Why not have google hire these nerdy dudes to optimize the code after a stable version has been released. make it official. then the every day chap can get these in updates. And us nerds would also benefit because we could still do whatever we wanted with our phones but we'd be starting off that much better.

24. nicholassss

Posts: 368; Member since: May 10, 2012

I know google has a lot more red tape to cut through before they can release stuff, but ti seems like it it can be made so much better, it should be made so much better, you know what I mean?

20. TylerGrunter

Posts: 1544; Member since: Feb 16, 2012

Michael, do you mind to check this two sentences? a) "closed binary blobs", a blob is a binary large object, so there is not binary blob is redundant. "closed blobs" or "closed binary objects, also called blobs" b) "which should allow for easier updating of the kernel by causing trouble with the binary blobs". Do you wanted to say this "which should allow for easier updating of the kernel WITHTOUT causing trouble with the blobs"?

27. MichaelHeller

Posts: 2734; Member since: May 26, 2011

edited. sorry about that. I was just quoting from the Linaro literature, which refers to them as "closed binary blobs". Obviously, I'm not a coder, so I was trusting them on that.

29. TylerGrunter

Posts: 1544; Member since: Feb 16, 2012

No problem, in fact is common mistake the Linux developers make. A blob is just a large binary, which includes images, videos, etc. So in order to differenciate the "executable code in binary" the call it just "binary". Why? Because in Linux there used to be two tipes of files in the filesystem: text or binary. At that time the only binaries where the exectuable ones (no need for images or videos in shell, really), so executables are still called binaries in Linux. Therefore they are not "really wrong" naming them binary blobs. The name should be changed as binary blob sounds stupid, but old customs die hard. But hey, it could be just me being too picky. ;)

18. jove39

Posts: 2154; Member since: Oct 18, 2011

Its very easy to say google engineer's didn't optimized code...but when you have delivery deadline pressure...priorities change...first and top most priority is to release defect-free build...we postpone optimizations to next build (mean postponed forever) and hardly ever revisit...but rarely it happens that we plan a build which is not functional enhancement but based solely on optimization. I hope google could cleanup stuff...and release refreshed Android 4.1...It'll be really cool...I am not sure if someone had tried compiling 4.0.4 build here...I tried from has butt load of warnings...and make script need couple of tweak to make it work out of the box (has problem with open jdk)...Anyway...I hope google comes clean...incorporate all suggestions of Linaro team...and we get best ever Android build :)

14. thunderising

Posts: 232; Member since: Nov 25, 2011

Optimize for low end SOCs like Cortex A5, A8 and all. Quad cores don't need this!

15. MichaelHeller

Posts: 2734; Member since: May 26, 2011

Yes, let's all spend our time optimizing for obsolete hardware!

13. kanonk

Posts: 14; Member since: Dec 21, 2011

"closed binary blobs" - blob means binary large object, wich makes it "closed binary binary large objects" =)

10. Ubi2447

Posts: 131; Member since: Feb 14, 2012

Thumbs down for Thumbs down.

9. scnix

Posts: 41; Member since: Jul 01, 2010

What's with all the thumbs down?

11. Riven

Posts: 25; Member since: May 25, 2012

AppleseedTroll lurks somewheres...

3. eDiesel

Posts: 142; Member since: Mar 17, 2012

Once again.... open source at its finest. Everybody helps everybody. Im glad its not gluttonous and closed minded.

2. Captain_Doug

Posts: 1037; Member since: Feb 10, 2012

I love this stuff. "Oh PS, the OS you really really like can be even faster without hardware changes" Music to my ears.

8. MichaelHeller

Posts: 2734; Member since: May 26, 2011

Actually, it's more like Android could be even faster if the code were optimized more. Google focused on UI and features with ICS (as with Froyo), so it will be focusing on optimizations now. We're hoping Linaro is part of that, but it will happen either way.

21. ahomad

Posts: 175; Member since: May 15, 2012

I am not sure if I understood correctly, you said ICS update was mainly updating UI and features, but what I usually read in any topic is that ICS made huge performance upgrade. there seems to be conflict in here or am I confused?

26. MichaelHeller

Posts: 2734; Member since: May 26, 2011

There was a huge performance upgrade with ICS, but that wasn't the main focus of the update. The point is that Google could have optimized the software more than it did, but chose to focus more on UI and features.

1. mas11

Posts: 1034; Member since: Mar 30, 2012

So does this mean that most devices running or getting ICS will see Jelly Bean, since it is enhancing performance not redesigning the UI?

7. MichaelHeller

Posts: 2734; Member since: May 26, 2011

This has nothing to do with it really, but yes devices running or getting ICS should eventually see the Jelly Bean update. All updates should get pushed to all compatible devices. The only outlier there has ever been in the Android line is Honeycomb. Everything else should make it out, assuming manufacturers do it.

12. mas11

Posts: 1034; Member since: Mar 30, 2012

Thanks for clarifying!

22. ahomad

Posts: 175; Member since: May 15, 2012

Honeycomb is android version made for tablets only. Jellybeans is also romured to be aimed for tablets improvements as well (given that android tablets not doing well). so we might not see this update hitting android phones.

25. MichaelHeller

Posts: 2734; Member since: May 26, 2011

Jelly Bean is rumored to be launching with the Nexus tablet. It's not rumored to be exclusive to tablets.

17. jove39

Posts: 2154; Member since: Oct 18, 2011

Officially...forget it...but dev community won't take long...since code base will be similarly structured and they'll be done with optimizations for ICS by then

* Some comments have been hidden, because they don't meet the discussions rules.

Latest Stories

This copy is for your personal, non-commercial use only. You can order presentation-ready copies for distribution to your colleagues, clients or customers at or use the Reprints & Permissions tool that appears at the bottom of each web page. Visit for samples and additional information.
FCC OKs Cingular's purchase of AT&T Wireless