fuchsia.bluetooth.sys

Protocol that abstracts the operational modes and procedures defined in the Bluetooth Generic Access Profile (see Core Specification v5.1, Vol 3, Part C).

The procedures under this protocol apply to the system as a whole. The Bluetooth controller that plays an active role in these procedures can be managed using the HostWatcher protocol.

The procedures initiated by an Access protocol instance are terminated when the underlying channel is closed.

Connect

Initiate a connection to the peer with the given id. This method connects both BR/EDR and LE transports depending on the technologies that the peer is known to support.

request id The id of the peer to connect.

error Reports Error.FAILED if a connection to the peer cannot be initiated.
error Reports Error.PEER_NOT_FOUND if id is not recognized.

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`

Response

Name	Type
`payload`	`Access_Connect_Result`

Disconnect

Disconnect all logical links to the peer with the given id. This includes LE and BR/EDR links that have been initiated using all Access and fuchsia.bluetooth.le protocol instances.

request id The id of the peer to disconnect.

error Reports Error.PEER_NOT_FOUND if id is not recognized.

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`

Response

Name	Type
`payload`	`Access_Disconnect_Result`

Forget

Removes all bonding information and disconnects any existing links with the peer with the given id.

request id The id of the peer to forget.

error Reports Error.PEER_NOT_FOUND if id is not recognized.

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`

Response

Name	Type
`payload`	`Access_Forget_Result`

MakeDiscoverable

Put the system into the "General Discoverable" mode on the BR/EDR transport. The active host will respond to general inquiry (by regularly entering the inquiry scan mode).

request token fuchsia.bluetooth.sys/ProcedureToken that will remain valid while a discoverable mode session is active. NOTE: The system may remain discoverable until all fuchsia.bluetooth.sys/Access clients drop their tokens.

error Reports Error.FAILED if inquiry mode cannot be entered.

Request

Name	Type
`token`	`server_end<ProcedureToken>`

Response

Name	Type
`payload`	`Access_MakeDiscoverable_Result`

Pair

Initiate a pairing to the remote id with the given options. This call completes only once the pairing procedure has completed or aborted. Returns an error if no connected peer with id is found or the pairing procedure fails. If the named peer is already paired, this returns immediately with a success value - unless the pairing is over LE and the PairingOptions.le_security_level is more secure than the current security level, in which case we will attempt to raise security to the requested level.

Pairing will take place over whichever transport is indicated by options.transport. If that transport isn't currently connected, the pairing will fail with Error.PEER_NOT_FOUND. Currently, if DUAL_MODE is requested, we will attempt to pair over the LE transport.

request id The id of the peer to initiate pairing with
request options The configuration options to use for this pairing request

error Reports Error.PEER_NOT_FOUND if id is not recognized, or the peer is not connected on the requested transport.
error Reports Error.INVALID_ARGUMENTS if ill-formed options are passed
error Reports Error.FAILED if an error occurs during pairing

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`
`options`	`PairingOptions`

Response

Name	Type
`payload`	`Access_Pair_Result`

SetDeviceClass

Set the local device class that will be visible to nearby peers when the system is in discoverable mode.

request device_class The device class to assign to the system.

Request

Name	Type
`device_class`	`fuchsia.bluetooth/DeviceClass`

SetLocalName

Assign a local name for the Bluetooth system. This name will be visible to nearby peers when the system is in discoverable mode and during name discovery procedures.

request name The complete local name to assign to the system.

Request

Name	Type
`name`	`fuchsia.bluetooth/DeviceName`

SetPairingDelegate

Assign a PairingDelegate to respond to drive pairing procedures. The delegate will be configured to use the provided I/O capabilities to determine the pairing method.

Only one PairingDelegate can be registered at a time. Closing a PairingDelegate aborts all on-going pairing procedures associated with a delegate and closes the PairingDelegate previously assigned for this Access instance.

request input Bluetooth input capability
request output Bluetooth output capability
request delegate The client end of a PairingDelegate channel.

Deprecation - This method is folded into the fuchsia.bluetooth.sys/Pairing protocol. See

https://fxbug.dev/42180744 for more details on the migration.

Deprecated: HEAD Added: 7

Request

Name	Type
`input`	`InputCapability`
`output`	`OutputCapability`
`delegate`	`PairingDelegate`

StartDiscovery

