Back to News
Foundations

Android’s Bluetooth stack, Fluoride, comes to ChromeOS

With ChromeOS 122, ChromeOS began replacing its current Bluetooth software implementation with Fluoride, the Android Bluetooth stack. This migration, named Project Floss, started in early 2021. It has taken nearly two and a half years to achieve quality parity with Bluez, ChromeOS’s previous Bluetooth stack, for the most frequent ChromeOS use cases. Let’s take a look at why we decided to migrate—and the benefits to the Bluetooth landscape we hoped to achieve.

Managing the Bluetooth ecosystem

The Bluetooth ecosystem is a large, diverse, and exponentially growing collection of devices, expanding by over 27 billion devices in the last four years [1]. Specifically relevant in the context of ChromeOS, there are nearly six billion audio devices and four billion Human Interface Devices such as mice, keyboards, and game controllers. These two categories make up the vast majority of Bluetooth peripherals connected to ChromeOS devices.

ChromeOS, and Linux in general, is still a relatively new contender in the consumer PC space—and, as a result, not the primary focus for peripheral device manufacturers when it comes to interoperability testing and validation. Compounded with the many variations of kernels actively supported across the fleet of ChromeOS devices, it is challenging to maintain device interoperability with the ChromeOS platform (or to motivate the ecosystem to dedicate resources toward validation).

Our previous Bluetooth stack, BlueZ, used a different code base and APIs between phone and PC ecosystems—leading to friction. This friction led to a longer time-to-market for new features. The maintenance cost of BlueZ is also higher than Floss, because over 50% of the code is in the Linux kernel, causing extra work when dealing with different versions.

The Android Bluetooth stack is a great alternative for a few reasons:

  • Large user base for better interoperability testing with peripheral devices.
  • Simpler technical architecture that is almost entirely in userspace.
  • Improved testability and security (userspace isolation and migration to Rust).

Introducing Project Floss

We created Project Floss as the ChromeOS and Linux frontend to Fluoride. Our core goals for Floss were to reduce engineering overhead, converge Google's efforts on a single stack, and reduce ecosystem fragmentation.

Diagram of the BlueZ software stack, displaying interactions between the kernel and the userspace daemon, as described in the following section.

BlueZ roughly splits Bluetooth software implementation into three areas: the kernel, the userspace daemon, and the audio server.

  • The audio server implements the Hands-Free profile and audio encoding/decoding.
  • The userspace daemon exposes the D-Bus APIs necessary to control Bluetooth and handles most of the device and profile management.
  • Finally, the kernel implements most of the core functionality and exposes several sockets to allow communication with the kernel.

Diagram of the Floss software stack, displaying differences in system architecture as outlined in the following section.

Migrating from Bluez to Floss simplifies a lot of the system architecture:

  • The audio server can control the audio connection via D-Bus and send data to the userspace daemon over domain sockets because it sends raw PCM data and does not handle any of the encoding/decoding.
  • The Bluetooth implementation is fully contained in the Floss daemon. The Floss daemon is sandboxed in userspace using minijail to reduce its permissions to the minimum set necessary for Bluetooth operation, which greatly improves the security of the system.
  • The kernel exposes a raw HCI socket directly to userspace for exclusive ownership.

Implementing Android’s Fluoride on ChromeOS

The Floss implementation shares most of its code with Android via libbluetooth, the native implementation of the Bluetooth stack. Floss implements the D-Bus APIs for managing devices, media and sockets by calling the necessary methods in libbluetooth. Since Floss is written entirely in Rust, there is a Rust to C/C++ layer called topshim which translates methods and data to allow the two code blocks to work together.

The Android specific portion of the implementation deals with which APIs are exposed to applications, how the system audio interacts with Bluetooth, and how the HALs are implemented (HCI HAL and various Audio HALs).

Diagram showing the overall Bluetooth Software stacks between Android and ChromeOS.

Improvements from Fluoride and Project Floss

In our internal tests, we saw performance improvements across the following metrics: reduced pairing duration, increased pairing success rate, and increased reconnection success rate.

Chart showing the pairing time between BlueZ and Floss

Chart showing the pairing time between BlueZ and Floss


Chart showing the pairing outcome between BlueZ and Floss

Chart showing the pairing outcome between BlueZ and Floss

Chart showing the reconnection success between BlueZ and Floss

Chart showing the reconnection success between BlueZ and Floss

In addition to improved performance, with Floss we can bring new features to ChromeOS with faster speed and built-in interoperability with Android.

LE audio

The Bluetooth market is constantly growing, and by 2026 there are expected to be seven billion Bluetooth device shipments globally. By 2026, it’s projected that three billion of seven billion devices will be LE Audio devices. LE Audio will enhance the performance of Bluetooth audio, add support for hearing aids, and enable Broadcast Audio, an innovative new Bluetooth feature with the potential to once again dramatically improve the way we experience audio and connect with the world around us.

New codecs

With Fluoride already supporting several advanced codecs, Floss will work to enable additional codecs to enable higher quality voice and audio streaming.

Better Together Accelerator

By sharing the underlying code base within Google, we can maximize the benefits of varying priorities in different products rather than having them compete with each other. Having one group focused on car interoperability and another focused on cross-device experiences will result in both benefits at the same time and scale throughout our product lines.

Reduced Bluetooth ecosystem fragmentation

Both Android and ChromeOS are motivated to provide timely updates to our customers and the larger ecosystem. This is key to ensure that we have a coherent codebase and reduce overall fragmentation in the Bluetooth ecosystem.

We aspire to position Project Floss as a standalone open source project that can reach beyond the walls of Google’s own operating system in a way where we can maximize the overall value and agility of the larger Bluetooth ecosystem. We also intend to support the Linux community as a whole with the goal that Floss can easily run on most Linux distributions.


  1. Bluetooth 2023 market update

    ↩︎