If Cyanogen Inc. has its way, you won’t be forced into the Google services if you use Android. Until then, a lot of us are fully invested into the Google ecosystem. We listen to our music on Google Play Music. However, the Google Play Music app could benefit from some tweaks. In this episode of XDA Xposed Tuesday, XDA TV Producer TK reviews an Xposed Module that adds some customization options into Google Play Music. XDA Senior Member Maxr1998 offers...
Google Editions: Lackluster or Leading Edge?
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:
- These Google Edition phones are only available for “cash upfront,” unlike the regular variants of the devices, which are sold in such a manner, but also on contracts via carriers. I believe it’s unlikely carriers would be interested in these devices on their network, as part of the Google Edition means there’s no carrier customization or modification made to the devices.
- Expert users won’t pay more for a device running a different firmware. They’ll just install it on their regular phone. This is definitely the case for XDA users and developers, and it seems likely to me that many people would rather there was no product launch of these devices, rather simply the OEMs had released a “parallel stream” of Google Experience software they could opt to install. Perhaps that’s the end-goal of this project? Who knows?
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?
Want something on the XDA Portal? Send us a tip!
Google introduced a revamped Recents interface with Lollipop in the hopes of making it easier for users to jump between tasks. But is Recents the best method of switching tasks? Let us know if you actually use the Recents button as a task switcher and why.
Many of you probably dual-boot your personal computers, be it to run Linux alongside Windows or because you have a Mac and hate OS X. On a computer platform, the process can be a life-saver for a variety of reasons, particularly software compatibility/integration. It’s not rare to see computer programmers with Linux partitions or Mac gamers that use bootcamp for their videogames. On computers, the process has gotten relatively simpler over time, with Microsoft and Apple typically supporting the notion....