The rise and fall of NewBlue, Google's attempt to 'fix' Bluetooth on Chrome OS

Google tried to rebuild Bluetooth from the ground up for Chrome OS—it didn't work out

It is a well-known fact that Google has a rough history with Bluetooth. While the Bluetooth situation on Chromebooks is improving thanks to recent development, many of us who pair Bluetooth peripherals to our Chromebooks like wireless earbuds or mice will know that the wireless experience isn’t perfect. In 2018, with Bluetooth devices on the rise and the launch of the Pixel Slate looming, Google likely felt pressured to tackle this problem. This led to an experiment with a brand new Bluetooth daemon, in an ambitious project known as NewBlue.

After more than two years of development, NewBlue was enabled by default on all Chromebooks, starting at Chrome OS version 80. The Chromium developers had hoped this would resolve the Bluetooth issues on Google's browser-based OS; but in the end, NewBlue didn’t last long.

By late 2019, Google removed NewBlue from its repositories and started scrubbing all traces of its code out of chromium. At the time of writing, the last NewBlue commit merged was in April 2020, removing yet more code related to NewBlue.

As a Chromebook user with consistent issues while using my Pixel Slate’s Bluetooth, I thought this backpedaling was weird as hell. I was so curious that I felt the need to dig in deeper. What I’ve discovered has prompted this write-up. Note that the information about NewBlue may not paint a complete picture, since internal documents regarding the project are not publicly available.

Possible motivations for NewBlue Removal

Bluetooth is an extremely complicated radio technology. Its specifications are massive; a single piece of documentation that explains how two devices can make a handshake is over 3,000 pages long. Add in the details that makes the device work, and you’re asking the software to conform to a document that has close to 5,000 pages! Furthermore, developing a Bluetooth stack is extremely difficult, especially with the inconsistent firmware capabilities of most Bluetooth chipsets, as well as multiple different Bluetooth profiles that exist. Generally speaking, a flaky Bluetooth connection is caused by bad firmware or bad hardware (or a combination of both).

Before NewBlue, Chrome OS was using BlueZ. Those of you who don’t know about BlueZ: it is the official Bluetooth stack for Linux. It’s licensed under the GPL and supports all core Bluetooth protocols and layers. Although BlueZ has been around for a while (starting with Linux 2.4.6), some developers expressed their dissatisfaction for the stack. Bjt2n3904 from Hacker News wrote that “the Linux side of BlueZ is abysmal. Honestly, I don't even know how anyone does anything with Bluetooth on Linux besides a mouse and keyboard. And barely even that." This person is not wrong.

As I wrote before, getting Bluetooth to work well requires good firmware design and good hardware, which most Chromebooks lack due to their affordability. Add in several different kinds of Bluetooth implementations, factor in the multiple different Bluetooth profiles, and the complications with backwards compatibility, and the whole situation gets ugly fast.

NewBlue wasn't even the first time Google tried to drop BlueZ. In 2012, Google switched Android’s Bluetooth stack from BlueZ to BlueDroid. No one really knows why—some speculated it was because of BlueZ's GPL license, which requires developers to release the software’s full source code and all rights to modify it. When Google worked with Broadcom to develop BlueDroid, it was licensed under Apache, meaning they were not forced to release the source code. That may well be a motivation behind NewBlue for Chrome OS—as it is licensed under BSD—but I personally don’t think that’s the reason. I think Google created NewBlue because of an influx of complaints regarding Bluetooth on Chromebooks.

The NewBlue experiment

The first evidence I found of NewBlue dates to February 16, 2018. In this chromium bug report, an Intel engineer asked Google why BlueZ was being dropped, to which they responded that they “wanted to move their Bluetooth stack into userland for many, many reasons.” A design doc was created to explain the motivations behind NewBlue, but unfortunately it was never publicly released. Development of NewBlue was kept under wraps until XDA-Developers noticed the NewBlue flag in the Chrome OS Canary channel in May 2018. NewBlue was unreliable and refused to connect to any Bluetooth devices at first, until Robby from ChromeUnboxed managed to get it running. In the article, he praises NewBlue and says that “this Bluetooth setup is how it always should have been. No dropped connections, no laggy pointers, no issues.” I believe the ChromeUnboxed article was the catalyst for the NewBlue hype as several other websites and redditors started reporting on it, claiming that it cured their various Bluetooth woes. For the moment, it looked like NewBlue might finally fix Bluetooth on Chrome OS.

Fast forward to 2019, and the r/ChromeOS subreddit was still littered with complaints about frequent drop-outs with their Bluetooth earbuds and mice. Although NewBlue wasn't enabled by default in 2019, those who tried it frequently found it didn’t fix anything—it actually seemed to make things worse. Google’s smart lock stopped working, it caused wireless instability, and it even broke Bluetooth completely on some devices! All of these bugs persisted when NewBlue was turned on by default in Chrome OS 80.

Google must have gotten tired of all of the Bluetooth bug reports, because right after Chrome OS 80 was released, the developers pulled the plug on NewBlue, and started to remove any references to it from their repositories. They spent the next several months reverting back to BlueZ and removing traces of NewBlue, bringing us to where we are today. Two and a half years of development has effectively gone down the drain. But I believe this may actually be a good thing.

Why reverting back to BlueZ is a good idea

Although BlueZ has its fair share of problems, support can be found on all Linux systems on the market, including Debian, Ubuntu, and Fedora. Unlike NewBlue, BlueZ has been around for quite a long time and was built into Linux starting with version 2.4.6, which was released in 2005. The foundation is already there. I think Google realized they should not have spent their resources reinventing a new Bluetooth stack. By Google fixing the Bluetooth experience on Chrome OS with BlueZ, it’ll also benefit the larger Linux community.

Since the switch to BlueZ, Chrome OS has received several updates that significantly improved the Bluetooth experience, such as shrinking the AD2P packet size to a smaller default value to improve audio quality and address audio stutter. I can’t say for sure if any of the recent improvements will finally resolve the Bluetooth situation with Chrome OS, but hopefully it’ll noticeably improve the experience. If anything, at least Google is doing something about Bluetooth now.

Has the Bluetooth experience improved on your Chromebook recently? Feel free to write a comment below.

Source: My old post on Reddit