Start a general discovery procedure. All general discoverable BR/EDR, LE, and BR/EDR/LE devices will appear in the peer list, which can be observed by calling fuchsia.bluetooth.sys/Access.WatchPeers.

request token fuchsia.bluetooth.sys/ProcedureToken that will remain valid while discovery is in progress. NOTE: The radio will continue performing discovery until all fuchsia.bluetooth.sys/Access drop their tokens.

error Reports Error.FAILED if discovery on either transport cannot be initiated.

Request

Name	Type
`token`	`server_end<ProcedureToken>`

Response

Name	Type
`payload`	`Access_StartDiscovery_Result`

WatchPeers

Returns a list of all peers (connectable Bluetooth devices) known to the system. The first call results in a snapshot of all known peers to be sent immediately in the updated return paremeter. Subsequent calls receive a response only when one or more entries have been added, modified, or removed from the entries reported since the most recent call.

response updated Peers that were added or updated since the last call to WatchPeers().
response removed Ids of peers that were removed since the last call to WatchPeers().

Request

<EMPTY>

Response

Name	Type
`updated`	`vector<Peer>`
`removed`	`vector<fuchsia.bluetooth/PeerId>`

Bootstrap

Protocol used to initialize persistent core Bluetooth data. This protocol populates data that determine the identity of this device as perceived by other Bluetooth devices.

This protocol can be obtained only before the core Bluetooth host subsystem has generated its own identity. Once initial data is committed, this capability becomes unavailable and remains unavailable even if new Bluetooth adapters are attached.

Due to the privacy and bonding secrets involved, as well as the capability to make this device assume the Bluetooth identity of another device, this protocol should only be exposed to privileged components that can vouchsafe the origin of the data.

AddIdentities

Adds identities to be added to the unpopulated Bluetooth stack.

Repeated calls will append identities.

Request

Name	Type
`identities`	`vector<Identity>`

Commit

Writes all added bootstrapping data to the Bluetooth core stack. The server will close the channel regardless of success. Returns without error if successful and the stack will be considered initialized even if no bootstrapping data was written. Returns INVALID_HOST_IDENTITY if any host or bonded peer data is insufficient or inconsistent, with no effect (the client may retry by obtaining another protocol handle).

Request

<EMPTY>

Response

Name	Type
`payload`	`Bootstrap_Commit_Result`

Configuration

Defined in fuchsia.bluetooth.sys/configuration.fidl

Protocol to configure parameters and features for the core Bluetooth system. These settings apply to all bt-host drivers known to the system.

This protocol should only be exposed to highly privileged components (e.g. Bluetooth developer tools in a testing/qualification environment).

Update

Applies the fields present in settings to all bt-host drivers known to the system. Any fields not present in settings will remain unchanged.

request settings The new settings for active bt-host drivers - only modified settings need be present.

response result A fully-populated table with the resultant settings after the new settings are applied.

Request

Name	Type
`settings`	`Settings`

Response

Name	Type
`result`	`Settings`

HostWatcher

Defined in fuchsia.bluetooth.sys/host_watcher.fidl

Protocol used to observe and manage the Bluetooth controllers on the system.

SetActive

Designates the host with the given id as active. All Bluetooth procedures will be routed over this host. Any previously assigned active host will be disabled and all of its pending procedures will be terminated.

error This can fail if a host with id was not found.

Request

Name	Type
`id`	`fuchsia.bluetooth/HostId`

Response

Name	Type
`payload`	`HostWatcher_SetActive_Result`

Watch

Obtain a list of all available Bluetooth controllers and their state. A response is sent only if this list has changed since the last time the client has sent this message.

Request

<EMPTY>

Response

Name	Type
`hosts`	`vector<HostInfo>`

Pairing

Allows system clients to enable Bluetooth pairing.

Added: HEAD

SetDelegate

Assign a PairingDelegate2 to handle pairing procedures. The provided I/O capabilities will be used to determine the methods used.

Only one of PairingDelegate or PairingDelegate2 can be set at a time system-wide. If this is called while another delegate is set, the new delegate will be closed immediately.

Closing a PairingDelegate2 unsets the pairing delegate. Ongoing PairingRequests can still be completed, but new requests will act as if no delegate is set.

If no delegate is set, all pairings will be rejected even if the peer connection was initiated by the local device.

