When is an Android an Android?
This article may contain personal views and opinion from the author.
Recently, we've been talking about the supposed Android "fragmentation" problem, and how we feel like the word is misused, loaded, and inherently wrong for the issues at hand. If we're talking about slow updates, then talk about the problem of slow updates, and the role manufacturers and carriers play in that issue. If we're talking about inconsistency in UI because of manufacturer UIs, talk about that. If we're talking about app issues because developers only put apps on certain devices, then that's the issue. However, they don't all add up to some ultimate issue of "fragmentation", which insinuates some sort of underlying flaw in Android.
In reality, all operating systems live with variations in the version of software running and device specific issues. But, only Linux can be called "fragmented", because it is the only platform where you have multiple major distributions with different requirements, different UIs, different ways of handling software repositories/software installation, etc. all of which adds up to requiring different app versions for many different distros, and creating a different method of user interaction.
In reality, all operating systems live with variations in the version of software running and device specific issues. But, only Linux can be called "fragmented", because it is the only platform where you have multiple major distributions with different requirements, different UIs, different ways of handling software repositories/software installation, etc. all of which adds up to requiring different app versions for many different distros, and creating a different method of user interaction.
Android doesn't have most of those problems, and the ones that do exist can't be said to cause much more than annoyance in a group of users. If you're running a 2.x device with Sense UI or a stock 4.x device, you still get everything from the Play Store, the apps all work except for a few exceptions, with which the devs are more to blame than the Android system. Sure, there are extra features in 4.x that someone wouldn't get without the update, but that's how every platform works. iPhone 3G users couldn't do "multitasking" even with the iOS 4 update. No one gets Siri except the iPhone 4S. That's the way things work. New devices/software get the newest features first. In the Android ecosystem, that trend is just highlighted more because of the delay between Google introducing a new update, and that software actually making it to handsets. And, yes there will be minor variations in the UI of skinned Android devices, but it is certainly nothing to cause that much trouble.
There are definitely problems in the Android ecosystem, but the only problem that could conceivably be pinned under the heading of "fragmentation" would be the forks with the Kindle Fire & Nook Color/Tablet or other devices not sold with the "with Google" tag and corresponding Google Apps. For clarity in this discussion, we'll refer to devices like the Kindle Fire as "forks" and all non-Google approved Android devices as "NGAs" (non-Google Androids).
The real "fragmentation"
Google, as many of you may know, has created Android with this "fragmentation", built-in to the way Android operates. On the bottom level is the (relatively) open-source half of Android, which can be freely used by anyone for any purpose; and, on the top level is the Google Android experience, which requires a certification process by which manufacturers have to adhere to certain standards, and include certain hardware and software in devices in order to be allowed to offer the Google Apps, including Gmail, Talk, Maps, Calendar, and most importantly, the Play Store.
Devices that don't bother with this certification process, and therefore don't have the "with Google" tag do create fragmentation because it fundamentally changes how the platform operates. Suddenly, you can't get apps from the centralized Android repository of the Google Play Store, where apps are monitored, updated and allow easy access to developer support, and don't have the same feature set of Google Apps included on your device. Of course, even these concerns are often dealt with, since many NGAs do have alternate app stores installed, like GetJar or SlideME, which can be quite feature-rich, although will likely lack some features of the Google Play Store. With general NGAs, this can cause confusion in the market because the devices will look just like any Google-approved Android device, but may be a completely different experience. Often, a much more difficult experience because of the inherent problems with using alternative Android app stores. However, there is real value in this option, because it allows for extremely inexpensive smartphones without some of the required pieces of hardware needed for the Play Store license, which is a huge benefit for poorer regions of the world. And, in areas of the world where $200 handsets and carrier subsidies are more common, it is far less likely to see an NGA on the market, aside from the random tablet sold at K-Mart, so the problem isn't as pronounced.
The other major issue that factors into the real "fragmentation" problem with Android is with Android forks. This is where a manufacturer not only uses the free, open-source bottom level of Android, but adds a custom experience over top of that to create devices where the entire Android UI is completely wiped away, like with the Amazon Kindle Fire or Barnes & Noble Nook Tablet. Devices like this are actually far less detrimental to the overall Android ecosystem than people usually think, because even though they are technically Android underneath, users rarely know or have reason to care that the device is Android-based.
The biggest difference is in the fact that NGAs are very likely to be marketed as Android devices, because in some cases the Android name is the best marketing advantage the device may have. This makes sense also because the devices often look like stock Android, just without the Google Apps, but it can cause quite a bit of confusion because of the visual similarities. If NGAs are marketed as Android devices, people tend to assume that means Google Android, and can be disappointed when those expectations aren't met. However, with forks, there should be no expectation of a Google Android experience, because these devices are rarely marketed as having Android. Rather, these devices are more likely to be completely divorced from the Android name.
In fact, if you have an Amazon Kindle Fire, you may notice that nowhere in the system is the word Android mentioned. Even when going to the Amazon website there are extremely few occurrences of the word "Android". On the Kindle Fire product page, the word "Android" is used twice, only once by Amazon (the other is in a quote from CNet) and both instances are in reference to the Amazon Appstore. In general, the only reference to Android is in the fact that the Amazon Appstore is technically called the "Amazon Appstore for Android", because it began life as an alternate to the Android Market, and can be installed on any Android device. If the Appstore were to ever become proprietary to Kindle devices, you can be sure that Amazon would erase the word Android from the name. The Barnes & Noble Nook Color/Tablet are even more divorced, and would never really use the word "Android" in any material connected to the devices.
How Google limits problems
As we mentioned before, Google has compatibility requirements that devices must meet in order to get the Google Apps suite, but the very first rule in that set of requirements is one that essentially removes NGAs and forks from the "fragmentation" discussion. We don't like the term "fragmentation" because it insinuates some sort of incompatibility between devices, but in reality this simply cannot exist under the rules for hardware. Rule number one for even using the Android name is that the device must be able to "run any application written by third-party developers using the Android SDK and NDK." So, if every device must be able to run "any application" written with the Android SDK and NDK, that allows Google to assert control on manufacturers, but unfortunately, Google doesn't have similar rules to force hardware compatibility on app developers. Android hardware must be able to run Android apps, but Android apps are not required to work with all hardware. This is a problem, but one without a clear answer as Google would not want to alienate developers or carriers by eliminating app exclusives (a differentiation factor for manufacturers/carriers) in an attempt to force compatibility.
Once that first requirement is met for hardware to use the Android name, then we get into the long Android Compatibility Definition Document (CDD) to determine if an Android device will be allowed to license the Google Apps and Play Store. This CDD outlines exactly the hardware and software requirements that devices must meet including the minimum memory requirements based on screen size and screen density, the required media codecs, support for OpenGL ES 1.0 and 2.0, and more. Google splits these guidelines into MUST, MAY and SHOULD, to differentiate what devices are required to include, what is optional, and what Google highly recommends.
There are actually relatively few "musts" in the CDD at least on the surface. Google may not expressly mandate much as far as hardware or software, but most items listed as a "may" or "should" are immediately followed by a "must" requiring the labeling of Android "constants" which let the system know what devices have (or don't have) certain hardware or software. This allows for app filtering in the Play Store, so users with devices incompatible with a certain app shouldn't even see that app in the Store. Combine these "constants" with the fragments system for Android development, which allows apps to be scaled easily between screen sizes and densities, and Google has created a clear path to making sure apps work on devices.
Conclusion
NGAs and forks do not need to meet any of these requirements or guidelines in the CDD. NGAs must at least conform to the requirement to use the Android name, but forks don't even need to do this much. Of course, if a fork is not using the Android name anywhere on its device, like the Kindle Fire or Nook Tablet, there is really no harm to Google or the Android ecosystem. Most casual users are unlikely to even know that those devices are based on Android.
NGAs can cause confusion, and do create a bit of "fragmentation" insofar as users may expect the Google experience, or expect a certain set of features either on the device or in the app store provided on the device (if such a store is provided), but NGAs are becoming less and less common. As Android has evolved, so has the CDD, meaning that devices that were at one time not allowed access to the Android Market (like Wi-Fi only tablets) are now allowed because certain rules (telephony requirements) have been changed. So, now unless it is an extremely low-budget device with very barebones hardware, it will likely be able to get access to the Google Apps.
Going forward, we may see fewer NGAs, but more forks as companies like Baidu create proprietary apps to take the place of the Google Apps. Some may say that this will mean more "fragmentation" even by our standards, because it could be that companies will add in their own software, but still use the Android name for marketing. This is possible, but as we've already seen with Amazon and B&N, there isn't much value in companies creating a fork, but sticking with the Android name. If you create a fork, it's to highlight your own brand. So, we wouldn't be surprised if "fragmentation" by our definition may rise, but it actually won't cause much problem with the Android ecosystem, because the fragmented forks will be so far divorced from the Android world.
Things that are NOT allowed: