This just in: Big screens and little screens are different and your excessive worry over forking Android 3.0 is misplaced. The real problem is the OEM and Carrier crapware.
Ok, so I go away for a few days and everyone gets their panties in a twist over whether Android 3.0 is a fork.
My ZDNet colleagues, Steven J. Vaughan Nichols and Chris Dawson have been at odds over the topic.
SJVN says Android 3.0 is a fork:
If you look at the Android Honeycomb highlights, it becomes even clearer that Honeycomb is going its own way. There is some good news for developers who don’t want to re-do their Android 2.x work for Honeycomb. As the Web page states, while “The new UI brings fresh paradigms for interaction, navigation, and customization and makes them available to all applications—even those built for earlier versions of the platform. Applications written for Android 3.0 are able to use an extended set of UI objects, powerful graphics, and media capabilities to engage users in new ways.”
and Dawson says that it isn’t.
Just as the underlying core of Ubuntu doesn’t differ between the various partner projects or user interface “spins,” Android 3.0 represents far more of a UI change than a true fork. The underlying technology is Android (meaning Linux, Dalvik, and Java), 3.0 is backwards compatible with 2.x and simply gives developers the tools and UI necessary to properly exploit larger tablet screens. There are, after all, plenty of apps designed for the iPad that aren’t available on other iOS devices.
Okay, both of you, get a room. And the two of you are wrong. Well, you’re both right and wrong, but let me get to the real issue at hand.
Android 3.0 is a fork. The user interface has changed, and there will be new APIs. Gingerbread and Honeycomb are distinctly different development targets even though Android 3.0 is compatible with the Android 2.x APIs. So we should freak out about this? No.
Look, sometimes you NEED to fork something in order to address a specific problem. Guess what? Apple’s iOS for iPhone and iPod Touch and iOS for iPad and the Apple TV are also FORKS. Yes. They are. The only reason why nobody is screaming and yelling about it is that there is only one company making iOS devices: Apple.
The iPad’s implementation of iOS has its own distinct applications that are pre-loaded into the ROM — such as a special version of Mobile Safari, an optimized Mail app, its own built-in version of iTunes, et cetera. All of these were done by Apple to address the fact that the screen on the iPad is bigger and higher-res than its iPhone/iPod counterpart and as a result of how the devices are actually used, there will be differences in the user experience.
The UI for the main iOS shell might be the same between the two devices, but where it counts, the two versions of iOS 4.2.x are FORKS. The codebase is not identical. Most iPad apps are distinctly different binaries than the iPhone/iPod ones because they have scaled graphics and a number of other things that require changes.
Universal binaries for iPad and IPhone, while they do exist, aren’t nearly as common. There may be a concerted effort to try to do more of this in the future by iOS developers and perhaps Apple in order to minimize development efforts as the devices start to share more characteristics such as screen resolution, but I’m betting that iPad apps and iPhone apps will be largely separate for some time to come.
But is this even an issue? Does anyone in iOS app development land really care if the two platforms never completely sync up? Do you ever see New Media pundits complaining about it? Of course not. The reason why nobody cares is because Apple is in full control of its ecosystem, it prohibits carriers from adding any sort of major modifications or changes, and there’s only a few models of the iPad and iPhone out at any time.
As with iOS, Android also requires two distinct versions because guess what, the user experiences between a small screen and a big screen are different. And while Google chose a completely new shell (UI) for Android 3.0 and Apple didn’t for the iPad versus the iPhone, both companies made changes where it counts most, in the built-in apps baked into the ROM.
Here is the real problem. It ain’t the fork, folks.
If Google only had just vanilla versions of Gingerbread and Honeycomb as the two distinct development targets, and everyone ran just the vanilla versions of these platforms on their phones, the situation would be manageable.  What makes things untenable is that the Android OEMs/ODMs/Carriers and their “Value Add” that they keep putting into the the phones and tablet ROMs.
Right now, each OEM has their own special UI layer and apps that they like to throw on top of the existing OS that Google releases. HTC has “Sense”, Motorola has “Blur” and so-on, all with their own various API additions and specialized apps that in many cases replace basic vanilla Android functions. This is what is creating problems for developers, not the actual versions of Android.
Android software developers target their apps against Google’s Android SDK, which simulates the various versions. Most Android developers aren’t the Rovio Mobiles of the world who can afford to buy one of every flavor of every device from every carrier, it just isn’t practical.
Your average Android shop is a one or two man operation, who maybe has a few devices on-hand to test against besides their SDK Android simulator. So when their application blows up on the latest Motorola/HTC/LG/Samsung/Dell/Sony Ericsson whatever, they’ve got no easy way to regression test if it works fine on their test devices, even if it is the same version of Android on the new model on which it is breaking.
I’d liken this situation to the average PC consumer who cannot buy PCs with “Pure” Microsoft Windows on it. Instead, they get systems with “crapware” and other OEM garbage and utilities that may bog down performance and cause application issues.
There’s an entire cottage industry of crapware-removal utilities in order to get your PC running “Pure” Windows 7. And some end-users will go as far as blowing away the OS on their PC and re-installing Windows from scratch using retail Windows DVDs in order to get that “Pure” experience.
The solution to the Android problem is simple: Short of forcing OEMs/ODMs/Carriers to standardize on the “Pure” versions of Gingerbread and Honeycomb for their smartphones and tablets, Google needs to lay down the law and require that anyone who wants to have access to the Android Market (device certification) has to start with a vanilla base and then install the “Value Add” components on the Micro-SD card/internal flash storage and not in the ROM, so that consumers have the option of reverting to a “Pure” Android if they want to.
And if consumers want to re-install those components, they should be able to do it from carrier or OEM-hosted 3rd-party App Stores, or by carrier/manufacturer specific sections of the Android Market.
I would also go as far to say that Google needs to make clear rooting instructions and the ability to use 3rd party ROMs, such as an official Google ROM or even custom ROMs made for vertical and enterprise use an absolute requirement for vendor certification for their devices.
The issue of warrantee invalidation of a rooted device by a carrier or manufacturer is certainly up for debate, but the consumer absolutely should not have to jump through all sorts of hacker hoops to install alternative firmware if they are fed up with update delays or refuse to use “Value Add” software. It should be a simple, painless and standardized process.
The fact that the only way I can currently get a consistent Android experience on my year-old DROID and my HTC EVO 4G is via using CyanogenMod’s version of Gingerbread or Froyo rather than the stock offerings from those two vendors or Verizon or Sprint is embarrassing for the Android developer community to say the least.
Now, I realize that factors such as differences in device drivers on hardware makes standardization on a single ROM image difficult. However, as I discussed in a previous article, much of the pain of managing ROMs and OS updates could be alleviated by using a built-in “microvisor” to virtualize the OS.
This would give users choice between the “Vanilla” official version from Google or the “value-added” carrier version or even custom versions like CyanogenMod that might fit their needs better, and would also provide the tools for enterprises to securely partition “Bring your own” devices between personal and corporate data and applications.
Do we really have a “forking” problem, or does Google simply need to lay down the law with the OEMs and Carriers to reduce their “Value Add” crapware on Android devices? Talk Back and Let Me Know.
Courtesy - zdnet.com