request input Bluetooth input capability, see InputCapability
request output Bluetooth output capability, see OutputCapability
request delegate PairingDelegate2 which will receive pairing requests

Request

Name	Type
`input`	`InputCapability`
`output`	`OutputCapability`
`delegate`	`PairingDelegate2`

SetPairingDelegate

Assign a PairingDelegate to respond to pairing procedures. The provided I/O capabilities will be used to determine the pairing methods used.

Only one PairingDelegate can be set at a time system-wide - if this is called while another delegate is set, the new delegate will be closed immediately. Closing a PairingDelegate after it is set aborts all ongoing pairing procedures without accepting and unsets the delegate.

If no PairingDelegate is set, all pairings will be rejected even if the peer connection was initiated by the local device.

request input Bluetooth input capability, see InputCapability
request output Bluetooth output capability, see OutputCapability
request delegate PairingDelegate which will receive pairing requests

Request

Name	Type
`input`	`InputCapability`
`output`	`OutputCapability`
`delegate`	`PairingDelegate`

PairingDelegate

A Bluetooth Pairing Delegate is responsible for confirming or denying pairing requests received from Bluetooth peers that connect or are being connected to the local device.

Any new pairing will result in a call to PairingDelegate.OnPairingRequest, including pairings where the InputCapability and OutputCapability are set to none. The delegate is expected to have enough context to derive whether to accept or deny the pairing.

Only one delegate is allowed to be set per system at a time. See fuchsia.bluetooth.sys.Pairing for how to set the pairing delegate.

OnLocalKeypress

The delegate can send this event to notify the peer of local keypresses during pairing using PairingMethod.PASSKEY_ENTRY.

Sending local keypress events can allow the user additional time for pairing when entering a passkey.

This should only be sent after an OnPairingRequest has been received with a PASSKEY_ENTRY method, and before the reponse for that pairing request.

request id id of a peer with a pairing request active
request keypress the type of notification which should be sent

Response

Name	Type
`id`	`fuchsia.bluetooth/PeerId`
`keypress`	`PairingKeypress`

OnPairingComplete

Called when the pairing procedure for a peer has been completed. This can be due to successful completion or an error (e.g. due to cancellation by the peer, a timeout, or disconnection).

request id The Bluetooth peer ID of the peer which was being paired.
request success true if the pairing succeeded, otherwise false.

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`
`success`	`bool`

OnPairingRequest

Called to confirm a pairing. The pairing process will be continued if accept response is true and rejected otherwise. If the pairing method requires a passkey it must be included as well. Pairing methods that do not require a passkey ignore the entered_passkey repsonse.

The pairing can fail (usually by timeout or peer disconnect) before the response is received. The OnPairingComplete method will be called when this occurs. Any response sent in this case will be ignored.

request peer information about the peer being paired
request method method of pairing active. See PairingMethod
request displayed_passkey a passkey to display to the user if PASSKEY_DISPLAY or PASSKEY_COMPARISON is being used. Meaningless otherwise.

response accept true if the pairing is accepted
response entered_passkey passkey entered by the user. Ignored unless method is PASSKEY_ENTRY.

Request

Name	Type
`peer`	`Peer`
`method`	`PairingMethod`
`displayed_passkey`	`uint32`

Response

Name	Type
`accept`	`bool`
`entered_passkey`	`uint32`

OnRemoteKeypress

Called to notify keypresses from the peer device during pairing using PairingMethod.PASSKEY_DISPLAY.

This event is used to provide key press events to the delegate for a responsive user experience as the user types the passkey on the peer device. This event will be called once for each keypress.

This event will only be called between when an OnPairingRequest has been sent for id and when OnPairingComplete is sent.

Note: many devices do not send these events

request id The peer id of the peer that sent the keypress event.
request keypress The type of event which was received.

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`
`keypress`	`PairingKeypress`

PairingDelegate2

A Bluetooth Pairing Delegate is responsible for confirming or denying pairing requests received from Bluetooth peers that connect or are being connected to the local device.

Any new pairing will result in a call to PairingDelegate.StartRequest, including pairings where the InputCapability and OutputCapability are set to none. The delegate is expected to have enough context to derive whether to accept or reject the pairing.

Only one delegate is allowed to be set per system at a time. See fuchsia.bluetooth.sys.Pairing for how to set the pairing delegate.

Added: HEAD

RequestComplete

