Editorial: In Defence of OEM Skins

The Gingerbread MotoBlur launcher
(No-one does fragmentation like Motorola) 

Android comes in many flavours. From community builds like

CyanogenMod, AOKP, and MIUI, to corporate flavours like Samsung’s Touchwiz, HTC’s Sense and Motorola’s MotoBlur, there’s no shortage of variants – ‘pure’ Android is a rare thing to find in the wild, generally restricted to Nexus devices and low-end handsets. Enthusiasts and power users praise the likes of CyanogenMod for their plethora of customisation options and hands-off approaches, while condemning Touchwiz and Sense et al for much the opposite. This criticism is not restricted to esoteric cliques that trawl XDA-Developers and Rootzwiki, however, as well-respected reviewers from the more mainstream side of tech journalism regularly denounce these manufacturer skins as well.

Curious why anyone would defend the likes of Touchwiz and Sense? Read on, after the jump.

This seems to illustrate a knowledge gap in the mind of Joe Consumer – Android is a confusing-enough playground for those with the interest and patience to research it thoroughly, so imagine for just a minute being confronted by all these variants side-by-side in a retail store. The HTC devices have a big flipping clock, Samsung’s have toggles in the notification window, Motorola’s have a universal messaging inbox, and so on and so forth. While any self-respecting sales rep would be happy to inform Joe Consumer that, yes, these all run Android, and Joe can transfer his contacts from his old, entry-level Android smartphone, the concept of a core mobile operating system with an increasingly-heavy set of manufacturer customisations atop of it is not all that easy to grasp. Suffice it to say that these skins are created with the intention of differentiating devices when compared side-by-side with a competing manufacturer - both to make the sales rep’s job easier, and to offer each manufacturer a chance to construct and control their own brand experience. Indeed, Samsung recently released updates to Android 4.0 for the Galaxy S II and Galaxy Note, yet seemingly did everything in their power to cover up the stock Ice-Cream Sandwich experience. This, I believe, deserves further investigation.

Notification toggles, not in stock Android!
A real value-add from OEMs

The power users and the tech bloggers differ from Joe Consumer by having had in-depth experience with more devices than any average person. Having gone through four phones in the past six months, I can certainly relate to this. Additionally, power users will tend to delve more deeply into the development communities for their devices of choice, while tech bloggers often won’t have the time, or will need to return review units within a certain timeframe – this is important because of the reaction each group has when confronted with a heavily-skinned device should they not like the skin. The former are likely to download and flash a community built Android build that is closer to ‘pure’ Android, whereas the latter are likely to complain that the device doesn’t run ‘stock’ and give it a poor review on the software side, believing every device should be a Galaxy Nexus. Neither of these are bad moves, merely interesting ones, for reasons I will go into in a moment.

The term ‘open source’ is bandied about a lot, but what does this really mean for Android? Well, for those unaware, there’s an Open Handset Alliance than manages the Android Open Source Project, or AOSP, which is the core of the operating system that runs over the Linux kernel. As mentioned above, there are also community-built variants of Android that are similar in function to Linux distributions like Ubuntu or Solaris. A core operating system exists, which anyone – be it a single person or a massive multinational corporate - can download and use on any hardware that supports the software, or construct their own devices to run it on. However, without the nod of approval from Google, they will not be gifted with the Google application suite, or ‘Gapps’, which make the Android experience what it is today – this includes all the Google experience applications such as Gmail, and the all-important access to the Google Play store (Ne Android Market). These Google apps, crucially, are ‘not’ open source. An Android device without Gapps is a poor device indeed, so all major OEMs seek Google’s approval before releasing their devices. As such, Gapps are installed separately from CyanogenMod, as Google are kind enough to provide updated Gapps on a regular basis after a brouhaha a few years back over Cyanogen’s including Gapps directly within CyanogenMod.

We’ll take a moment, now, to jump back a few years to 2010, when Android was technically still a fledgling OS –Android 2.1, or ‘Éclair’, came out in January of that year with the launch of the Nexus One. The Nexus One was the first device to be well publicised for running stock Android, and the latest variant of it at that. It was released for sale to the US public directly by Google itself, and was designed for use with the GSM-based T-Mobile USA network, on which the first Android handset, the G1/HTC Dream, had been released the year before. Sadly, this release of the Nexus One was a dismal failure, and its later, quiet release on AT&T didn’t fare much better. Google needed carriers to shift handsets, and carriers, as it turns out, don’t much care for stock Android. US CDMA carriers Sprint and Verizon announced intentions to carry a CDMA variant of the Nexus One, yet dropped it for the HTC Evo 4G and the HTC Droid Incredible, respectively, both of which ran HTC’s Sense suite overtop of Android 2.1. HTC even released its own Sense-skinned variant of the Nexus One hardware internationally, the HTC Desire. Later that year, Android really took off as a global platform when Samsung released the original Galaxy S, which sported yet another heavy skin.

