The Fuchsia Bluetooth stack is an implementation of the Bluetooth 5.0 Host Subsystem. It intends to provide a dual-mode implementation of the Generic Access Profile, a module framework for developing Bluetooth Low Energy applications, a limited set of Bluetooth Classic profiles, and a framework for building HCI transport drivers.
The bluetooth package contains the Bluetooth process, some command-line tools, and unit tests. The bluetooth_examples package contains various example applications that interact with the Bluetooth FIDL interfaces.
You generally do not need to build the entire Fuchsia tree for Bluetooth development. The following configures a minimal build that includes Bluetooth unit tests and command-line tools (useful for quick iteration times when developing unit tests on QEMU):
./packages/gn/gen.py --modules fxl,mtl,bluetooth
NOTE: You may see warnings related to skia which are safe to ignore. The warnings can be muted by passing
--ignore-skia to gen.py.
To build the entire Fuchsia tree and also include the FIDL examples:
./packages/gn/gen.py --modules bluetooth_examples,default
bt-hci device is published for each local Bluetooth controller under
/dev/class/bt-hci/. The Bluetooth host-subsystem process and the command-line tools that interact with a Bluetooth controller obtain channel handles from a bt-hci device using the ioctls defined here.
Bluetooth functionality is currently exposed via FIDL services that are provided by the Bluetooth process (currently installed at
/system/apps/bluetooth). This process implements the core Bluetooth protocols required for the Generic Access Profile (HCI state machines, L2CAP, GATT, SDP, SM, etc).
The process is launched by Bootstrap when an application requests one of the Bluetooth services. The service-to-binary mapping for Bluetooth services is currently defined in Bootstrap's
This is a command-line client for the control FIDL interfaces. The
bluetooth process does not need to launched directly before using
bluetoothcli since Bootstrap will launch a new
bluetooth process during the service request if one isn't already running.
$ bluetoothcli bluetooth> list-adapters Adapter 0 id: bf004a8b-d691-4298-8c79-130b83e047a1 address: 00:1A:7D:DA:0A powered: yes
hcitool can be used to directly send HCI commands to a bt-hci device:
$ hcitool reset Sent HCI_Reset (id=1) Command Complete - status 0x00 (id=1) $ hcitool read-bdaddr Sent HCI_Read_BDADDR (id=1) Command Complete - status 0x00 (id=1) BD_ADDR: 00:1A:7D:DA:71:0A
hcitool binds the control channel of the specified bt-hci device (
/dev/class/bt-hci/000 by default) provided that it has not already been bound by another process.
btsnoop binds the snoop channel of a specified bt-hci device (
/dev/class/bt-hci/000 by default) and writes HCI traffic to a specified file using the BTSnoop file format. The captured packets can be visualized using any protocol analyzer that supports BTSnoop (e.g. Wireshark).
The following command will sniff all HCI traffic to/from
/dev/class/bt-hci/001 and write it to /tmp/btsnoop.log (on a Fuchsia device):
$ btsnoop --path=/tmp/btsnoop.log --dev=/dev/class/bt-hci/001
Logs can then be copied from the Fuchsia device and passed directly to Wireshark:
$ netcp :/tmp/btsnoop.log ./ $ wireshark ./btsnoop.log
All Bluetooth unit tests are currently compiled into a single GTest binary installed at