Called when the pairing procedure for a peer has been completed. This can be due to successful completion or an error (e.g. due to cancellation by the peer, a timeout, or disconnection).

request id The Bluetooth peer ID of the peer which was being paired
request success true if the pairing succeeded, otherwise false

Request

Name	Type
`id`	`fuchsia.bluetooth/PeerId`
`success`	`bool`

StartRequest

Called when a pairing with peer is started. The pairing process is continued using the PairingRequest protocol.

The properties of the pairing are provided in info which indicates what type of interaction is intended locally.

Multiple requests can be active at one time for different peers, and requests can outlive this protocol. Dropping the request protocol will automatically reject the pairing.

All fields will always be present.

Request

Name	Type
`payload`	`PairingDelegate2StartRequestRequest`

PairingRequest

This protocol is active when a pairing is in progress, and provided to the PairingDelegate via the PairingDelegate.StartRequest The server will close this protocol with an epitaph if the pairing process completes early without success:

ZX_ERR_UNAVAILABLE - Bluetooth peer has disconnected
ZX_ERR_NOT_SUPPORTED - a passkey was provided when it was not expected
ZX_ERR_BAD_STATE - a keypress was sent when not using PairingProperties.passkey_entry
ZX_ERR_TIMED_OUT - no activity was detected, and the pairing was stopped

Added: HEAD

Accept

Accept the pairing request. entered_passkey is required if the PairingProperties.passkey_entry method is used, ignored otherwise.

Request

Name	Type
`payload`	`PairingRequestAcceptRequest`

Keypress

Used to communicate local keypresses to update the remote peer on the progress of the pairing. The responses to this method should be used for flow control.

Request

Name	Type
`keypress`	`PairingKeypress`

Response

<EMPTY>

OnComplete

Sent once when the pairing is completed, just before the protocol is closed. The success value along with the PeerId will also be sent to the delegate using the PairingDelegate.RequestComplete call.

Response

Name	Type
`success`	`bool`

OnKeypress

Sent when the pairing method is passkey_display. Can be used to update the UI to indicate reception of keypresses.

Response

Name	Type
`keypress`	`PairingKeypress`

Reject

Reject the pairing request. Closing this protocol will also reject the pairing request.

Request

<EMPTY>

ProcedureToken

Represents an active procedure. The validity of a handle that supports this protocol is tied to the activity of the procedure that it is attached to. To elaborate:

Closing a token handle ends the procedure that it is attached to.
The system closes a token handle to communicate that a procedure was internally terminated.

STRUCTS

Access_Connect_Response

<EMPTY>

Access_Disconnect_Response

<EMPTY>

Access_Forget_Response

<EMPTY>

Access_MakeDiscoverable_Response

<EMPTY>

Access_Pair_Response

<EMPTY>

Access_StartDiscovery_Response

<EMPTY>

Bootstrap_Commit_Response

<EMPTY>

<EMPTY>

HostWatcher_SetActive_Response

Defined in fuchsia.bluetooth.sys/host_watcher.fidl

<EMPTY>

Key

Represents a 128-bit secret key.

Field	Type	Description	Default
`value`	`uint8[16]`		No default

LeConnectionParameters

The preferred LE connection parameters of the peer.

Field	Type	Default
`connection_interval`	`uint16`	No default
`connection_latency`	`uint16`	No default
`supervision_timeout`	`uint16`	No default

Ltk

Represents a LE Long-Term peer key used for link encyrption. The ediv and rand fields are zero if distributed using LE Secure Connections pairing.

Field	Type	Default
`key`	`PeerKey`	No default
`ediv`	`uint16`	No default
`rand`	`uint64`	No default

PasskeyEntry

<EMPTY>

PeerKey

Represents a key that was received from a peer.

Field	Type	Description	Default
`security`	`SecurityProperties`	The security properties of this link under which this key was received.	No default
`data`	`Key`	The contents of the key.	No default

SecurityProperties

Field	Type	Default
`authenticated`	`bool`	No default
`secure_connections`	`bool`	No default
`encryption_key_size`	`uint8`	No default

ENUMS

BondableMode strict

Type: uint32

Defined in fuchsia.bluetooth.sys/pairing_options.fidl

Whether or not the device should form a bluetooth bond during the pairing prodecure. As described in Core Spec v5.2 | Vol 3, Part C, Sec 4.3

