Android OEM customizations like Samsung TouchWiz and HTC Sense are undoubtedly a love-it-or-hate-it affair. There are certainly users out there who care for the added features that these skins introduce. But on the other side of the coin, there are more than a fair share of users who despise the aesthetic nightmares found in some skins. What’s more, this extensive customization often (but not always) results in Android firmware update delays—and that’s if the bloated firmware doesn’t prevent updates in the first place. Oh, and let’s not forget about how these customizations result in a greater number of security vulnerabilities.
Android’s Early Beginnings
OEM customizations certainly had their place in the early beginnings of Android, when its stock UI was clunky and supremely unpolished, and when these custom interfaces added legitimately useful features. However, Android has evolved quite a bit, and ever since Ice Cream Sandwich (or arguably even Honeycomb), has also offered a fantastic and intuitive UI that certainly had its own flair. But as we all know, this flair was for all intents and purposes lost in the excessive OEM and carrier customizations. After all, does a Samsung Galaxy S 5 phone look and feel more similar to another phone running KitKat like the HTC One M8, or does its UI remind you more of an ancient TouchWiz-laden device like the original Galaxy S?
Increased Platform Unity
As we noted in our I/O 2014 coverage, Google has been trying to bring some unity into Android ever since Sundar Pichai took over the platform. And now with Android Wear, Android TV, and Android Auto, they’re taking the first big step by requiring manufacturers to deliver a relatively untarnished user experience.
In an interview with Ars Technica, Google engineering director David Burke confirmed that all of Android’s new initiatives will feature user interfaces and underlying software that is controlled by Google, and not by the OEMs. This is because on these products, “the UI is more part of the product in this case.” And as one would expect given Pichai’s new role, the end goal is to make Android updates “more like Chrome on the desktop.” There will be a few differences in OEM implementations with regards to built-in features and pre-installed apps, as described by Google, but for the most part, these implementations will be nearly identical to the end user, and reinforce Android’s new image.
There are now undoubtedly several questions from both a developer and end user perspective. First off, how exactly does Google plan on enforcing this? Would this be accomplished by limiting Google Play access to certified implementations? This is already done in limited capacity with new Android devices to ensure that they pass the Android Compatibility Test Suite. But still, what’s to prevent an OEM from building an Android Wear device, which doesn’t require direct access to the Play Store in the first place, and making it hook into the appropriate APIs? This then brings us back to a question we posed several months back when Android Wear was first unveiled: Just how open will Android Wear actually be?
The unfortunate truth is that we don’t know yet if Android Wear itself (or how much of it) will be open source, or how this unified UI will be enforced. Perhaps only the shared AOSP codebase will be open, with the rest being proprietary and used as a means of enforcing platform unity. This is both a good and bad thing–for both developers and end users. However, it’s easy to imagine how this move, alongside the emergence of all of the recent closed-source Google apps, can hurt Android’s openness.
What are your thoughts on all of this? Are you a fan of Google trying to preserve Android’s identity at seemingly all costs, or would you rather have a more open ecosystem, where developers and manufacturers are free to use (and abuse) Android’s openness to differentiate their products? Be sure to sound off in the comments below!
Want something on the XDA Portal? Send us a tip! -- Join us for xda:devcon 2014!