The stock ICS launcher look (On my S III)

So, back to 2012 - At the time those 2010 handsets were released, the skins added a lot of functionality that would otherwise have been missing, adding real value as well as a more consistent UI design, not to mention that differentiation factor that carriers want. Now we have Ice-Cream Sandwich, the most feature-complete and beautiful flavour of Android yet, nigh-universally praised when the Galaxy Nexus launched in November of 2011. OEM skins, argue fans and industry pundits alike, are no longer required. They delay the rollout of updates to the core OS, they often bog the system down, and they ruin Google’s intentions for the platform’s operation. They have even prevented OS updates entirely, as Samsung, HTC, Motorola, and most recently Sony Ericsson have denied them to devices such as the original Galaxy S, the Desire, the Droid X2, and the Xperia Play, when all of the above have been merrily running community-built updates for some time.

This article was entitled ‘In Defence of OEM Skins’, and I cannot blame you, dear reader, for wondering when I am going to get to any defending. Firstly, I have two words that perfectly encapsulate my feelings and argument, and those words are Windows Phone. You see, Microsoft has gone for a middle ground with Windows Phone, seeking some kind of happy medium between the vertically integrated & tightly controlled ‘walled garden’ of the Apple experience, and the free-for-all hardware & software playground that is the Android device line-up. They have done so by allowing the manufacturers free reign on hardware (Within a set of parameters), and controlling all software themselves. This has resulted in a set of devices with mildly different form factors, effectively the same internals, and all of them do the exact same thing from a software perspective. In short, it’s boring as all hell. The OEMs, with the notable exception of Nokia, certainly do not put their best foot forward. If you’ve tried one Windows Phone, you have tried them all. While that may speak to the success of Microsoft’s software consistency and encourage claims of the first world problems that come with reviewing smartphones, I feel it speaks to something larger, and if you’ve indulged me this far, I’m sure you won’t mind if I elaborate.

HTC's HD2 Sense suite
(As customised by yours truly)

Smartphones are now 90% screen. We touch the screen, we talk into the screen, we stare at the screen for hours at a time. What surrounds that screen, for better or worse, is becoming less important. Nokia have sought to differentiate by making some gorgeous looking hardware with stellar industrial design, but I’m not interested precisely because one Windows Phone may as well be all Windows Phones – I’ve even gone on the record to state that, had HTC included its Windows Mobile Sense suite from the mighty HD2 on its Windows Phone 7 devices, I’d probably be using one of those right now. if I don’t like that core experience, there is exactly zero chance of my liking more because it comes in a different box. Every time I see a reviewer claim that every flagship Android device would be better if it ran vanilla Android – and I do see it every time, at one site or another – I get the feeling that they want these Android-powered super-phones to become Windows Phones, ideologically if not literally. And this is not an extreme I want to see realised. Why? Because I genuinely believe that OEMs can and do add value to their devices on the software level.

This is not to say that I love skins, but is more a testament to the flexibility of Android. As I’ve mentioned before – when talking about Windows Phone, in fact – it is the modularity of the Android experience that keeps me immersed in it. Essentially, if I don’t like any part of my experience with my device, be it the browser, the camera, the messaging app, or most crucially, the home launcher, I can change it, and will (generally) work just as seamlessly as the stock application did, while offering all manner of additional features. I can experience an Android device the way the manufacturer intended it to be experienced, use all the stock apps, use the launcher with the layout it shipped with, use all the default settings – and I have the freedom to disregard that configuration entirely, to throw it all out and to implement my own, comprised of whatever third party application combination tickles my fancy. Apple have a rule that prevents applications with duplicate functionality to stock apps being released on the App Store. Google, on the other hand, encourage it, regularly featuring such apps on the front page of the Play Store. This defines my Android experience.

The gorgeous Sharp SH-06D NERV
Pinnacle of OEM skins, in my eyes..but it runs GB!