Name	Value	Description
BONDABLE	`1`	The device will form a bond during pairing with peers
NON_BONDABLE	`2`	The device will not form a bond during pairing with peers

BootstrapError strict

Type: uint32

Name	Value	Description
INVALID_HOST_IDENTITY	`1`
WRITE_FAILURE	`2`

BrEdrSecurityMode strict

Type: uint32

Defined in fuchsia.bluetooth.sys/security_mode.fidl

The BR/EDR Security Mode of a BT device determines the possible security properties of the device. The security mode does not make specific guarantees about the current security properties of a device's connections; it sets restrictions on the allowable security properties. See Core Spec v5.4 Vol. 3, Part C 5.2.2 for more details.

Added: 14

Name Value Description

Name	Value	Description
MODE_4	`1`	In BR/EDR Security Mode 4, communication will be authenticated and encrypted using the lowest common denominator algorithm between the pairing devices. Note that this means key generation, authentication, and encryption algorithms used may be weaker than Secure Connections if SC is not supported.
SECURE_CONNECTIONS_ONLY	`2`	In Secure Connections Only mode, the device will reject connections that do not support Secure Connections, and longer key lengths will be enforced. SC Only mode also attempts to enforce user confirmation of the expected peer. Devices that do not have a display (e.g. headsets) do not typically support SC for this reason.

MODE_4

1

In BR/EDR Security Mode 4, communication will be authenticated and encrypted using the lowest common denominator algorithm between the pairing devices. Note that this means key generation, authentication, and encryption algorithms used may be weaker than Secure Connections if SC is not supported.

SECURE_CONNECTIONS_ONLY

2

In Secure Connections Only mode, the device will reject connections that do not support Secure Connections, and longer key lengths will be enforced.

SC Only mode also attempts to enforce user confirmation of the expected peer. Devices that do not have a display (e.g. headsets) do not typically support SC for this reason.

Error strict

Type: uint32

Name	Value	Description
FAILED	`1`	Operation could not be performed.
PEER_NOT_FOUND	`2`	The peer designated for the operation was not found.
TIMED_OUT	`3`	The time limit for the operation has expired.
CANCELED	`4`	The operation was canceled.
IN_PROGRESS	`5`	Operation already in progress.
NOT_SUPPORTED	`6`	Operation not supported.
INVALID_ARGUMENTS	`7`	The operation was given an invalid set of arguments.

InputCapability strict

Type: uint32

Input Capabilities for pairing exchanges. These should be set based on the ability of the local system to enter responses to pairing requests. See Volume 3, Part C, Table 5.3 for more information.

Name	Value	Description
NONE	`1`	There is no user input method available for responding 'yes' or 'no' to a pairing request. Note: setting this setting will mean most pairings are considered unauthenticated and vulnerable to machine-in-the-middle attacks.
CONFIRMATION	`2`	The user can respond yes or no to a request.
KEYBOARD	`3`	The user has a keyboard (or other UI) where they can type a numerical code and signal they have finished or cancel.

LeSecurityMode strict

Type: uint32

Defined in fuchsia.bluetooth.sys/security_mode.fidl

The LE Security Mode of a BLE device determines the possible security properties of the device. The security mode does not make specific guarantees about the current security properties of a device's connections; it sets restrictions on the allowable security properties. See Core Spec v5.2 Vol. 3, Part C 10.2 for more details.

Name	Value	Description
MODE_1	`1`	In LE Security Mode 1, communication is secured by encryption, and BLE-based services may specify varying requirements for authentication, key size, or Secure Connections protection on the encryption keys.
SECURE_CONNECTIONS_ONLY	`2`	In Secure Connections Only mode, all secure communication must use 128 bit, authenticated, and LE Secure Connections-generated encryption keys. If these encryption key properties cannot be satisfied by a device due to system constraints, any connection involving such a device will not be able to secure the link at all. This mode does not prevent unencrypted communication; it merely enforces stricter policies on all encrypted communication.

OutputCapability strict

Type: uint32

Output Capabilities for pairing excanges. These should be set based on the ability of the local system to display information to the user initiating or accepting a Bluetooth pairing. See Volume 3, Part C, Table 5.4 for more information.

Name	Value	Description
NONE	`1`	There is no display available for pairing.
DISPLAY	`2`	There is a display that can show at least a six-digit decimal number.

PairingKeypress strict

