Why Google’s Android makes me gag

I really enjoy the commentary from the guys over at the Register and this post from last week deserves some attention:

Google claims ‘non-existent’ Android beats everything but the Jesus Phone

It basically covers some comments made by Rich Miner, of Google’s Android, about how Android’s “openness” is so awesome that developers everywhere will build wonderful things with it and how evil Apple is for keeping the iPhone under such tight wraps. This kind of talk has shown up a lot lately from the Android camp and I have to say every time I see it - it makes me gag- and here’s why…

I’m no Apple fan-boy but let me throw out a few of the incredibly difficult issues to deal with, how Apple is addressing them with the iPhone and how Google seems to be addressing them with Android (I say seems because in reality, there are almost no real details about Android)…

#1 : Fragmentation
I’ll define fragmentation up front as the variance between two different model handsets. Fragmentation is bad for developers because it forces us to modify our application in order to account for the differences between handsets. This is good when it means we get access to new features - this is bad when it means we have to write 10 versions for 10 handsets all with the same features.

Apple solves fragmentation by being the single-source distributor, for both its hardware and software, and even provides a firmware upgrade path for devices in the field to keep them up-to-date with devices just shipping. This has historically been a monumental problem in mobile and Apple has stepped in and addressed it right at the start with their very first handset. I’m confident that even when Apple introduces an additional iPhone model, applications will run on it as well without the write-once-test-everywhere burden we’ve all come to know.

Android, by contrast, isn’t a product per-se at all, but rather an open stack (if we are to believe Google) which OEMs can take and modify to their hearts’ content and produce Android handsets. But therein lies the contradiction - if the stack is truly open and OEMs can do whatever they want, then there will be different processor architectures, memory configurations, form factors, input methods, etc. That means fragmentation folks, and now as a developer I’m back to testing my application on every “Android” handset that ships, right?

Well, not so fast. While Google pontificates the “uber openness” of Android, what it really means is that OEMs will get the code base under some sort of open-source license. For us developers, the only access to the platform is by writing a looks-like-Java-but-isn’t Dalvik application, using the APIs which Google gives us. As much as they tout the Linux underpinnings, there’s no way your or I will ever write a line of C code. So maybe the fragmentation problem won’t be so bad (as long as OEMs don’t go adding their own API libraries to Dalvik to open access to device features which aren’t present in the Google APIs), but if its not then they should not tout its openness, because you can’t have both.

#2 : Distribution
A huge problem for us developers, with BREW being the large exception to the rule, is distribution of our applications once we’ve developed the 18 versions we need. Apple’s move here is masterful in that not only are they the distribution point via iTunes, but Apple is creating the discovery experience for content themselves - and they’re building it right into the iPhone’s interface. They solve two enormous issues in one stroke - ensuring that consumers will have a consistent and quality discovery, download, and installation experience while simultaneously giving developers a one-stop distribution stop.

Android on the other hand is fuzzy at best on both of these points. If anyone has any further details please share, but I haven’t heard much but the sound of crickets from the Android camp. A lot of it depends on the reality of #1 up above, but all I have is more questions…

• Is Google also signing up to distribute apps out to all the Android handsets that pop up?
• If Google is distributing them, does that mean they’re certifying them? How could they manage that for an “open” platform, when each one would potentially be unique?
• If they are certifying and distributing apps, why would an operator even want Android devices if they are once again cut out of the value chain?
• How are Android consumers going to discover new applications? Will it be different on each device? The platform is “open” so why wouldn’t it be an area where Operators/OEMs would differentiate?

If the platform really is so “open” and ripe for innovation then how are these issues going to be resolved?

#3 Revenue
Again, Apple allows us to name our price, even Free!, and they’ll handle hosting, distribution, and billing duties, giving us a turn-key approach to seeing an actual return for all our long hours and Jolt colas. Now granted, this isn’t new, BREW developers know just how nice this arrangement can be (despite the rediculous toolkit and certification fees), but how will Android handle this? Once again, this issue depends upon the realities of #1 and #2 above. If Google isn’t the distribution point, then we as developers face the same two options we largely have today, some sort of “on-deck” for whatever that means on an Android device and “off-deck”. I think we all know the issues with both of these approaches by now so I won’t go repeating them - but if you’re like me - the hair on the back of your neck just stood up.

—

I can say from experience there are even more, somewhat subtler issues Android will have to address. Of course there are certainly enough PhDs over at Google to address these things, but the combination of Operator needs, OEM desires, developer needs, and of course, consumer needs, is a tall order. I for one would just like to hear less talk about how being “open” solves everything - as it solves nearly nothing - and would rather hear answers to the real problems we all face.

Posted by Mark Posted in: Mobility No Comments » March 2008