Android is crushing Apple and Microsoft in the mobile device market

Android is crushing Apple and Microsoft in the mobile device market

Summary: In five and a half years, Android has come from nowhere to crush Apple and Microsoft in the mobile device market. How long until PC OEMs decide to take a gamble on the winning mobile OS and load Android onto PCs?


In five and a half years, Android has come from nowhere to dominate the mobile landscape during the first quarter of 2013, according to a new report from research firm Canalys.

The market — which takes into account smartphone, tablet, and notebook shipments — grew to 308.7 million, representing year-on-year growth of 37.4 percent. But despite this market segment including traditional notebook devices powered by Windows, it is Android, a product of the Open Handset Alliance, that is making the biggest gains.

During the quarter, Android was the operating system powering 59.5 percent of smart devices shipped. Behind Android was Apple's iOS with a 19.3 percent market share, and Microsoft, with 18.1 percent.

And it is tablets that are driving this growth, not smartphones, and definitely not notebooks. Over the period, worldwide tablet shipments increased by 106.1 percent year on year, to 41.9 million units, and while Apple continues to be the big fish in the tablet space with a 46.4 percent share, even the iPad is not immune to Android, as it lost share for the third consecutive quarter.

The Canalys data for the quarter speaks volumes.

(Image: Canalys)

But let's take this data and bake it into a pie.

(Image: Canalys/ZDNet)

Presented this way, it is clear that Android is crushing Apple and Microsoft in the mobile device market, putting the squeeze on not only Microsoft, but Apple, too, the company that sparked the smartphone and tablet revolutions in the first place.

While some analysts are pondering Android's demise, I really can't see how the operating system can put a foot wrong. About the only weakness I can see is that one company — Samsung — dominates the Android landscape.

Given Android's success in the mobile market, one has to wonder how long it will be until we see the operating system loaded onto PCs and go head to head against Windows and iOS. Given the way that buyers (consumers and enterprise alike) have embraced Android on smartphones and tablets — activations of new devices sit at 1.5 million daily, or 45 million every month — it seems logical to give consumers what they want, and put this operating system onto notebooks, convertibles, and hybrid systems.

When it comes to PCs, neither Windows nor OS X seem to be igniting the imaginations — and opening the wallets — of consumers. Cheap (possibly in the region of $200) PCs would be just what PC OEMs need to inject a new lease of life into the stagnating market.