Type: uint32

Used to convey information to the peer on progress typing a passkey. The various types of keypresses can be used to customize what is communicated to the user requesting a pairing.

Name	Value	Description
DIGIT_ENTERED	`1`	The user has entered a single digit.
DIGIT_ERASED	`2`	The user has erased a single digit.
PASSKEY_CLEARED	`3`	The user has cleared the entire passkey.
PASSKEY_ENTERED	`4`	The user has finished entering the passkey.

PairingMethod strict

Type: uint32

Different types required by the Security Manager for pairing methods. Bluetooth SIG has different requirements for different device capabilities.

Name	Value	Description
CONSENT	`1`	The user is asked to accept or reject pairing. This is the minimum method - even when both devices do not support input or output, the delegate will be asked to confirm any pairing not initiated with user intent.
PASSKEY_DISPLAY	`2`	The user is shown a 6-digit numerical passkey on this device which they must enter on the peer device.
PASSKEY_COMPARISON	`3`	The user is shown a 6-digit numerical passkey on this device which will also shown on the peer device. The user must compare the passkeys and accept the pairing if the passkeys match.
PASSKEY_ENTRY	`4`	The user is asked to enter a 6-digit passkey on this device which is communicated via the peer device.

PairingSecurityLevel strict

Type: uint32

Defined in fuchsia.bluetooth.sys/pairing_options.fidl

The security level required for this pairing - corresponds to the security levels defined in the Security Manager Protocol in Vol 3, Part H, Section 2.3.1

Name	Value	Description
ENCRYPTED	`1`	Encrypted without MITM protection (unauthenticated)
AUTHENTICATED	`2`	Encrypted with MITM protection (authenticated), although this level of security does not fully protect against passive eavesdroppers

TechnologyType strict

Type: uint32

Defined in fuchsia.bluetooth.sys/peer.fidl

Name	Value	Description
LOW_ENERGY	`1`
CLASSIC	`2`
DUAL_MODE	`3`

TABLES

BondingData

Represents the bonding data for a single peer.

Ordinal	Field	Type	Description
1	`identifier`	`fuchsia.bluetooth/PeerId`	The identifier that uniquely identifies this peer.
2	`local_address`	`fuchsia.bluetooth/Address`	The local Bluetooth identity address that this bond is associated with.
3	`name`	`fuchsia.bluetooth/DeviceName`	The name of the peer, if known.
6	`address`	`fuchsia.bluetooth/Address`	The identity address of the peer.
7	`le_bond`	`LeBondData`	Bonding data that is present when this peer is paired on the LE transport.
8	`bredr_bond`	`BredrBondData`	Bonding data that is present when this peer is paired on the BR/EDR transport.

BredrBondData

Ordinal	Field	Type	Description
1	`role_preference`	`fuchsia.bluetooth/ConnectionRole`	The peer's preferred piconet role. This is determined by role switch procedures. Paging and connecting from a peer does not automatically set this flag. If absent, the peer has not expressed a preference.
2	`services`	`vector<fuchsia.bluetooth/Uuid>[65535]`	Known service UUIDs obtained from EIR data or SDP.
3	`link_key`	`PeerKey`	The semi-permanent BR/EDR key. Present if link was paired with Secure Simple Pairing or stronger.

HostData

Represents persistent local host data.

Ordinal Field Type Description

1

irk

LocalKey

The local Identity Resolving Key used by a bt-host device to generate Resolvable Private Addresses when privacy is enabled.

May be absent for hosts that do not use LE privacy, or that only use Non-Resolvable Private Addresses.

NOTE: This key is distributed to LE peers during pairing procedures. The client must take care to assign an IRK that consistent with the local bt-host identity.

HostInfo

Defined in fuchsia.bluetooth.sys/host_watcher.fidl

Information about a Bluetooth controller and its associated host-subsystem state.

Ordinal	Field	Type	Description
1	`id`	`fuchsia.bluetooth/HostId`	Uniquely identifies a host on the current system. This field is always present.
2	`technology`	`TechnologyType`	The Bluetooth technologies that are supported by this adapter. This field is always present.
4	`active`	`bool`	Indicates whether or not this is the active host. The system has one active host which handles all Bluetooth procedures.
5	`local_name`	`fuchsia.bluetooth/DeviceName`	The local name of this host. This is the name that is visible to other devices when this host is in the discoverable mode.
6	`discoverable`	`bool`	Whether or not the local adapter is currently discoverable over BR/EDR and LE physical channels.
7	`discovering`	`bool`	Whether or not device discovery is currently being performed.
8	`addresses`	`vector<fuchsia.bluetooth/Address>`	The addresses (LE and/or BR/EDR) associated with the host. The Public address is always reported first. This field is always present. Added: 11

