Android Product Strategy
Google’s Android strategy has been particularly nebulous. Android handset manufactures have been slow to adopt Android updates. Though many manufacturers promised on previous I/O stages to update devices on a well-defined schedule as part of the Handset Alliance, their motivation and commitment both faded after collecting upfront revenue form handset sales. This has fragmented the ecosystem and prohibited developers from adopting new OS features. Google has cleverly begun sidestepping this issue by packaging new features not in Android, but in the Google Play app. This seems to be a trend of turning Android into an OS “Core” while many shell and API features could be provided by Google Play instead. Though this means developers get access to new features sooner, it feels like a departure from the Android philosophy. Rather than demonstrating the definition of “open”, Android is being bifurcated into an open source core and a closed-source experience. If this sounds familiar, it’s the same strategy Apple uses to separate OS X from its open Darwin foundation. Just as Darwin is unattractive without the full OS X experience, what will future versions of Android offer without Play?
As the benefits conferred by the Play app increase, Google has more power to wield against handset manufacturers and telco operators. An Android phone simply won’t be “Android” without the Play Store app that only blessed devices provide. It is further interesting that the only way to receive features such as matchmaking and push notifications is to include an app which provides Google with a monetization channel. Google is helping developers by providing SDK updates that are easily pushed down-level, but they seem to be accomplishing this with means that feel un-Google.
Regardless of the means, the new features being added to Android are exciting. Android’s API for matchmaking and achievement management looks clean and straightforward by Android standards. I was also extremely impressed with Google that they have released this SDK for iOS as well. I cringed, however, when the speaker reached the point in his talk where these services all relied on Google+ login. Despite Larry Page’s criticism of other companies who placed economic gain before technological innovation, Google seems determined to parlay Android success on Google+. Rather than supporting an open identity model where users are free to pick their favorite provider, Google has inserted Google+ as a dependency in so many places that Android will stagnate if Google+ fails. As a supporter of the Android ideals, I hope they find a way to continue to thrive. Perhaps the keynote focus on Google+ intended to convince us that the parlay is a safe bet.
As predicted, the keynote contained a series of evolutions, but no revolutions. There were a number of great announcements; it may sound bitter, but I can’t wait to replace Eclipse with Android Studio. The redesigns of Google+ and Google Maps gave me hope that designers are finally earning their well-deserved respect and authority within Google and the improvements to Google+ image processing and Google Search assure me that Google is utilizing more of the incredible brainpower it employs. Though these were great launches, they appear to be consumer-facing products only. I am unsure how the Google+ image processing features affect any of the developer-focused audience.
Truthfully, it can be hard to keep a continued fervor for the three hours we were scheduled, and it seems like Google used the gathered audience to instead deliver product announcements to the press. I would be amiss if I didn’t emphasize that I am happy for what is being released; I am particularly curious about the GCM and gaming updates to Android. Still, I struggle to digest how I feel about the movement Google has started.
This combination of brilliant engineering and product directions that feel off has been the theme of my first day. Some talks inspire me to tirelessly incorporate better technology into Parse. Other speakers seem to believe that the world would be such a better place if we only knew REST existed and want to sell us a factory factory singleton API to abstractly access a member of a JSON payload (not kidding).
Attending I/O is like watching a sitcom about a nerdy stereotype. I want Google to succeed so badly, but I uncomfortably cringe each time they stumble and a piece in their constellation of products suffers from poor design, market fit, or muddies the overall picture by overlapping older and better Google products.