Home > Software > Android Development > Pixels don’t run ‘stock Android’ and Google needs to give its software skin a public name – Android Police

Pixels don’t run ‘stock Android’ and Google needs to give its software skin a public name – Android Police

There was a time when Google’s phones actually ran “stock Android.” The company’s Nexus phones (which were released between 2010 and 2015 and preceded Google’s Pixel line) were specifically made as development devices, followed documented behaviors, and ran software that was very close to the barebones AOSP experience — the version of Android developed by Google that all other skins and companies build on top of.

But the Pixels have shaken up that formula, accruing exclusive features over the years that other phones won’t get. In fact, “stock Android” is a misnomer the way it’s used now. No matter your definition, though, the recent Pixel 6 and 6 Pro aren’t running it, and it’s probably time Google gave the Pixel’s software skin a formal name.

To start, let’s lay down some definitions we can agree on. “Stock Android,” as most of our readers probably think of it, isn’t a real thing. Unless you’re an enthusiast running a GSI (generic system image) on your phone, you have an Android One-based phone from a company like Nokia, or you’ve specifically flashed a custom ROM that aims to be as close as possible to AOSP, then you probably aren’t running “stock Android.” The term as it’s been used for the last decade originated as an imprecise way of describing a version of Android that followed the way Google designed Android to be, popularized by fans of the Nexus phones running software that hewed closely to AOSP.

“Stock Android,” as most of our readers probably think of it, isn’t a real thing.

During an era when every smartphone maker was convinced its crappy, poorly designed interface was somehow an advantage, Google’s own design was championed as a better alternative — which it was, though it wasn’t perfect. People and sites (including ours) would imprecisely compare things like Samsung’s godawful TouchWiz to “stock Android” when describing poorly thought out UI dumpster fires, and the term falsely grew to represent Google’s interface over time. The problem there is that Google’s interface isn’t “stock” anymore.

Part of that disconnect stems from the Nexus heritage and light touch Google initially took with the Pixel’s software changes, which made it easy to equate the two, even as things began to change. When sites like ours track features during the Android developer previews and beta programs, we’re actually tracking features that appear on Pixel devices. In many cases (especially before Android 12), these were “stock” features that will be part of AOSP, but sometimes they weren’t, and that reality has accelerated under Android 12.

Mishaal Rahman (senior technical editor at Esper.io and former editor-in-chief of XDA-Developers) coordinated with Henrique Silva (developer of the Pixel Experience ROM), Luca Stefani (Lineage OS director, Calyx Institute member), and Kieron Quinn (Tap Tap developer) to provide us with a few extra details:

“Now Playing, Quick Tap, and the new Gaming Dashboard deviate the most from AOSP. Now Playing dates to the Pixel 2, but Quick Tap and Gaming Dashboard are both new to Android 12 on Pixel. Quick Tap uses a proprietary nanoapp that runs off the CHRE (Context Hub). Gaming Dashboard is a simple feature on the surface, but there’s no genericized implementation of it in AOSP.”

In short, outside of performing a detailed teardown looking for the logic behind each and every feature or hoping Google spells things out in the documentation, we can’t always be sure which new Android features spotted during testing will become Pixel-exclusive features. And, though this is an issue that came to a head more with Android 12, Rahman tells me that Google really started to diverge from AOSP and introduce exclusive features beginning with the Pixel 2, even changing the UI in notable ways:

“I think the Pixel 2 is where we started to see Google features really deviate from AOSP. The Pixel 2 introduced Now Playing and Active Edge, for example, both of which extended SystemUI with proprietary Google solutions. I don’t think Now Playing’s low-power, on-device music recognizer or on-device music database are available to the public. Likewise, the proprietary tech behind Active Edge was inherited from Google’s acquisition of HTC’s smartphone design division.

Prior to the Pixel 2, most proprietary Google tech was contained to updatable apps rather than core system apps (Google Assistant [part of the Google App] debuted on the Pixel 1, Google Camera, etc.) Pixel 2 is where SystemUIGoogle really started to deviate from AOSP SystemUI in significant ways, with little bits of features moving to a private part of the package (under the com.google namespace).

Though they’re probably closer than any other phone to it, Pixels don’t run “stock Android” even from a user-facing perspective, and Google is making changes and adding features to its own software skin that other companies won’t get, whether they want them or not. For customers, “stock Android” basically means Google’s UI, but that’s not something you can fully get outside Pixels now. But for developers, “stock Android” means something a little different: predictability.

Last year we reported on some of the trouble developers face trying to make sure their apps played nice on different Android skins. As with pointless UI changes, every company is convinced it has the secret sauce to saving battery life by changing the way Android works — almost universally these changes are bad, dumb, and break things, resulting in issues from delayed notifications to apps just straight-up dying in the background. When pressure mounted on Google to start imposing requirements that might improve the situation, the company refused to.

Speaking to DontKillMyApp developer Petr Nalevka, who is an expert when it comes to Android behaviors for developers, Pixels are “the closest to AOSP you can get without building your own Android [version] from sources,” though even he admits there might be a similar bias to Android feature-spotting: “Pixels are really the first devices we develop for and test everything on, before we move on to other devices, so we may miss something just because of that.” Rahman tells us that Pixels essentially follow AOSP behaviors precisely outside bugs and that “no developer-facing behaviors have ever been altered by Google.”

But, in a wider sense, “stock Android” by its cumulative customer-and-developer definition hasn’t really been a thing in a long time — with one exception. Even OnePlus’s OxygenOS, paraded as an unmolested and well-designed version of Android (until the recent ColorOS merger), wasn’t “stock Android,” as any app developer that has had to fix OnePlus-specific issues can tell you. While some Android skins stick with an AOSP-like apperance, there really aren’t any phones from big companies running “stock Android” anymore, outside Android One.

If you’re unfamiliar, Android One phones stick with an AOSP interface, a minimum of software changes to accomodate things like hardware, and a guaranteed update window. According to Rahman, Google has to approve hardware and software changes, down to things as specific as the default home screen layout and a maximum of five pre-loaded apps, all of which must be updated through the Play Store and approved by Google. Even when it comes to the interface, “the UX must comply with Material design, not feature a skin or custom user interface, and must use the Android One boot screen and animation, etc.”

Ryne Hager (2835 Articles Published)

Ostensibly a senior editor, in reality just some verbose dude who digs on tech, loves Android, and hates anticompetitive practices. His only regret is that he didn’t buy a Nokia N9 in 2012. Email tips or corrections to ryne at androidpolice dot com.

More From Ryne Hager