The Problem with Android
by Mark W. Hibben
Why an Android iPad Killer is Unlikely
Although the latest version of Google's Android mobile operating system offers some improvements on its predecessors, it’s not enough to overcome the platform's fundamental structural deficiencies. The application architecture of Android is fundamentally at odds with mainstream operating systems such as Windows, Mac OS X, and even Apple’s iOS for mobile devices.
The differences are mostly “under the hood”, and therefore invisible to most consumers, but they nevertheless impair the performance and stability of apps created for the Android platform. Therefore, I don’t expect Android tablets to make much headway at the premium end of the tablet market, where Apple reigns, and where Microsoft intends to challenge with the Surface. The architectural differences of Android disadvantage it relative to its competitors such as Apple iOS and Microsoft Windows 8/RT. In my opinion, that's why Android tablets have only significantly penetrated the low cost end of the market.
The Very Definition of Ad Hoc
Unlike Apple, Google had no pre-existing community of developers for Android when it was unveiled in 2007. Google adopted the Java programming language for Android as a way to tap into a ready made community of developers for its mobile platform. The need to accommodate the Java programming language forced Android’s departure from the traditional app creation process.
In the diagram below, I contrast the application creation and execution processes (application architecture) for iOS and Android. iOS follows the traditional approach of compiling from a programming language (Apple’s Objective C) directly into the machine code for the specific processor of a given mobile device.
Android’s path is more complicated. First, Java programs are compiled into a generic “byte code” rather than machine code for a particular processor. On a Windows or Mac PC, this byte code would then be translated into machine code by a Java virtual machine (JVM) installed onto the computer. Rather than use a Java virtual machine for Android, Google created its own version of a virtual machine, called Dalvik. Dalvik doesn’t actually translate Java byte code. Instead, Java byte code is first translated into .dex (short for Dalvik executable) code by the developer using the dx tool. Getting confused yet? This is what I mean by ad hoc.
If you’ve ever run Windows emulation software on a Mac, then you have some idea of the performance hit involved with running the virtual machine approach. There are techniques that the Java Virtual Machine and Dalvik use to speed things up, but in general, the JVM works as well as it does on Intel pc’s (either Mac or Windows) because modern Intel processors have a lot of excess capacity in the form of multiple processing cores. The ARM processors found in mobile devices tend not to be so well endowed with processor cores (typically 2-4) or as fast and powerful as Intel processors. To make matters worse, each and every app running under Android has to have its own Dalvik virtual machine, since all apps are “sandboxed” from one another.
I became familiar with the Android application architecture through some research I did when I was considering becoming an Android developer. But the performance implications didn’t really sink in until I performed some comparison testing between the Asus Transformer Prime and the third generation Apple new iPad for a review. With a quad core nVidia processor running at a maximum of 1.3 GHz, the Prime should have left the iPad in its dust, but in most tests, especially CPU intensive tests, the Prime was slower.
Most consumers aren’t in the habit of running extensive performance tests on their mobile devices, but the impacts of the Android application architecture can still be felt in subtle and not so subtle ways. The effect this has on customer satisfaction can be seen in a recent J.D. Power customer satisfaction survey on tablets, published in September. The iPad scored the highest in overall satisfaction and was only lower than its competitors in one category: Price.
The survey results also reflect the overall market position of Android tablets. The iPad occupies the upper echelon of the tablet market, and popular Android tablets such as the Kindle are at the lower priced end of the market. Android’s explosive growth in smart phone market share has not been duplicated in tablets. As IDC’s latest (published 12/5/12) Tablet Forecast shows, Android tablet market share was 39.8% in 2011 and is projected to grow to 42.7% for 2012. This stands in stark contrast to smart phones, where Android market share was 46.9% in Q2 2011 and grew to 68.1% in Q2 2012, according to an IDC report published 8/8/12. I believe this reflects the fact that people simply have higher expectations for tablets than they have for smart phones, and that smart phones tend to run simpler apps where the performance disadvantage of Android is less apparent.
I think part of the reason for the relative valuation of Apple and Google shares at the moment is a perception that Google is poised to grab market share in the tablet space as it has in smart phones. What I’ve tried to do in this discussion of the Android application architecture is explain why that hasn’t happened already, as well as motivate expectations for the near term.
Google shows no sign of dissatisfaction with using Java, so we can expect this baggage to weigh down Android for the foreseeable future. Investors can monitor metrics such as the J.D. Power survey and IDC’s tablet market share data, which comes out quarterly, for signs of a shift upmarket, but I mainly expect a gradual expansion of tablet market share based on low cost models. That being the case, there will probably be a positive correction in Apple’s stock price following its next quarterly earnings report, assuming its price doesn’t turn around before then in anticipation.
Is there a possibility of a dramatic improvement in Android’s performance and reliability? Many reviewers of Android devices have commented on Android’s “rough edges”, numerous little things that didn’t work quite right. Always it is assumed that these will be fixed in the next version of Android. For instance, I noticed that the built in Browser had difficulty dealing with changes in the Transformer Prime’s screen orientation. Now that Android 4.1 is installed, I don’t have that problem anymore -- since Browser crashes consistently on start up.