Fragmentation in Android: Boon or Bane
Android is fast becoming the smartphone OS of choice for many handset manufacturers today. Handset manufacturers like Samsung, HTC, Sony Ericsson, Motorola, etc have chosen Android to be their smartphone OS of choice. Each of the devices install a specific version of the Android OS. Android OS versions released by Google are internally codenamed as pastry names. The versions of Android released are Cupcake for version 1.5, Donut for version 1.6, Éclair which was initially released as version 2.0 followed by an update to version 2.1, Froyo for version 2.2. The latest version of Android codenamed Gingerbread is anticipated to be released any time now. These frequent software releases from Google makes the handset manufacturers in a constant catch-up to provide updates to their consumers. Handset manufacturers are in a constant act of balancing their software R&D costs between releasing new devices into the market vs. providing software updates for their already shipping devices. This cycle has lead to the fragmentation of Android. The following pie chart and gives the distribution of Android as per the data collated in December 2010.
What is causing fragmentation?
In order to understand Android fragmentation we need to understand the software upgrade R&D cycle of a device manufacturer. Shipment of devices by Handset manufacturers or OEMs (Original Equipment Manufacturers) can be broadly classified into two categories: operator specific devices and non-operator specific devices. Operator specific devices are devices shipped in an operator network like Verizon, AT&T, Vodafone, etc. These devices are tied to the respective operator network. Non-operator specific devices are not tied to any specific operator and usually sold as “unlocked” devices. Unlocked devices are most popular in countries where the operator does not subsidize the device costs and bundled with a voice and data plan or contract. In Q3 2010 the total shipment of phones with Android was 20 million devices, which also makes it the 2nd largest smartphone OS in the world in Q3. Out of this shipment, 9.1 million devices were sold in the US operator market, which makes it 45% of shipments for operators in the United States alone. From this it is clear that the volume of operator specific category of devices is a large. Further, operator specific devices entail more R&D and hence this category is discussed in more detail below.
Operator Specific Features: When a phone is to be shipped in a North American or European operator network the OEM has to comply with the specifications published by that specific operator. These specifications are usually related to some specific nuances of an operator network configuration or more commonly services that are provided by an operator. An example of the former is AT&T. When AT&T and Cingular merged, a feature called EONS was made mandatory. Broadly this feature allows for a user with an AT&T SIM card to lock onto to Cingular and vice-versa. Another example is Verizon with its service of LTE and CDMA. This service has lot of specifics, related to telephony of two different types of network access standards. Such features are not provided for in the plain vanilla version of open source Android. They have to be implemented by the OEM. The second type of operator specific customizations is related to services provided by the operator. For example, Verizon provides the “Visual Voice Mail” service, Vodafone provides the “Vodafone Live” service and so on. Each such unique services provided by an operator requires a specialized application which complies with the respective operator specifications. Once again, these features don’t come as part of the open source Android release. They have to be implemented by the OEM. All the above described customizations typically impact Android vertically through its various OS layers. Hence, to upgrade to a new version of Android, OEMs have to migrate all these operator specific customizations to the new version. This entails time and R&D costs.
OEM Specific UI: The UI that comes along with the plain vanilla open source version of android is commonly known as “Stock Android UI”. The UI is one of the most differentiating factors of software. UI is what can make a man to machine interaction simple and intuitive or rather complex. Obviously, every OEM wants to have a much richer and enhanced UI compared to what is available in stock android UI. So each OEM has their differentiated UI. To name a few, HTC’s UI is branded as HTC-sense, Samsung’s UI is branded Touch-Wiz and Motorola has branded their UI as Moto-Blur. When an OEM wants to upgrade a device to a newer version of Android, all custom UI modifications also need to be migrated. Once again, it entails time and R&D costs. One key factor we have to bear in mind is that once all the changes are migrated to the new release all functionality and performance needs to be re-tested to make sure nothing is broken.
Kernel upgrade: Usually a new Android version is also accompanied with a newer version of the Linux kernel. Each device has its specific hardware components like LCD, GPS, WIFI, etc. So an OEM will have to make all the necessary kernel related changes to make sure that the new version of Android can be ported onto the device. It typically takes and OEM anywhere between 3 to 4 months before they can make a public release of the upgrade. This cycle has to be done per device. Once a device has been shipped, it is usually gets a lower priority from the device manufacturers to get an Android upgrade going because they concentrate their efforts on the new devices which are on their roadmap. Sometimes devices never get a software upgrade because either, it’s too old a product for the OEM to spend R&D money or the hardware is just not powerful enough to run the new version of Android. Either way, it leads to fragmentation in the Android device market.
Impact to developers
A paradigm shift came along with the launch of Apple “App Store”. The equivalent application store from Google is “Android Market”. Developers quickly realized the potential of adapting to Android as it maximizes the user reach for their applications. This is because development is on one OS but the same application will run on devices manufactured by multiple OEMs. Google also enhanced the incentive for developers by providing advertising support within applications. This was a significant shift in paradigm where advertisements within mobile applications were previously unheard of. This enabled developers to publish their applications for free but monetize via advertisements. Most of the application developer community comprises of small companies ranging from being a single developer to a small team of 3 to 4 developers. With the fragmentation of Android, developers are strained with a balancing act. They have to make sure that their applications work on all different versions of Android across varying UI interfaces of OEMs. On the other hand they are in a constant race to add more features to their apps or develop new apps. A typical dilemma is when a developer is planning to use some new APIs of let’s say Gingerbread while wondering how many users will actually get to use it. Statistics show that even in December 2010 approximately 40% of devices still run Éclair. So there-in lies the dilemma; whether the company should concentrate on features that would give maximum user access or develop features based on the new version and wait till it gets a bigger install base. What has been described so far is only related to new feature development. There is still the part where developers have to make mandatory changes to support their applications on newer or different versions of Android. Given below is an example of the frustration a developer has expressed on a Slashdot discussion.
Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don’t even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there’s no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
While I visited one of the Google office lobby’s I noticed that they had a large LCD screen displaying a spinning globe. It was afternoon by Indian time. This globe had certain regions of the globe lighting up in different colors. Each flashing dot on the globe indicated a Google search being invoked from that particular region. The dots also flashed in different colors indicating the language of the search. The United States was brightly lit up with the California region being especially bright. This was followed by Europe. The regions of Asia especially India and China were sparsely lit. Regions of Africa pretty dark. Watching this display, a realization of the emerging market potential dawned on me. Most of the access to the Google applications is currently accessed via a PC. However, the PC market is not growing at the same pace of the mobile market. This means the growth of internet accessibility is going to be via mobile devices. But, the large part of the emerging handset market is based on feature phones which are not internet rich. If more and more users start using smartphones, I would expect the globe lighting up faster in the emerging markets. Therein lays the power of open-source and Android for Google. One of the key driving factors of mobile phones in the emerging market is the price point. In India the sweet spot is between $100 and $150. But there are always users who are willing to pay more for more features and even more for getting the most advanced device. What this means, is that there is an inherent fragmentation enforced by the consumers and this is more proclaimed in the emerging markets. One of the key factors in the driving the device price point is the BOM (Bill Of Materials). Newer releases of Android have a more and more demanding need of hardware from the device. For e.g. the latest release of Android Gingerbread incorporates features like NFC and Gyro. These additional hardware components increase the BOM cost, thereby increasing the device cost to the user. So, OEMs have to find ways to decrease the BOM One example is to use the Android Éclair or even the Donut version with lower powered hardware. It is becoming a trend of consumers who were buying high-end feature phones to switch to low end smartphones. The price point being referred to is $150 to $200. Users who were considering a top end Nokia S40 phone are considering low priced Android phones from Samsung. Semiconductor companies like MediaTek based out of Taiwan primarily focuses on the China and India markets. This trend will only increase the fragmentation in Android. India and China being large population markets, this trend cannot be ignored. Developers will have to be more and more innovative to come up with efficient ways of addressing varying Android segments.
Opportunities arising out of fragmentation
Each new version of Android comes with new enhancements and cool features. Android being open source all new features of a particular release are known to the world. Every user is keen to have the greatest and newest Android version on his or her device. User buying behavior also indicates that the availability of the newest version on a device is a key factor in the device buying decision. Hence it has become a necessary evil for OEMs to continuously provide software upgrades to their existing shipping devices to help improve their volumes. This is compounded by the fact that operators also impress upon the OEMs to release upgrades to the devices shipped on their network. In the earlier part of this discussion it has been highlighted that OEMs are starved of R&D bandwidth and are in a balancing act of new devices vs. support of already shipping devices. This fragmentation of Android has led to interesting potential business opportunities for the professional services industry. Since OEMs would prefer to concentrate on R&D work for new device launches, they have started looking for external help on maintaining and upgrading Android OS versions. Further, OEMs are pushing this pressure down the chain to semiconductor companies. Semiconductor companies are in the business of creating newer and faster processors and not in the business of software support. Companies like Sasken are in uniquely positioned to cater to such new opportunities. Partnerships with semiconductor companies, deep relationships with OEMs and an experienced Android pool make companies like Sasken Communication Technologies are positioned right for such business potentials.
The Google factor
Google’s primary source of income is advertising. Almost every product of Google displays context sensitive advertisements. Their income comes typically through a pay per click model. If a product or service does not directly generate revenue via advertisements then its purpose is to help improve products which generate revenue to become more efficient, thereby making those products or services generate more revenue. This can be best explained via an example. The Google DNS service is a free service. When users adopt to this service, Google has access to almost all data traffic patterns of a user. This kind of stats will then enable Google to model users on a various parameters. They can model based on region, language, etc. The better the prediction of what an user is looking for, the more efficient the Google search results can become. Advertisements can then become more directed. This means more people will choose to advertise with Google Adwords and hence more revenue. Let’s look at how this applies to Android. Android is free and open-source. Is it really? The Google app-suite in Android is not part of the open-source package. By Google app suite, I’m referring to Google Maps, Gmail, etc. The most important of them all is Android Market. These applications have to be licensed by the OEM. These applications have a two part agenda. One of course is to generate direct revenue via advertisements. However, a more unstated reason is to collect stats of an user. An individual typically carries a mobile phone through-out-the day. Further, an individual uses a phone for various activities from email to shopping lists. If someone has to model an user pattern using the device he or she uses, the mobile phone is ideally suited for this purpose. Android as a platform works perfectly for this purpose. Using the stats collected, Google can model this data and improve their services in various ways. One of the rumors is that the “instant search” in Google search was developed based on the stats received by Google mobile apps. So, how is Google trying to control fragmentation today? The answer lies in what is called a compatibility test suite. If a device is to be branded Android, the device has a pass a bunch of tests as defined by the android compatibility definition. This compatibility is defined at http://source.android.com. The compatibility definition also defines mandatory components in hardware. For e.g. an OEM cannot make an Android device without GPS. The reason stated is to reduce fragmentation. Google has to play a careful role with controlling fragmentation. If they decide to tighten control over Android, the China-India market might create an open source derivative which means that Google loses control.
Whether the fragmentation of Android deepens or not, it is not evident right now. What is definitely true is that Android has opened multiple business avenues for companies participating in various aspects of the wireless industry. What does lie in the future of the Android market space is something one just has to wait, watch and experience it with time.