Topics: Mobility, Android, Apple, iOS, iPhone, iPad, Laptops, Microsoft

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
  • An OS with

    .. a virtual machine and java at its core on PCs? No thanks, I can't imagine how the experience will be, and I say this as a fan of Android. I guess even low-end PC hardware will handle it nicely, but I just don't trust the OS to run good and not start lagging after a while. But again, I guess even low-end PC hardware should be enough for Android.
    • Which OS?

      None of the listed ones have Java at the core.

      Android uses Dalvik. Any Java must be translated first. And you can use C or C++ if you prefer. Any language that generates Java byte code can have that generated bytecode compiled into Dalvik code.

      As far as "lagging after a while", I think that is owned by MS.
      • as far as I know..

        .. most apps are Java programmed, and the dalvik virtual machine executes that code, but since it's a virtual machine, it takes more resources than others. Android's RAM usage (per app) is off the charts compared to other OS and it also requires much more power to run nicely, and something is the culprit for that. Look at OS like MeeGo, true multitasking but still runs great on single-core. Or Maemo or Symbian.

        Basically, whatever it is, Android is the most resource-heavy OS out here, so what's the reason for that?
        • so use the C/C++

          Though fitting it into the security model of android might be difficult.

          Each app runs under its own UID, separating it from all the others. As far as resource-heavy, haven't heard that.
          • C/C++ producing bytecode?

            Are you an Android App developer? Can you generate machine independent binary on Android using C/C++?
          • it looks you can

          • you can what?

            generate byte code using NDK? Using NDK, which currently supports ARM7, ARM5, MIPS, and X86 instruction sets you will need to generate separate binaries for each of these, which means NDK doesn't support byte code output, which makes sense, and to use C/C++ you must use NDK, and this is really for certain components that can be optimized better in machine code than byte code.
          • Re: you will need to generate separate binaries for each of these

            You can build native code for all supported Android architectures into a single APK. The system will automatically choose the right code to load.
          • Not just c/c++

            Heck, you can do it with c#.
          • Doesn't have to.

            There is an interfacing toolkit.

            How limiting that is I don't know. As long as the code is for ARM v9 (I believe) it will run on all of them.
          • ARM v9 machine code runs on all?

            other CPU architecture? Never heard of such thing, unless it's some sort of emulation layer that runs machine code of different CPU architecture, which would perform even worse than the byte code implementation. What is the interfacing toolkit called?
          • Problem is more fundamental than just the language.....

            The fact that Dalvik VM uses register based architecture instead of stack based architecture should significantly lower the performance of Dalvik process VMs. Add to it the additional step of conversion from .class files to .dex files taxes compilation process. But I did read that Dalvik uses JIT compilation and uses further compiler optimizations to save memory space to suit mobile device constraints. Which also explains why newer multicore mobile machines seem to run older Dalvik VMs better.

            But as regards using C/C++ code using NDK, the Android page an earlier poster ForeverSPB posted here states that NDK API usage with C/C++ code will not result in noticable performance improvement. I wonder what could be the reason behind this. Native applications have always been faster than VMs on most machines as I know of it (even today C++ on Windows or Linux is faster than Java EE on the same platform).
          • Android domination is actually more stronger (72%)

            Latest figures of Q1 2013 smartphones by Digitimes:

            Android 75,5%. Total 216,3 million smartphone sold, 163,5 million of them were Android.


            "Smartphone shipments came in at just over 216.3 million for the quarter, maintaining the strong growth (47.9%) that the market saw throughout 2012. Android handsets accounted for 75.6% of total smartphone shipments, and Samsung dominated once again, growing its volume by 64.3% on year, which helped its market share exceed 32%. In contrast, Apple saw modest annual growth (6.7%) in its smartphone shipments, the lowest level since the launch of the original iPhone back in 2007."

            Then tablets. Q1 2013 by IDC: 49,2 million tablets sold, 27,8 million of them were Android (56,5%).

            Total: 265,5 million smartphones and tablets sold in Jan-March 2013. 191,3 million were Android:

            191,3/265,5 x 100 = 72,05% for Android
          • Actually, you have that backwards.

            The register architecture of Dalvik reduces the amount of time consuming stack manipulations required to access parameters. It allows a much more streamlined execution path.
          • @ jessepollard

            The truth is somewhere in the middle.

            That fact depends on multiple variables most of which were resolved through the 90s to 2000s. Performance of register machines was faster back then when spillover of variable values to memory was costly due to cache access times. Register machines could keep most of the accessed automatic variables on registers instead. But this is also a problem for register machines when more register values themselves spillover to memory across nested proc calls.

            Stack scheduling can take care of this on stack machines. The subexpression problem can be solved the same way. Better variable analysis by compilers and increased use of parallelism by modern CPUs has eliminated these problems. A hybrid machine model will also serve good. Intel and VAX CPUs did well, haven't they?

            This also explains why Java's 8-bit stack machine performs just as good as any comparable register machine VM. I am not sure Dalvik's use of 16-bit instructions and use of a virtual register machine model has really helped it. But I do not have the data here. What I write is from my programming experience on C++/C# and Java. So I should temper my previous words 'should significantly lower' to 'may significantly lower'.

            The main problem I see here is that inspite of reusing the Java class structure and functional VM model, Dalvik may not have any outsized advantages to offer over Java. If there is no new problem to be solved with Dalvik, there may have been no need for creating it in the first place.
          • Why create Dalvik

            The purpose of creating Dalvik was to break free of control from SUM Microsystems and its potential suitors (like Oracle) who could have potentially throttled Android, and the rest is history.
            It was a business-led strategic move which was smart in hindsight and not an engineering led move
          • @ abledoc

            We are talking business strategy. Sure.

            That also explains the paradox on transforming legacy enterprise Java client/server projects to the Dalvik platform. Currently there is no talk yet of Dalvik as an enterprise server (in the mold of Java EE and Java server and more). But that need will arise and Google will have no answer since Java EE is good enough for legacy Java clients.

            Google has a few great products (engineering wise) - Google File System, data mining algorithms in Google Search - but they have missed the enterprise server boat. It is a matter of time before others come up with better enterprise versions of their mobile and fixed client and server offerings.
          • Re: Though fitting it into the security model of android might be difficult

            Native code fits into the Android security model just fine.

            As they say in the biz, Dalvik is not a "security boundary".
        • Reason for Android heavy usage.

          High RAM usage is by design. Android is going to run the active on the screen app as quickly as possible and then when not in use move a snapshot image of it to memory for quick referencing on resume. It is not the most effective use of multitasking, but it is the best way to great performance out of low powered devices. It is also more RAM intensive for power management reason (write to RAM consumes less power than to other media). Also the idea of a virtual machine running more resource than a standard OS isn't necessarily true, why do think Enterprise is invested in them so heavily?
          • I think it's clear...

            you have no idea what you're talking about.
            RAM consumes power (a lot of it).

            "Enterprise" (what the starship enterprise?) use virtual machines because they're easier to work with, delete, start new ones: you can use one machine and run a lot more OS instances on it. what is cheaper to you? using 1 machine to run 5 OS instance or using 5 different machines?
            with 1 machine you save space, power and money.