Google’s changes to the Android Beta Program have created a huge mess

This week, Google released a new beta update for Pixel Phones, publicly testing Android 12 QPR3, or the third Quarterly Platform Update for Android 12. The first two Android 12 QPRs were released in December and March as Feature Drops, with the latter getting a public test as well. But Google has switched up how things work in a way that’s confusing – particularly, as Android 13’s public testing starts to build. Complicating that is the fact that the official, stable Pixel 6 March update has been held back while its changes and much-needed fixes are simultaneously available in the new beta. That’s caused plenty of customers to jump onto the beta release, and some who did not want it were pushed onto it by failing to opt-out of the program before flashing Android 13 DP1, causing yet other issues. And when it comes to the right labels to describe all these changes, even Google itself could not keep track of the correct terms to use.


Amid an uncertain future, the current Android Beta Program feels like a hot mess, and only better messaging and organization from Google can fix it.

Complicated names, complicated history

To start, there’s the simple confusion over the names used by the Android Beta Program – confusion that Google actually added to by using the wrong language itself (which I’ll talk about more later). My friend Mishaal Rahman did a perfect job breaking down the important terminology recently on Twitter when it comes to these new betas for quarterly releases. The abridged version is that Pixel Feature Drops are based on QPRs, or Quarterly Platform Release updates, that happen (you guessed it) every three months. The Feature Drops have extra stuff on top of that, too, like updates to Google’s apps and Play Services, all branded and bundled together for a simultaneous announcement.

There’s some historical nuance to consider when it comes to the Android Beta Program itself. Long ago, some of these Quarterly Platform Release updates received X.1 point updates and API changes. Google stopped that practice after Android 8.1. Rahman theorizes (and I strongly agree) that OEMs pushed back because they could not keep up with more frequent updates. These point releases also had public beta testing, though that was partly before the Android Beta Program existed and Google called all of its tests Developer Previews (that change happened with Android 7 Nougat).

More recently, the Android Beta Program has only been used for major Android releases. While Android 12L stands out as new to the modern eye, it’s actually a return to Google’s roots, in a sense. Although Android 12L was not going to be a very impactful update outside foldables and tablets, it did introduce API changes, so it made sense that Google would extend the Android Beta Program out of its usual release cycle so developers could test it. But Android 12L was also effectively one of those Quarterly Platform Releases, and after it landed in stable, Google has now continued the program into this next QPR release, even without any new API changes. While testing Android 12L (effectively Android 12.1) in the Beta Program was a return to tradition, this – releasing a beta of an upcoming QPR – is entirely new territory.

In just two steps, Google went from only testing major releases in its Android Beta Program to testing every quarterly update that the Feature Drops were based on. This change did not happen entirely silently – in hindsight, Google was actually upfront in a Reddit announcement in late 2021 that the Android Beta Program would continue into Android 12 itself (and it even specifically called out Feature Drops) – but communication still was not clear, particularly because, as we now know, Android 12L would have been an exception either way by introducing API changes. I think many of us blindly assumed that the program’s extension would “end” after 12L was released and start again with Android 13’s betas, expected in April. But that did not happen, and now we’re not entirely sure what’s going to happen with Android 13’s imminent public beta testing.

It’s a confusing situation further complicated by the fact that some people (like me) are switching to the beta releases not just for an early glimpse or to test unstable features but to counterintuitively fix issues.


QPR3 Beta 1 is buggy, but before it my Pixel 6 Pro 6 was unusable.

Google’s Pixel 6 update situation has been a frustrating experience given both the volume and severity of issues with the phones. My Pixel 6 Pro was not even able to connect to Wi-Fi reliably for over a month. Google itself noted that these betas include fixes for issues like this even if it has not rolled out a stable update yet (for whatever reason), and some people took this opportunity to jump into the new Android betas just to get their phones working again . Now, unless they want to wipe their phones, they’re locked into this beta track until the next window opens to leave it – windows that Google does not effectively communicate outside posts to Reddit. When the program only ran on an annual cadence, Google sometimes made that opt-out process entirely automatic after major versions were released, though it was still wise to double-check. But as the Android Beta Program expands into seemingly continuous testing, this is going to complicate things.

That’s not the only way that Google has failed to communicate what’s happening, though. Remember that subtle difference between Quarterly Platform Releases and Feature Drop updates? The QPR release notes page confused the two, at first – Google itself could not keep track of what was happening. On top of that, for a “beta” that ostensibly is asking for feedback from customers, Google has not listed a single change for the new QPR3 Beta 1 release. If you can not even tell beta testers what they should be testing, how can they provide valuable feedback?

What Google’s got here is a failure to communicate

Google has started reactively changing some of its messaging, like altering the “Feature Drop” language from the release notes page. But this is one tiny change in response to a situation so confusing even Google could not keep track, and it still does not fix its messaging in other ways. When you get down to it, Google has to be proactive here, not reactive – all of this should have been easily foreseen.

I’ve reached out to Google with questions regarding all of these issues, and the company has not yet responded to my inquiries. Admittedly, none of this has a general impact outside the Android Beta Program. The vast majority of customers run stable releases. For them, not a single thing has changed (except for the Pixel 6’s frustrating update delays and a few that might jump into the betas to get them early). But this does impact a lot of the more influential Android opinion-makers, from developers to enthusiasts, and their frustration has the potential to be seen by more mainstream Android users. Furthermore, if even Google’s enthusiast audience is confused – and these are people all too used to wading through minute and nuanced differences – that should be enough of a reason for Google to pay attention.

In my opinion, Google needs to press pause here before the Android 13 betas land as expected sometime in April and get its messaging straight, increasing communication with customers and laying out a plan for how the changes to the Android Beta Program will fit in with upcoming major and minor releases. A nice Android Developers Blog post on the subject from the Android team detailing how major and minor Android releases will be tested going forward would help, as would some changes to the program itself. I think the major Android version release test program and these QPR tests should have separate, mutually exclusive programs with separate registration and program names to reduce confusion – let the QPR testing keep the more general Android Beta Program name and give the major Android release testing a new one that makes it more clear that it’s targeting developers looking to test API changes.

I also think that Google should make it a little easier to migrate to and from the Android Beta Program by notifying customers running beta and Developer Preview releases directly (with on-device notifications) when the window to opt-out without wiping a phone opens and closes. That way, they aren’t stuck with bootlooping phones, as happened with the recent Android 12 QPR3 update when Google served it to those that did not opt ​​out of the Android Beta Program before installing Android 13 DP1.

While parts of these changes to the Android Beta Program happened slowly in hindsight, the situation right now remains confusing, and Google would be wise to address it before Android 13 makes things even more complicated. It already has enough other update issues to worry about with the ongoing Pixel 6 snafu.

Samsung Galaxy S22 update removes performance throttling in apps and games

Available in South Korea only to start

Read Next

About The Author

Leave a Reply

Your email address will not be published.