Identity

Represents the persistent configuration of a single host-subsystem instance. This is used for identity presentation (inquiry, inquiry response, and advertisement) and for bonding secrets recall (encrypting link data to peers associated with this identity).

Each BR/EDR BD_ADDR and Low Energy public identity address used to bond should have its own Identity instance containing corresponding peers.

Each Identity instance that supports LE privacy should have an Identity Resolving Key (IRK) that is consistent with that distributed to its bonded peers.

Ordinal	Field	Type	Description
1	`host`	`HostData`
2	`bonds`	`vector<BondingData>`	All bonds that use a public identity address must contain the same local address.

LeBondData

Ordinal	Field	Type	Description
1	`connection_parameters`	`LeConnectionParameters`	The peer's preferred connection parameters, if known.
2	`services`	`vector<fuchsia.bluetooth/Uuid>[65535]`	Known GATT service UUIDs.
3	`irk`	`PeerKey`	Identity Resolving RemoteKey used to generate and resolve random addresses.
4	`csrk`	`PeerKey`	Connection Signature Resolving RemoteKey used for data signing without encryption.
5	`peer_ltk`	`Ltk`	LE long-term key used to encrypt a connection when the peer is in the LE Peripheral role. In legacy pairing (`peer_ltk.security.secure_connections` is false), this key corresponds to the key distributed by the peer. In Secure Connections pairing there is only one LTK and `peer_ltk` is the same as `local_ltk`.
6	`local_ltk`	`Ltk`	LE long-term key used to encrypt a connection when the peer is in the LE Central role. In legacy pairing (`local_ltk.security.secure_connections` is false), this key corresponds to the key distributed by the local device. In Secure Connections pairing there is only one LTK and `local_ltk` is the same as `peer_ltk`.

PairingDelegate2StartRequestRequest resource

Ordinal	Field	Type	Description
1	`peer`	`Peer`	Peer making the request.
2	`info`	`PairingProperties`	Properties of the pairing.
3	`request`	`PairingRequest`	Protocol used to complete the pairing process.

PairingOptions

Defined in fuchsia.bluetooth.sys/pairing_options.fidl

Parameters that give a caller more fine-grained control over the pairing process. All of the fields of this table are optional and pairing can still succeed if none of them are set.

Ordinal Field Type Description

1

le_security_level

PairingSecurityLevel

Only relevant for LE. If present, determines the Security Manager security level to pair with. If not present, interpreted as PairingSecurityLevel.AUTHENTICATED.

2

bondable_mode

BondableMode

If transport is LOW_ENERGY or DUAL_MODE, whether the device should form a bond or not during pairing. If not present, interpreted as bondable mode.

If transport is CLASSIC, this option must be absent or otherwise the value BONDABLE. NON_BONDABLE mode is not currently supported for the CLASSIC transport

3

transport

TechnologyType

If transport is LOW_ENERGY, indicate a desire to pair over the LE transport. If transport is CLASSIC, indicate a desire to pair over the Br/Edr transport. If transport is DUAL_MODE, indicate a desire to pair over both transports. If not present, interpreted as TechnologyType.DUAL_MODE

PairingRequestAcceptRequest

Ordinal	Field	Type	Description
1	`entered_passkey`	`uint32`

Peer

Defined in fuchsia.bluetooth.sys/peer.fidl

Represents a remote BR/EDR, LE, or dual-mode BR/EDR/LE peer.

