A unified platform with the same OS across all devices. It’s been a defining feature of the iOS platform since day one and impressed it’s importance on the development community with the introduction of the iPad last year.
At its I/O conference Tuesday, Google announced that Android 3.1 would also become a unified platform across all devices, bringing with it the improvements of the Honeycomb tablet OS and the advantages of a singular OS across the breadth of Android offerings. In addition, they introduced an initiative to ensure that devices get timely updates to the Android OS for at least 18 months from the date of release.
So. Much. Tech.
Some of the biggest names in tech are coming to TNW Conference in Amsterdam this May.
These measures, along with the newly introduced Google Music service and Android Accessory API’s, indicate that Google is trying to circle it’s metaphorical wagons to ensure good footing against iOS 5’s rumored cloud services.
Traditionally, Google has had the edge over iOS when it comes to device syncing. From the first Android devices, users have enjoyed the ability to fire up a device, log into their Google accounts and be up and running with their personal information and access to their purchased apps in minutes. While its execution of syncing is not entirely perfect, Google’s system is far more mature than Apple’s, which is, well, almost nonexistent at this point.
One of the largest hurdles for Google in perfecting Android’s sync mechanisms has always been the disparate versions of Android run by devices. If a phone from HTC and one from Samsung are running different competing, customizations of the Android OS, it can sometimes take weeks or months before they’re updated with the latest version of Android, if ever. This leads to improvements in sync and other portions of the OS filtering out slowly to devices from some manufacturers while others that run a stock version of Android getting them immediately. Customer confusion and a wildly different Android experience between some devices have abounded as OEM’s try to differentiate their offerings from one another.
This isn’t even touching on the way that multiple Android app stores in addition to the stock Android Market affect how and when people can install apps that they have purchased.
The core experience of sync is beautiful when it works. I’ve owned and tested many Android devices over the years starting with the G1 and have been able to get most of them up and running with at least basic information and without much trouble. The devices that have performed the best are, unsurprisingly, the devices with little in the way of UI and system customization. Google is appropriately unsatisfied with the ‘when it works’ portion of that statement and has been looking for ways to unify the experience of Android users.
Cloud music syncing is now a core OS feature.
In addition to stabilizing the core syncing experience, Google has also added a new service to its beta lineup. Google Music Beta was also introduced Tuesday at I/O as an online music syncing library that allows users to stream their music to their devices over the air. In addition to a standard application that is used to play music on a computer and upload their music library, a player was introduced for Android devices that gives users access to their music wherever they are.
The music player app for Android already works with the new Music service and will serve as a gateway to user’s content. Unfortunately early reviews of Music Beta aren’t all that positive but Google has always had a reputation for getting products out now with a solidly affixed ‘beta’ label and working out the issues with them in the public eye. The real test will be getting Music into fighting shape before the release of the inevitable music service from Apple.
The urgency in getting a streaming music service up and running isn’t Google’s purview alone though. Amazon just dropped its Cloud Player music service and while no one knows what Apple has planned for WWDC, it seems generally accepted that they will be introducing a music streaming service linked to a product called ‘iCloud‘. It’s becoming clear at this point that if a cloud syncing music framework isn’t built into your OS, you’re doing something wrong.
The inability to download songs permanently to a mobile device using Music stands out as a weakness, although this is due not to technical limitations but licensing ones. Although Google states that what it is doing with Music is ‘completely legal’, they don’t have the cooperation of the music labels. This makes re-downloading songs from your storage off-limits for now. This is a feature that, if it is indeed successfully negotiating with music labels, Apple will likely have in the next iteration of its software.
While movies will surely follow, music syncing with the cloud is a must-have component of a modern OS.
One only has to look at recent revelations about the way that Google is attempting to exercise more control over customization to see that they’re done living with the reality of a fragmented user experience.
To this end, Google has instituted a partnership with most of the major Android device makers to fix fragmentation issues. The initiative states that new Android devices will be provided with prompt updates to their software for up to 18 months after their introduction, limited only by hardware requirements.
While their syncing options have been limited to MobileMe integration and some basic Google contacts and calendar support, Apple has been very good at presenting a unified experience across the iPhone, iPod touch and iPad lines although it has had it’s own share of fragmentation. iOS 4, for instance, showed up on the iPad 7 months after its release, delaying multitasking for the platform. Through all of that however, the experience for the average user and the developer remained relatively smooth. Apps that supported multitasking ran just fine on the iPad for instance.
That experience has made the Apple ecosystem more attractive to developers who don’t have to worry about quirky UI or framework problems across devices preventing their apps from working properly on the hundreds of Android devices available.
A recent survey suggested that the fragmentation of the Android OS across devices is cited as a meaningful or ‘huge’ problem by 56% of developers. That hasn’t stopped developers from writing apps for the Android platform altogether but you can be sure that it’s a barrier to the entry of established iOS developers or those looking to start development for one of the two major platforms.
With the new Ice Cream Sandwich, or Android 3.1 version of the OS, Google is unifying its Android versioning for the first time across all of their devices with most Honeycomb features like advanced widgets and expanded multitasking coming to phones. This is the first step towards a more cohesive experience for both developers and users alike. It’s a state of being that iOS device users take for granted and one that is long overdue for the Android ecosystem.
If Google’s new initiative is successful in reducing customer confusion and can mitigate some of the frustration that developers are expressing about the state of the OS across mutltiple devices then this should strengthen their position against the relatively stable and uniform iOS experience. Regardless of the efforts of the new initiative however, fragmentation will remain one of Google’s biggest hurdles to creating a unified experience for its users.
As ZDNet’s Peter Cohen points out, it still leaves over 300 older Android devices on wildly different versions of the OS and three years worth of customers that are having vastly different versions of the Android experience.
Expanding commercial options.
The announcements of the Android open accessory API and Android@Home initiatives lent an air of ‘we built this, please find a use for it’ to the proceedings. While Apple introduced their accessory integration API’s in iOS 3.0, there has been relatively little action on that front. It seems like Google feels that this is a position that they’re more suited to thrive in than Apple, stating ‘we want every device in your home’.
The widely varied nature of the hardware that Android currently runs on doesn’t hurt its chances of integrating into a variety of home products, although widespread adoption of Android integration into appliances and home control systems is impossible to predict at this point. What it could do however, if successful, is to create opportunities for developers to create a whole new array of commercial applications for any Android integrated accessories.
While I don’t think that your blender or fridge will be running Android any time soon, it’s clear that Google wants to capture a wide base of integrated devices. This is an arena that, for better or for worse, Apple will never enter. Google sees this as its way to install Android on as many appliances as possible, creating avenues for developers and opportunities to sell their largest product, advertising.
Just don’t be surprised when your toaster pushes out an ad to your phone for wheat bread and peanut butter.
Growth is good, experience is king
Much of Google’s focus in the last several years of Android’s existence has been growth. It’s probably a bit disingenuous to say ‘at all costs’ but that’s how it’s felt at times. If you look at the announcements of Google I/O from the context of Android’s future, it’s clear that Google has realized that it needs to shift the focus from just ‘getting bigger’ to making the experience of using Android more pleasant for future customers, if not current ones. More importantly, it’s looking for ways to make the environment more friendly to incoming developers and those who want to develop for both iOS and Android, but have been turned off by fragmentation and limited commercial potential.
They haven’t solved all of their problems yet, these are just announcements of products and rough products at that. But it does show Google’s awareness of the impending encroachment of the next version of Apple’s software on what has been its core advantages over iOS and that its weakness in user experience and developer relationships needs addressing.