The Fuchsia Bluetooth system (source layout) aims to provide a dual-mode implementation of the Bluetooth Host Subsystem versions 4.2 and 5.0+. This includes
A framework for developing Bluetooth Low Energy applications in central, peripheral, broadcaster, and scanner roles.
DDK interfaces for building LE and Traditional service drivers that have high throughput requirements.
A DDK surface for building vendor-specific HCI drivers to support a wide range of Bluetooth controllers as well as generic transport drivers.
Services for policy and management to integrate a system with the Generic Access Profile.
Bluetooth controllers that are present on the system surface as a hierarchy of devices. On an x86 platform this hierarchy may look like the following:
[pci] pid=1633 /boot/driver/bus-acpi.so [00:14.0] pid=1633 /boot/driver/bus-pci.so <00:14.0> pid=2179 /boot/driver/bus-pci.proxy.so [xhci] pid=2179 /boot/driver/xhci.so [usb] pid=2179 /boot/driver/usb-bus.so  pid=2179 /boot/driver/usb-bus.so [ifc-000] pid=2179 /boot/driver/usb-bus.so [bt_transport_usb] pid=2179 /boot/driver/bt-transport-usb.so [bthci-passthrough] pid=2179 /system/driver/bthci-passthrough.so [bt-host] pid=2179 /system/driver/bthost.so
Generic HCI transport functionality is provided by the
Zircon provides drivers that implement the HCI transport over
The transport protocol abstracts the HCI control, ACL, and SCO
channels (currently as Zircon channels).
A transport driver publishes a bt-transport device (e.g.
Each of these devices only represents the transport and not an initialized
Bluetooth controller since most Bluetooth controllers require vendor-specific protocols
for their setup (e.g. to load firmware). That logic is implemented by vendor HCI
drivers that bind to a bt-transport device.
Vendor drivers have access to the bt-transport protocol for HCI transactions, as
well as other underlying protocols that the transport device supports. Once a
Bluetooth controller has been initialized and is ready for the host subsystem,
the vendor driver publishes a
The system provides the
bthci-passthrough driver which binds to bt-transport
devices that are not claimed by any vendor-specific driver. bthci-passthrough
simply publishes a bt-hci device without doing special initialization.
bthost driver implements the core Bluetooth protocols that form the
Generic Access Profile. bthost binds to bt-hci devices and publishes
devices. A bt-host device claims the HCI control and data endpoints of the underlying
bt-hci and implements:
- The core dual-mode GAP bookkeeping
- Handling of FIDL messages for core services
- L2CAP and fixed channel protocols (GATT, SMP, SDP)
- Pairing protocols and delegation
- Other types of IPC (such as L2CAP sockets)
- Bus protocol for child devices for services implemented as device drivers
Host devices are managed by the Bluetooth system service. The service allows only one bt-host to be accessed for service requests at a given time. This bt-host is represented as the "active Adapter". control.fidl provides a management interface to designate an active adapter when multiple adapters are present.
bt-host devices implement the host.fidl protocol to communicate with the Bluetooth system service.
TODO(armansito): child devices
Bluetooth environment services are the primary way to implement Bluetooth services and applications.
The Control FIDL library is intended for privileged clients and is for device-level control/policy.
TODO: describe other services
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2019-12-02.