Android: The Path to Unification. It’s Here!

We often hear in the media about the pitfalls of Android fragmentation. To be sure, Android apps developers have struggled with creating portable applications that work across devices and OS versions. Developers have also struggled to gain traction and make money in an open apps marketplace with no prescreening and low prices. Recent data from Flurry Analytics shows that for every $1 a developer earns on iOS, he or she can expect to earn 24 cents on Android. Ouch!

##IMAGE_2_C##

Despite these very real challenges, Google has taken many actions to address developers’ concerns, and solutions are in effect. During my keynote at COMPUTEX, I outlined these actions along with other factors propelling Android towards unification and a more streamlined apps development landscape.

Let’s go back a couple years, about five if you can believe it. Steve Jobs liked to ‘think different,’ and his company’s work resulted in a fluid operating system with best-in-class hardware and the iTunes ecosystem – true vertical Apple style.

##IMAGE_3_C##
MIPS Principal Mobile Architect Amit Rohatgi

Google’s Andy Rubin, on the other hand, wanted to drive the proliferation of apps across all types of devices, from all types of manufacturers – a more horizontal challenge. This was a daunting task given the amount of variability in architectures, IP technologies, screens, capabilities, costs, geographies etc. In a sense, Google took on the fragmented ecosystem that already existed, with the singular goal of unifying it while still allowing for companies to differentiate.

The first significant step towards unification came in December 2011, with the release of Android 4.0 “Ice Cream Sandwich.” This version of Android was the first to merge phone and tablet APIs into a single UI theme called Holo, that is portable across OS versions and devices. Google has taken many additional steps to unify the Android development landscape:

• The creation of workshops and training sessions to help developers (and OEMs) maximize portability, such as the Android Training in Dec 2011. Unified design principles in Android help developers code once – regardless of device—with the use of layouts and fragments.
• The launch in Feb. 2012 of a dedicated Android Design website to help developers ensure that their content looks good across a wide variety of devices.
• The creation of a rigorous and constantly improving compatibility test suite (CTS) and accompanying compatibility definition document (CDD) to certify devices that meet the highest quality of API standards (over 25,000 tests).

Each of these steps has created a friendlier, more consistent development environment that encourages the creation of more applications, and better applications!

Not long ago, the Android market was viewed a bit like the “Wild West.” You never knew what you might get. In many cases, apps would just not work on all devices – and this problem was highlighted when the first tablets came out. The Motorola Xoom, for example, despite awesome hardware and much marketing fanfare, failed miserably – partially due to app compatibility. This is one of the many reasons why developers found it to be a headache to bring quality content to Android. And of course another key consideration for developers is the obvious goal of monetizing those apps. Many of these issues were addressed with the launch of Google Play in March 2012:
• Malware Blocked: Malware (or rogue applications) are now constantly scanned for and are immediately blocked or removed.
• Expanded Availability: Google Play is now available in 130 countries, increased from 30 last year. A big leap! More eyes on the content – more monetization potential.
• In-App Purchasing Improvements: More and more apps are moving to this model. Consumers trying to purchase an app on the go (or at home) are much more likely to do so if they don’t have to pull out their credit card. With iOS, new app purchases are automatically billed to a consumer’s iTunes account. This is now a growing movement in Android too.
• Auto-renewing subscriptions and one-off payments: Auto renewals allow content providers (such as magazine and comics subscriptions) to provide their content to consumers on Android tablets and phones with automatic monthly billing.
• Direct Carrier Billing: Direct carriers who provide billing have expanded from two to 15 carriers since last year. This allows app purchases to appear on the consumer’s carrier bill.
• Improved Architecture Filtering: With MIPS now officially supported by Google in Android, the market needed to show only compatible apps. This allows for a superior user experience.

In reality, most consumers could care less about the architecture of their phone, tablet or computer. What they do care about is a consistent user-experience of applications across their devices, despite the architecture. Google has clearly been addressing this by unifying APIs and making changes to Google Play. Consumers also care about having choice, which is inherent in the open source nature of Android. Finally, consumers care greatly about cost. By being architecture-neutral and allowing diversity, Google has allowed for a massive increase in Android tablets and phones which in turn drives down cost for the consumer.

For example, with official support for the MIPS ABI, more than 1.8 million (and growing!) MIPS-Based tablets have now been added to the Android family. Furthermore, Google’s inclusion of MIPS in Release 8 of the Android Native Development Kit (NDK) is of great benefit to both consumers and developers. This move paves the way for more developers to push out apps that are compatible with multiple architectures, resulting in more revenue for developers, and apps that provide consumers with a consistent cross-device user experience.

For OEMs, the openness of Android allows for differentiation. This is obvious by the sheer number of Android phones employing different interfaces today, such as the HTC Sense, Samsung TouchWiz and Motorola MotoBlur to name a few. Each OEM is free to choose different SoCs (Qualcomm, TI, Nvidia, Actions, Ingenic), different architectures (MIPS, Intel, ARM), various screen sizes and inclusion/exclusion of hardware (GPS, Bluetooth, NFC, cellular, etc.). This differentiation benefits consumers, who have greater choice, and OEMs, who can customize their products. Thanks to the aforementioned initiatives by Google, app compatibility across all of these permutations of devices is growing rapidly, thereby reducing fragmentation yet allowing for diversification.

So what’s a developer to do? Embrace the differentiation! Adhere to the APIs! Use the latest APIs (e.g., fragments & layouts) and code portable (on top of Dalvik or using the NDK r8 for all architectures). Follow this advice and use the many tools Google has put into play, at Google Play and elsewhere! The stepping stones to Android’s unification have been laid. Developers need only follow the path.

Take part in the discussion here.

Author: Amit Rohatgi, Principal Architect, Mobile, MIPS Technologies