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
bt-transport protocol. Zircon provides drivers that implement the HCI transport over USB and UART. 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.
/dev/class/bt-transport/000). 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
bt-host devices. A bt-host device claims the HCI control and data endpoints of the underlying
bt-hci and implements:
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 management library 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