But, you may well say, Joe Consumer doesn’t have the time to learn how to do all that. He’s stuck with whatever poor implementation the OEM may have thrown on there at the last minute, and may well never get the update he would so surely benefit from – the dreaded fragmentation issue. Well, I did say I’d defend OEM skinning, but I didn’t say I’d defend its current implementation. Rather, I
support the idea behind it, that of software differentiation, and I certainly appreciate some implementations over others. Simply put, I feel that hardware manufacturers have a lot to offer on the software side. Be it design elements like wallpaper and system UI sounds, or innovative lockscreens, great widgets, beautiful icons, handy drop-down notification toggles, and excellent launchers, I sincerely believe Android would be a poorer ecosystem were it not for those enhancements. Few can argue that some of these implementations are superior to vanilla Android, especially the likes of HTC and Samsung’s camera applications.  There is also a lot of redundancy, superfluous, poor design, difference entirely for difference’s sake, and places where the stock implementation would have been a lot better. To this end, I submit a list of five proposed requirements for Android OEM skins that, I feel, many would agree would add value while retaining the differentiation element and allowing the skilled individuals that reside within their respective corporate bodies to flex their design muscle.

1.      Add a kill switch. Include the stock Android launcher, whatever iteration that may be, and the stock keyboard. These are key. Everything else is in-and-out, but these are two of the most often poorly duplicated elements of the Android device experience. While there are plenty of alternatives on the Play Store to whatever implementation OEMs have gone for, again, those aren’t really for Joe Consumer. Give everyone the option to try the vanilla flavour for themselves, and switch back to the OEM experience if they don’t like it. Don’t be afraid to be different, but leave a back door.

2.      Do not change something if you aren’t improving it. If the stock Google calendar is better than yours, don’t include your own. Add value, don’t detract from it. And if you do choose to add your own version that isn’t significantly better, at least leave the framework intact enough for power users to side-load the vanilla experience. Bloatware also falls under this category, although – thanks to Ice-Cream Sandwich bringing the ability to disable applications – that has become less of an issue than it was in years past.

3.      Support open development. This I cannot stretch enough. Unlock bootloaders through an official channel, release public beta builds, release your drivers, speak to the community that loves your hardware and they will stick with you over and above other OEMs. There is zero excuse for locking hardware down at this point, security concerns are null and void, and if consumers don’t like an OEM’s Android experience – and don’t have the ability to change this themselves – they will move to another manufacturer. Plain & simple.

4.      Make your devices’ software interoperable. One of the greatest wins for consumers in the Android space occurs when one device’s killer features are ported to another device. Given the goal of OEMs is to hook consumers into ‘their’ Android experience, why not allow those users the ability to hot-swap elements of that brand experience when they upgrade? What if they jump from the Galaxy S II to the Galaxy S III, but miss their old launcher, or their old text messaging app? Where possible, why not allow for the transplant of core apps from one device to another? Would that not further encourage the upgrade to stick with the same brand? Sony are probably the best at doing this, albeit unofficially, as a number of their applications are cross-compatible. Here’s another thought – even Apple haven’t mastered the ability to transfer settings and home screen layouts from device to device just yet, why not make an upgrade assistant that does just that?

5.      Don’t customise to the point where it severely interferes with the ability to upgrade the core OS unless there’s a really good reason for doing so. Really good reasons are generally hardware-related, things like the Galaxy Note’s S-Pen. There isn’t much else that washes, there, yet so many skins and apps are baked right into the framework. If a device is so heavily skinned and with so many applications replaced that an upgrade will take forever to code and test, you’ve done it wrong. Android is modular, so too should OEM skins be. The above-mentioned kill switch could combine with interoperability and allow for the independent updating of OEM apps and skins directly via the Play Store, just as Google provide updates to G-Apps – it could add value, reduce the complexity of porting new Android flavours, and allow for faster updates and bugfixes, just like third party launchers do.

The Galaxy S III Lockscreen

Again, I believe there is real value and innovation that can be contributed by software engineers working at major Android device manufacturers, and I enjoy trying, say, an Xperia launcher on my Motorola device.  There are genuinely useful features to be added and real visual design to be appreciated. Carriers don’t care for a shelf full of phones that all look the same and do exactly the

same things, and I too don’t feel that every device needs to be a Nexus. As above, I do feel there’s an easily defined line, yet it shouldn’t be too hard to keep to that boundary. As long as there are regular updates (or the OEM is open enough that the community can provide those updates to the people that care), as long as it’s non-intrusive and serves to differentiate rather than cripple, why should OEM customisations be a bad thing?

To wrap things up, I’d like to provide a few choice examples of OEM-customised launchers that are, I feel, worth your time. If nothing else, it’s fascinating to compare the different manufacturers’ approaches – it’s the closest to actually using those devices one can get without shelling out for the hardware.

 - The LG UI 3.0 Launcher (ICS+)

 - The Sony Xperia S Launcher (GB+)

 - Two different ICS MotoBlur launchers (ICS+)

 - The Galaxy S III's Nature UX launcher (ICS+)

 - Dell's Stage UI from the Streak (2.2+)

 - Touchwiz 4.5 (Modification of the Galaxy S II's launcher) (2.2+)