Ordinal	Field	Type	Description
1	`id`	`fuchsia.bluetooth/PeerId`	Uniquely identifies this peer on the current system. This field is always present.
2	`address`	`fuchsia.bluetooth/Address`	Bluetooth device address that identifies this peer. Clients should display this field to the user when `name` is not available. This field is always present. NOTE: Clients should use the `identifier` field to keep track of peers instead of their address.
3	`technology`	`TechnologyType`	The Bluetooth technologies that are supported by this peer. This field is always present.
4	`connected`	`bool`	Whether or not a BR/EDR and/or LE connection exists to this peer. This field is always present.
5	`bonded`	`bool`	Whether or not this peer is bonded. This field is always present.
6	`name`	`fuchsia.bluetooth/DeviceName`	The name of the peer, if known.
7	`appearance`	`fuchsia.bluetooth/Appearance`	The LE appearance property. Present if this peer supports LE and the appearance information was obtained over advertising and/or GATT.
8	`device_class`	`fuchsia.bluetooth/DeviceClass`	The class of device for this device, if known.
9	`rssi`	`int8`	The most recently obtained advertising signal strength for this peer. Present if known.
10	`tx_power`	`int8`	The most recently obtained transmission power for this peer. Present if known.
11	`services`	`vector<fuchsia.bluetooth/Uuid>[65535]`	The list of service UUIDs known to be available on this peer. This is a legacy field that should not be depended on for new code. DEPRECATED
12	`le_services`	`vector<fuchsia.bluetooth/Uuid>[65535]`	The list of service UUIDs known to be available on the LE transport. Never present if technology is CLASSIC.
13	`bredr_services`	`vector<fuchsia.bluetooth/Uuid>[65535]`	The cached list of service UUIDs previously discovered on the BR/EDR transport. Services are not removed if peer is disconnected if subsequent searches don't find them. Never present if technology is LOW_ENERGY. This is a legacy field that should not be depended on for new code. DEPRECATED

Settings

Defined in fuchsia.bluetooth.sys/configuration.fidl

Represents the Bluetooth Host Subsystem parameters available for configuration. Each parameter is set to a default upon Bluetooth system initialization. The default values for each parameter can be found in //src/connectivity/bluetooth/core/bt-gap/config/default.js.

Ordinal	Field	Type	Description
1	`le_privacy`	`bool`	If true then enable the LE Privacy feature, if false disable it. If not present, leaves the current value unchanged. When enabled, all BLE procedures that broadcast the local device address (active scanning, connection initiation, and advertising) use a Resolvable Private Address type. When disabled, these procedures reveal the local public identity address assigned to the controller. Enabling this feature is highly recommended on products.
2	`le_background_scan`	`bool`	If true then enable LE background-scan feature, if false disable it. If not present, leaves the current value unchanged. When enabled, the system maintains an on-going passive scan and establishes connections to bonded peers that are in "Connectable" or "Directed Connectable" mode.
3	`bredr_connectable_mode`	`bool`	If true then enable BR/EDR connectable mode, if false disable it. If not present, leaves the current value unchanged. When enabled, bt-host devices are put into BR/EDR page scan mode and accept connections.
4	`le_security_mode`	`LeSecurityMode`	If present then sets the LE Security mode of the Host Subsystem, if not present leaves the current value unchanged. See BT Core Spec v5.2 Vol. 3 Part C 10.2 for more details. If present and set to Secure Connections Only mode, any active connections not meeting the requirements of Secure Connections Only mode are disconnected.
5	`bredr_security_mode`	`BrEdrSecurityMode`	If present then sets the BR/EDR Security mode of the Host Subsystem, if not present leaves the current value unchanged. See BT Core Spec v5.2 Vol. 3 Part C 5.2.2 for more details. If present and set to Secure Connections Only mode, any active connections not meeting the requirements of Secure Connections Only mode are disconnected. Added: 14

UNIONS

Access_Connect_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Access_Connect_Response`
2	`err`	`Error`

Access_Disconnect_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Access_Disconnect_Response`
2	`err`	`Error`

Access_Forget_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Access_Forget_Response`
2	`err`	`Error`

Access_MakeDiscoverable_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Access_MakeDiscoverable_Response`
2	`err`	`Error`

Access_Pair_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Access_Pair_Response`
2	`err`	`Error`

Access_StartDiscovery_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Access_StartDiscovery_Response`
2	`err`	`Error`

Bootstrap_Commit_Result strict

Ordinal	Variant	Type	Description
1	`response`	`Bootstrap_Commit_Response`
2	`err`	`BootstrapError`

HostWatcher_SetActive_Result strict

Defined in fuchsia.bluetooth.sys/host_watcher.fidl

Ordinal	Variant	Type	Description
1	`response`	`HostWatcher_SetActive_Response`
2	`err`	`zx/Status`

PairingProperties flexible