Android Virtualization: It's Time

Android Virtualization: It's Time

Summary: 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.


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.

Topics: Android, CXO, Cloud, Google, Hardware, Storage, Virtualization


Jason Perlow, Sr. Technology Editor at ZDNet, is a technologist with over two decades of experience integrating large heterogeneous multi-vendor computing environments in Fortune 500 companies. Jason is currently a Partner Technology Strategist with Microsoft Corp. His expressed views do not necessarily represent those of his employer.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • interesting

    very interesting but i wonder how these devices can handle the loss of performance and even using virtualization i think there will still be a problem regarding oems and operators customizing android the way they want.
    • RE: Android Virtualization: It's Time

      @bnlf If we're talking about Wind River's platform for example, the overhead is minimal. Probably less than 5 percent performance loss for using a hypervisor, if that.
      • And even better


        If the entire platform were standardized on with a hypvervisor it would be far superior to Wind River's performance. You'd be looking at a Type 2 hyperviser like the server platforms you mentioned which are all capable of hitting pretty close to 99% performance. Especially since you'll only have one VM running on the hypervisor.

        I think it's a terrific solution for those of us who use Android. The problem is it takes a huge excuse for developers to not do updates, which makes it harder to sell that mobile upgrade constantly. It's bad for the manufacturer and carrier so I doubt we'll see it happen anytime soon.
      • Standard platform

        @jperlow, I'm not familiar with Wind River, but it seems to me that you wouldn't even need true virtualization, from the standpoint that all hardware functions are EMULATED in software. A standard API layer should suffice -- similar to Java, where there are deep hooks in to the hardware (now), but an app is expressed as a general set of APIs that bind to and exploit those hardware hooks similarly on different hardware platforms. In other words, things like file system, timer ticks, cpu and memory allocation, as well as IO would NOT need to be virtualized, ASSUMING they all performed the same way on HTC vs. iPhone vs. Moto.

        I will continue to push this: The main thing we HAVE NOT SEEN and sorely lack in the mobile (handset) world is adequate virus protection. I feel that multi-core architectures will be conducive to antivirus, where it has traditionally been viewed as too expensive from a CPU / memory standpoint on conventional handsets.
    • RE: Android Virtualization: It's Time

      @bnlf Typically the overhead is very small
  • Is there a problem than cannot be solved by virtualization?

    Jason Perlow investigates.
    • RE: Android Virtualization: It's Time

      @urbandk I'm looking into global warming and world peace, I'll get back to you on that.
      • RE: Android Virtualization: It's Time

        @jperlow Ha ha!
      • RE: Android Virtualization: It's Time

        As far as I am aware, Second Life has neither global warming nor war - and it is a virtual world ;-)
      • RE: Android Virtualization: It's Time


        virtualize war by having both sides decide by playing halo.

        virtualize CO2 by turning us all into computers via that xfiles brain upload episode.

        We just saved the world!
      • RE: Android Virtualization: It's Time


        Could not resist ;-)

        Global Warming: is a function of 22-year solar cycles coupled with the amount of saturated water vapor in the atmosphere.

        World peace: requires a point of equilibrium, but a man named Lorentz showed that an equilibrium point within a chaotic system can act as an attractor without ever resolving to that single point. So the best we can hope for is normalized behavior between nations that exists in predictable patterns, yet does not escalate.

    • RE: Android Virtualization: It's Time

      @urbandk - only problem not solved by yet another layer of abstraction are the ones that it creates....

      now - where are my cloud virtulaization tools, you know, the one that allows me to virtualise all the cloud providers together into one big metacloud with one management console (and in 5 years time - my metacloud virtualisation tools)
      • virtualise all the cloud providers together into one big metacloud with one

        You mean ?
  • RE: Android Virtualization: It's Time.

    First the JIT has to be good enough to ensure impact on battery life is minimal.
    Maybe in a few years when Android is mature.
  • Agreement on Standardization in Open Source?

    "So what?s the solution to the Android mess then?"

    Package Managers seemed to work well for the Linux community, in my opinion. Maybe what Android needs is an RPM or an APT equivalent to ease the pain of it's so-called "fragmentation" that the media keeps reporting on.

    Virtualization is also an interesting concept, however, I think that you seem to have made a poor assumption here:

    "Assuming that the Android ODMs and OEMs can agree to standardize on one or two hypervisor platforms..."

    If agreement on standardization was possible, there would be no "fragmentation" issue to begin with. Am I right?
    • RE: Android Virtualization: It's Time

      @Linville79 It's not really a package manager issue.. Android apps come in packages, but the whole OS does not. <br><br>This isn't a problem on a PC because you have the PC's BIOS. Any new Linux install or OS upgrade can boot the PC, load their installer, suss out the hardware, install the new kernel and necessary drivers, etc. <br><br>On Android, the drivers are, apparently, just merged into the whole boot image by the OEMs... no modularization here. What's needed is abstraction (as I mentioned in another post)... there's the piece Motorola touches, there's the piece that's Android proper, and there's a very thin API between the two. Any new version of Android would plug into that Motorola HAL; any new phone would present a HAL that accepts all of Android. This would also mean than Cyanogen(mod) and other custom builds could be made just once, and they'd run on any device. While that might take out some of the fun, think of all that spare time available for actual improvement to Android by the good people at Cyanogen.
  • why? apples going to have

    100% of the smartphone market by 2012 so what does it matter if android is updated or not!?!
    Ron Bergundy
    • RE: Android Virtualization: It's Time

      @Ron Bergundy You are definitely true to your avatar... what a JW.
    • RE: Android Virtualization: It's Time

      @Ron Bergundy Apple is past their peak on smart phone share. This was made very obvious in 2010 by how quickly Android surpassed iOS... 2-3 quarters ahead of where most pundits predicted it would happen.

      Don't fret... Apple will continue to rake in more profits than any other smart phone company. But they lack the will to compete across the board with Android; they only want to be the Mercedes of the smart phone world. Mercedes makes a great car, but most folks can't afford one. And if Mercedes made something to compete with a Ford Fiesta or Honda Civic, they'd actually damage the brand.

      Apple has exactly the same problem. At this point, the only way to grow iOS faster is to lower the bad, which would hurt their profits. Same thing with Macintosh computers.. they can't keep selling Macs at 2x-3x the price of comparable non-Mac PCs and expect to take more than a small share of the desktop market. And yet, if they really tried to compete with HP and Dell and all those guys, they might well be successful in growing the Mac market, but they're lower their profits to match the other commodity PC vendors.

      Apple will never do this. So they are guaranteed a shrinking percentage of smart phone and before long, tablet markets. Their PC market has shifted a bit, they sell more units, but fewer high-end units, thanks to a boost in lower-end Macs driven by the iPhone and iPad. However, that coattail effect is so far only in the USA.
      • I agree, but, I think that perception of superiority is wearing out

        @dave@... Not worn out but in the process.

        Right now I suspect that iPhone are only considered to be a little bit superior and that's arguable.

        Even on the PC side other than the look and feel, I don't think they have much of an edge, either in performance or reliability. Even the OS doesn't appear to remarkably better or more secure.

        The iPad on the other hand...