Android, the "F-Word", and the Trade-offs of an Open Platform
"The thing is, nobody ever defined “fragmentation” — or rather, everybody has a different definition. Some people use it to mean too many mobile operating systems; others to refer to optional APIs causing inconsistent platform implementations; still others use it to refer to “locked down” devices, or even to the existence of multiple versions of the software at the same time. I’ve even seen it used to refer to the existence of different UI skins. Most of these definitions don’t even have any impact on whether apps can run!
Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn."
However, Android "Compatibility," Morrill said, is a real challenge. Whether or not an app built with the Android SDK runs properly on certain devices depends on factors such as buggy hardware, different physical components (camera, touch-keypad or physical keypad), and added or altered APIs. That's where Android's three pillars of compatibility come in:
- The Android source code
- The Compatibility Definition Document
- The Compatibility Test Suite
Morrill explains, "Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device. For the most part, Android devices are running the same code." Even those who are not as familiar with Android realize that the core of the OS is stable so that Android apps are at least "100% forward compatible" (although there's no guarantee that this will always be the case).
The Compatibility Definition Document is a list of requirements for device manufacturers (OEMs) that tells them which components they may or may not omit, and that the official Android API may not be altered. All Android handset makers adhere to these rules because it gives them the advantage of a wider pool of applications.
Finally, the Compatibility Test Suite helps OEMs mitigate the bugs that occur when putting the OS on so many different sets of hardware. The suite currently consists of more than 20k test cases that check for the known issues that Google has accumulated.
While some say that Google's current solution is not doing enough to make life easier for developers (who have to write many extra code paths for an application to reach the full Android-user market), others see it as a necessary trade-off for the freedom of an open platform running on multiple devices. Windows and Linux PCs, and even Macs have a variety of hardware and software to deal with. To prevent all of the hardware related pitfalls, you would need to have a locked-down platform, and that has its own set of disadvantages.
Morrill says that for Android, "The choice is in app developers’ hands as to whether they want to live on the bleeding edge for the flashiest features, or stay on older versions for the largest possible audience. And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded."
The Android Marketplace will help developers by making sure that all developers have to do is list their apps' requirements and they'll do the rest to make sure your app is only accessible in the Android Market to devices that will run the app properly.