A recent rant led me to read Matt Porter’s slides titled “Mythbusters: Android“. Matt’s analysis is a laundry list of Linux no-no’s found in Android. I became curious about whether any of these technical issues would really matter to Google, so I stopped by the OHA site to look at what they claim about Android, and do the analysis from that direction.
The OHA is pushing the notion that it’s all about the applications (copying Apple’s “there’s an app for that“):
- “The platform will continue to evolve as the developer community works together to build innovative mobile applications.”
- “Android breaks down the barriers to building new and innovative applications.”
- “Android provides access to a wide range of useful libraries and tools that can be used to build rich applications.”
This notion that it’s all about the apps seems to be working well for Apple. One big difference between Apple and OHA is that Apple only needs to support its own platform, and Apple owns the entire software stack. This lets Apple provide developers with well-defined boundaries around what the platform can do. Android, however, isn’t playing in such a simple environment, and needs to deliver benefits beyond a single platform if it wishes to live up to its claims.
Matt points out that there are several problems with the Android stack that could prevent or hamper development on Android, at least for traditional Linux/UNIX developers.
- Bionic: Android’s own libc implementation is for ARM/x86 only, has only partial pthreads support, has no IPC support, has no STL support. That’s a lot of stuff that Linux app developers need to work without.
- Device Management: Standard Linux distros use the highly-configurable udev and hal components to manage system device enumeration and hotplug support. Android has hard-coded devices into their own init system, so developers will need to modify the init system for any “non-standard” hardware.
- Power Management: Hard-coded for handsets. If you have a disk or other non-handset devices, you’re on your own.
So the benefit to Android device users may be the applications from the Android Market. From the perspective of device manufacturers, you get a high-investment, low-differentiation, ARM-based phone, that can participate in the Android market. Does Google care about the technical issues Matt points out? We’ll have to see whether Google invests in lowering the barriers-to-entry on Android, making system-level configuration easier, supporting a larger number of architectures, and providing standard programming interfaces that developers expect.
