The Blitzy BlueZ: Building Bluetooth Support
Apr 14, 2026 • Carly Levinsohn • 5 min read
Originally developed as a Qualcomm project by Max Krasnyansky, BlueZ has been the official Linux Bluetooth protocol for roughly 25 years. Since the hallmark release of BlueZ under General Public License in May 2001, Qualcomm has had significant influence on Bluetooth development.
One month later, Linus Torvalds incorporated the BlueZ library into the 2.4.6 release of the Linux kernel. From then on, Linux got its own Bluetooth stack.
In January 2004, BlueZ was handed over to Marcel Holtmann as the system's maintainer.
The new maintainer led the library to eventually achieve official qualification as a subsystem by Bluetooth SIG in 2005. With support from TomTom BV (a European-based software company), the conformance was a crucial stepping stone for adopting Bluetooth technology in Linux-based embedded devices and PCs.
BlueZ's Significance
Qualcomm did not create BlueZ in a vacuum. Their position in the Bluetooth development market made the project inevitable.
Shortly after the Bluetooth Special Interest Group's (SIG) founding, Qualcomm was an "Early Adopter" for the organization in 1998. Qualcomm's interest in Bluetooth technology did not stop here.
The company had invested in wireless chipsets. Bluetooth was brand new at the time (with version 1.0 released in 1999), and Linux was becoming the operating system of choice for both mobile and embedded devices. The problem: Linux had no Bluetooth stack. If a chipmaker like Qualcomm wanted their Bluetooth silicon to work on Linux-based devices, someone had to write the host-side software.
BlueZ is a classic example of a hardware company open-sourcing driver and protocol software to encourage adoption of their chips: the same tactic other enterprises like Intel, Broadcom and others have done repeatedly.
The Challenges in Recreating BlueZ
Sitting at approximately 408,000 lines with corner cases and minimal comments, BlueZ is a daunting opponent for any refactor. The system has been a standard for many years, but exploits in memory management and security lay dormant in the code.
BlueZ communicates through D-Bus messages and signals. The protocol works nothing like Bluetooth APIs on Android, iOS, or Windows. Most developers have to relearn everything just to get started.
Then, there's debugging. BlueZ is split across the kernel, userspace, and an audio daemon.
A bug might live in any of the three, and each ships on its own release cycle tied to different kernel versions. Reproducing an issue on one system tells you little about another. That fragmentation makes every fix a maintenance problem.
The underlying architecture prevents BlueZ from staying current with the rapid changes in the Bluetooth ecosystem. Interoperability fixes are slow to reach end users. Fewer bugs in Linux Bluetooth are found and resolved because of the contributing overhead required for peripheral manufacturers working on the software.
BlueZ's vicious cycle can be broken with a simpler, userspace-first architecture. That new approach is exactly what ChromeOS decided to do.
In approximately two and a half years, ChromeOS' Project Floss was able to achieve feature parity with BlueZ only on common Bluetooth use cases like keyboards and audio devices. The real feat was in the adjusted architecture: Floss contained their entire implementation in one daemon sandboxed in userspace with minimal kernel permissions. The initiative remains an internal Google success story rather than a drop-in replacement for BlueZ in Linux.
Project Floss is a captivating achievement for refactoring the C library. The initiative drove our engineers to push for an even greater technical challenge: could Blitzy take on BlueZ in its entirety?
What Blitzy Built
The platform rewrote the BlueZ v5.86 userspace in idiomatic Rust. Ultimately, Blitzy built a memory-safe, async-first Cargo workspace all while preserving byte-identical D-Bus contracts and wire protocol ending. The prompt focused on four main deliverables:
- Eliminating memory management vulnerabilities
- Replacing GLib/ELL event loops with tokio async runtime
- Substituting libdbus-1/gdbus with type-safe zbus 5.x bindings
- Preserving 100% of the config file and D-Bus API compatibility
See the project guide that recaps the work. The results are as follows:
- 8 Cargo workspace crates replacing 5 daemon binaries + shared libraries
- 253 Rust source files (approx. 380,513 LOC) replacing 715 C files (approx. 522,547 LOC)
- 4,339 tests passing with 0 failures in unit, integration, and doc-tests
- 30+ D-Bus interfaces implemented via
#[zbus::interface]proc macros - CI pipeline with four parallel jobs (fmt, clippy, build, test)
- Gate 6 unsafe code audit: 272 blocks, 100% SAFETY comment coverage
Blitzy completed 90.6% of the project equating to 920 engineering hours in days.
The remaining work is well-defined and understood. The table below shows the estimated time each task will take to complete for an engineer with corresponding priority level:
| Task | Hours | Priority |
|---|---|---|
| Gate 1 — Live daemon E2E boundary verification | 16 | High |
| Gate 4 — btsnoop replay + mgmt-tester suite | 16 | High |
| Gate 5 — API contract verification (busctl XML diff) | 12 | High |
| Gate 8 — Integration sign-off (live smoke test) | 8 | High |
| Gate 3 — Performance baseline benchmarking vs C | 12 | Medium |
| Hardware integration testing on physical adapters | 12 | Medium |
| Production deployment & systemd integration testing | 8 | Medium |
| D-Bus security policy review & hardening | 4 | Medium |
| Performance tuning (if thresholds not met) | 8 | Low |
| Documentation updates & production runbooks | 4 | Low |
Implications
The original BlueZ was not maintained but managed.
Adding onto the library meant navigating many implicit conventions, tracing cross-cutting dependencies across daemon boundaries and traversing steep learning curves. The difficulties made new codebase changes risky, causing contributors to lessen and the library to calcify. Blitzy's rewrite removes that bottleneck.
The final codebase fanned out to eight isolated crates that allow engineers to work on one module and clearly understand its explicit boundaries and dependencies. Declarative D-Bus interfaces create readability with API contracts visible at a glance. All 272 safe blocks carry a documented safety justification, so engineers can comprehend the reasoning behind them.
The real deliverable in our refactoring efforts is a codebase that does not inhibit its own evolution. Blitzy's implementation is one that contributors can easily read, CI can enforce, and 4,300 tests can verify without depending on any one individual's knowledge.
Blitzy enables BlueZ to outlive its builders: a goal all great creators dream about.
Interested in learning more about what your team can build with Blitzy? Learn more here.
