The interwebz are alight. Debate and argument is intense, following the launch of the HTC One and Samsung Galaxy S4, Google Play editions. The Google Play edition moniker, for those (such as I) who choose to reside under a rock, refers to the fact these devices come minus the manufacturer skins and modifications users are accustomed to, and instead ship with the “stock” Google experience, most commonly seen from AOSP or Nexus devices. A fair idea, it appears, although the launch has been met with controversy and debate over if these new handsets are a let-down. Why? Let’s take a look:
The final point I’ll cover is a long point. This does’t intend to cover every possible angle of argument over the Google Editions, rather give a flavor of what’s going on. I believe that to sum up the anger and defense being seen from different people, we need to look at a bit of history. The first “Google” phone was the T-Mobile/HTC G1, which brought Android to the market for the first time as part of the Open Handset Alliance. This device ran pure, stock, out-the-box, Android. And boy was such early “pure Android” ugly.
The next “Google” device was the Nexus One. At this time, the Nexus devices seemed to be more developer-oriented devices, used to give developers a reference device to work on the platform, and the latest version of Android. And herein lies the problem: Google has put their name to the “Nexus” range of devices.
I believe the problem is confusion. There are too many similar schemes on the go, with similarly confusing names. I have bolded these names to draw attention to the issue and confusion. First, there’s AOSP, the Android Open Source Project. If you build AOSP for a device, you’ll get a vanilla, plain experience on your device. It’s also entirely open source. Many of the device’s features won’t work without “proprietary binaries,” which are added into AOSP as binaries (e.g. graphics drivers etc). ROMs such as CyanogenMod, AOKP and ParanoidAndroid are generally derived from AOSP, and the sources for these are available to download and modify freely. If a device is supported by AOSP, it’s possible for the user to compile the ROM entirely, and thus ensure their device receives updates to the latest versions of Android (barring compatibility issues with the proprietary blobs, which may need updates for major revisions)
Next up is the Nexus range of devices. As mentioned previously, the Nexus moniker is for the range of (usually) Google-sold devices, which have easily unlocked bootloaders, and ship with vanilla Android, and prompt updates for 2 or 3 revisions of Android. There is an often overlooked distinction between Nexus devices and AOSP. The former has Google proprietary applications installed, and the fact a Nexus device is released does not necessarily mean it is available in AOSP. This was shown by Google when JBQ announced the Nexus 4 and Nexus 7 (LTE) wouldn’t be part of AOSP (at the time).
Now let’s introduce Google Play Editions. These phones are sold via the Google Play Store (like the Nexus devices currently are), but will have software updates delivered by the OEMs, rather than Google. They also feature modifications to the pure Android experience (e.g. the HTC One has a toggle for Beats Audio, and Sense frameworks in the ROM). To back this statement, the repacked Google Play Edition HTC One ROM weighs in at a whopping 432.29 MB. In contrast, an AOSP build with Google Apps weighs in at around 250 MB, even on an XXHDPI device. Clearly, these devices are not running the same software.
Still with us? I’d honestly be surprised if anyone is still able to make sense of this. I believe the issue here is to do with branding. There are too many terms being used to describe devices that have the “Vanilla Android” experience. Personally, I won’t be buying any of these devices, because I want proper AOSP support for my phones and tablets. Ironically enough, I don’t even run a “stock” ROM on my Nexus 10. Instead, I choose to use a compiled AOSP ROM with some changes. Ironically enough, the only two devices I use the way they came out of the box are Sony devices. Yes, Sony, the company that actively contributes towards efforts to make their devices compatible with AOSP.
Perhaps, just perhaps, I’ve found something here. The OEM with the most “usable” default software is also the OEM who makes it easiest for me to change to AOSP if I don’t like it, giving them a motivation to get their software right. Perhaps these Google Play Experience devices will help, and show OEMs that customers want more choice and the ability to run unmodified software. My biggest concern is that of the updates. Users are still reliant on their OEM for the kernel that Google includes in the updates, and there’s no suggestion any of these devices will find their way into AOSP. As such, I find it impossible to recommend a Play Edition device, at least until things are clearer. OEMs, unless you are Sony, give up on making software, and sell your devices based on the hardware. Put the device into AOSP, and stop worrying about software, let people who understand it deal with it.
Google could sort out this nonsense, and start being more bullish with their suppliers: “Want your chip in our latest phone, which will sell millions of units worldwide? Sure, once you open-source the drivers and agree to put them into AOSP. Not so keen? We’ll just give the contract to your rival then, no loss to us. What’s that? You’re reconsidering. How nice, but since you seem hesitant, we want the chip firmware in AOSP as well”.
The mobile market is frankly absurdly backward and defensive of their source code—almost as much as the graphics chip market. Dear Qualcomm, Samsung, and every other mobile chip maker: GROW UP. Make your code open source. Your rivals aren’t going to copy it or benefit from it because you are all working on the “next generation” right now. And if they do, imitation is the sincerest form of flattery, right?_________