Gingerbread taking Android to the masses
In my previous article titled “Fragmentation in Android: Boon or Bane”, I discussed the various aspects of fragmentation in Android and how it impacts the respective parties involved. The article was written before the release of Gingerbread. Gingerbread is now out. As with each Android release Gingerbread has its own compatibility definition published by Google at http://source.android.com. There is an interesting turn that Google has taken in this compatibility definition which is discussed in this article. This change in the compatibility definition can help OEMs reduce the BOM (Bill Of Materials) thereby enabling them to produce devices at lower costs.
Compatibility definitions before Gingerbread
The compatibility definition is a requirements document to which an OEM (device manufacturer) has to comply, in order to call a device Android. The primary focus of the compatibility definition is to make sure that there is conformance to all public APIs. The document apart from addressing the software aspects also covers specific hardware features that a device MUST, SHOULD or MAY have. The definitions of MUST, SHOULD and MAY are as per RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt). In short, MUST means mandatory, SHOULD means recommended but not mandatory and MAY means optional. In view of not going way back into the past, I have limited the analysis to Éclair and Froyo definitions. Now let’s talk more about the mandatory hardware components mentioned in the compatibility definition since they impact the BOM. OEMs typically produce similar devices varying across different price segments. These are typically known as variant devices. For example the variant devices may not have GPS or Bluetooth or even a camera. Such hardware features is what I call as auxiliary components. By reducing the auxiliary component list the OEM can reduce the BOM cost which then reduces the per unit price that a buyer finally pays. Let’s examine some of these auxiliary components in the Éclair and Froyo compatibility definitions. GPS, accelerometer, digital compass or magnetometer, camera, and Bluetooth are all mandatory components. Each of these components cost money. So as per the Éclair and Froyo compatibility definitions there is an element of control that Google exercises over handset manufacturers.
Google’s stand during previous versions (Éclair and Froyo)
Before the advent of the concept of an app-store, users bought a phone and were content with the applications that came built in. This behavior started changing with smartphones. The credit goes to Nokia for popularizing Symbian based smartphones. However, Apple and now Google have taken it to the next step with the Apple App Store and the Google Android Market. Nokia has also followed with the Ovi Store. Application developers use the SDK of the respective smartphone OS and develop innovative applications and games. It’s now not only about what a smartphone offers with its default built-in applications but the variety of applications that users can download from the respective app store. In the context of Android, Android Market is a huge success which offers a large range of applications and games. Google took it one step further, by enabling application developers to monetize via ads in their applications. So in a sense, application developers are revenue channels for Google. In view of the above context, Google felt it was important to make the Android platform homogeneous across various devices. This included making a bunch of auxiliary hardware components mandatory. This way a developer could assume that such hardware components were present on all Android devices, thus making their code paths simpler. In my opinion, this was Google’s way of helping control fragmentation in Android.
Compatibility definition in Gingerbread
Gingerbread is the most recent release of Android from Google. It was released late December 2010. Along with the release of Gingerbread the Gingerbread compatibility definition has also been published. It is interesting to see that all the auxiliary components which I have mentioned earlier have been marked as “SHOULD” in the document. This means that such auxiliary components are now not mandatory but rather recommended.
What does this mean?
This move by Google might not delight application developers. However, OEMs can now produce Android handsets catering to various price segments. OEMs can now make devices with a subset or none of the auxiliary components thereby reducing the BOM cost. A market research firm isuppli estimated the Google Nexus One BOM to be $175. Let’s hypothetically speaking get rid of these auxiliary components from this BOM list.
|Camera (5.0 MP Auto Focus)||
|Bluetooth / WIFI||
|Magnetometer (Digital Compass)||
The revised Nexus One BOM cost would now be $146. Please bear in mind that we are not talking about the per unit price that a user would pay but only the BOM cost. Per unit price also includes R&D, testing, certification and manufacturing related expenses. With these BOM reductions, there will be other direct cost savings related to R&D, testing and certification which is not factored here. OEMs can further optimize BOM costs by reducing application phone storage memory. This is because; in Gingerbread the applications storage shared memory minimum in the compatibility definition has been reduced from 2GB to 1GB. I believe the year of 2011 will see a lot of low cost Android devices being launched, especially in the India-China markets. Of course, there will be high end devices like the Nexus S, but, there will also be devices which a common man of the emerging India-China market can afford. This will make Android not only a high end smartphone but also a device for the mass market.