Android Virtualization: It's Time

With device update lag seemingly becoming an epidemic on the Android platform, there’s only one answer to nip this problem in the bud once and for all: Virtualization.

James Kendrick, our new Mobile News columnist has a serious beef with the mobile carriers and the device manufacturers. It’s taking them way too long to get updates out for all of the Android handsets out on the market.

The Android platform is extremely successful and it’s only becoming more so. By this time next year, it will almost certainly eclipse the BlackBerry as the leading smartphone platform in overall market share.

That’s great news for Android, but there’s a downside to this rapid expansion. There’s a vast array of handsets currently on the market, not to mention all of the devices that were released in the last year or so, all of which have unique “Value Add” in their modification of the Android OS, a.k.a platform fragmentation.

The downside of having such a successful Open Source platform like Android is that we’ve got multiple manufacturers building devices based on a development source tree coming from Google, and those manufacturers are on completely different schedules and their level of effort varies from company to company when it comes to testing and developing Android for their own hardware. This includes releasing updates to Android for their handsets.

Packaging up a release of Android for a single handset or even a family of similar handsets is no trivial matter, as it requires building the platform from source, integrating device drivers and also performing carrier-specific customizations. Every single manufacturer of Android devices has to undergo this process, every single time an update to Android comes out.

They may have some automation for building and testing in place, but this is still a huge pain in the butt to do. And this process of regression testing and quality assurance takes time.

Apple (and to a similar extent, RIM) doesn’t really have this problem because they are only building their software for a limited target device group. There’s only one major revision of iPhone and one iPad out at any time, and keeping legacy models updated is much less complicated because there are far fewer models to deal with.

Apple and RIM also own the OS and platform in question, so there’s a much tighter integration of the workflow and integration processes when a new version of iOS or Blackberry OS comes out.

So what’s the solution to the Android mess then? Do we just throw our hands up and accept that the process is never going to be as efficient as Apple’s or RIM’s? Or can we leverage technology and processes/methods to alleviate it?

There is an answer and I’ve discussed this before: Device Virtualization.

Also Read: Wind River, Tasty Embedded Linux Treat

Also Read: I want an iPhoneStormDroid

Also Read: Virtualization, an easy way to kill Apple’s HTC lawsuit

Now, I realize that I am something of a Virtualization fanboy. No, scratch that, I’m a HUGE virtualization fanboy. But Virtualization is the only answer to the Android fragmentation and updates problem.

How so?

First, let’s understand what benefits virtualization on smartphone devices brings to the table. Assuming that the Android ODMs and OEMs can agree to standardize on one or two hypervisor platforms which abstract the hardware from the operating system, the process of developing ROM updates for Android smartphones and even tablets becomes a great deal easier.

The benefits of virtualization have already been realized in the datacenter on the x86 server platform, as well as with mid-range UNIX and even mainframe systems.

For example, when Microsoft or Red Hat releases a new version of Windows Server or RHEL, there’s much less activity that goes on now to certify that OS against new x86 server hardware made by IBM, HP and Dell because on a virtualized platform, those vendors are putting less emphasis on developing specific hardware device drivers for Windows.

As a result of virtualization becoming much more de rigeur, and due to of the economies of scale afforded by data center consolidation and increasing server density using technologies such as VMWare, fewer and fewer organizations are running the majority of their servers “On the metal” now.

The low level device drivers which used to be in the OS are now integrated into the Hypervisor, and it becomes a group effort to by the vendors to integrate that support there instead of the OS.

Instead, the hypervisor vendor creates “virtual” device drivers that expose common services to the virtualized OS, such as networking, display and I/O. No matter whose hardware that virtualized version of Windows or Linux is running on, it runs exactly the same, provided the same hypervisor is used. Doesn’t matter if the Windows or Linux is running on IBM, HP, or Dell.

In fact, that image can be transferred between different vendors and run without any changes at all.

In virtualization parlance, this abstraction of the OS from the hardware using pseudo-devices is referred to as “Paravirtualization”.

For datacenters, that hypervisor means VMWare ESX, Microsoft’s Hyper-V, Citrix’s XenServer or Linux’s KVM. On Android, this could mean Wind River’s embedded hypervisor, another vendor’s embedded hypervisor (such as VMWare’s Mobile Virtualization Platform) or possibly something that Google buys or creates in-house.

One such possible acquisition target for Google to integrate this functionality into Android is Open Kernel Labs, which has a functioning “Microvisor” that already has been demonstrated on partner handset platforms and is shipping in selected devices today.

As seen in the first demo, shown below, the OKL4 Microvisor permits even the weakest ARM9 200Mhz processor to run a Linux smartphone fully virtualized with no loss of performance.

With built-in virtualization in Android, the very same benefits that companies like IBM, Dell and HP derive from hypervisors in the datacenter could also be enjoyed by HTC, Motorola, LG and Samsung.

Regardless of which hypervisor gets chosen, the result is the same: Google builds ONE master Android image that is guaranteed to run on the hypervisor, which in turn runs on a multitude of handsets.

So from the perspective of the handset manufacturer and the carrier, the customizations are done to the master image — no need to build from source every time, no device driver debugging, et cetera. And as seen in the second Open Kernel Labs demo below, it allows for a much more secure architecture for enterprise use as well.

So instead of customizing an OS to run on specific vendor hardware, it becomes generic, and “templates” of that generic image can be built which can then be further customized as needed. That’s where the carrier and manufacturers come in with their value add, and where the speed of getting OS updates out to the end-user is realized.

Virtualization on the device’s time has come. It’s now up to Google and the Android handset ODM/OEMs to agree to move forward with it.

Does Android need a hypervisor to get out of the update cycle mess? Talk Back and Let Me Know.