Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions codeless banner

Bluetooth Support


Qt Extended supports Bluetooth communications hardware and software profiles by relying on BlueZ, the official Linux Bluetooth stack. Qt Extended provides implementations of Bluetooth profiles; settings applications for device and profile configuration; and advanced framework classes that enable implementation of custom profiles.

As of Qt Extended 4.4, the built-in Bluetooth profile implementations have been tested with the Profile Tuning Suite (PTS) from the Bluetooth SIG, and are certification-ready.

Hardware Requirements

Qt Extended does not directly support any hardware, instead it relies on the BlueZ Bluetooth stack. Thus for any hardware to be supported by Qt Extended, it must be supported by BlueZ. For more information, please visit the BlueZ website at http://www.bluez.org.

Software Requirements

Qtopia/Qt Extended 4.3 or later requires BlueZ Bluetooth framework Version 3.19. This means both the bluez-libs-3.19 and bluez-utils-3.19 must be installed on your system. For more information about installing BlueZ, please refer to the BlueZ website at http://www.bluez.org.

Note that bluez-utils needs to be compiled with XML support as Qt Extended uses its XML service record description feature. Versions 3.27 and earlier of bluez-utils require the expat or GLib libraries to enable this feature, and later versions use GLib only.

BlueZ uses the DBUS communications protocol to expose a rich and complex API. Qt Extended uses this API to manage Bluetooth devices. Thus Qt Extended requires DBUS to be configured and running in order to successfully communicate with hcid. Qt Extended does not link to the BlueZ libraries, however correct version of the bluez-lib package must be installed as it is used by bluez-utils.

Qt Extended requires:

Qt Extended Configuration

Qt Extended has several configure options which relate to Bluetoth support. These options are documented in the table below:

-bluetoothTurns Bluetooth Support on.

Bluetooth support requires DBUS. Configure uses pkg-config utility to search for the necessary compiler and linker flags. If a useable version of the DBUS library is not found, the DBUS and Bluetooth support will be disabled. Please see the Build system device profile documentation for more details.


It is important to note that Qt Extended make use of a PCM SCO connection since that connection type uses the least amount of power. This means that Qt Extended does not process any audio data related to the Bluetooth connection.

Before using the Qt Extended Bluetooth support it is highly recommended that the BlueZ tools be used to test the Bluetooth connection. As a minimum the follow should be run to check the device adaptor :

    dbus-send --system --dest=org.bluez --type=method_call \
        --print-reply '/org/bluez' org.bluez.Manager.DefaultAdapter'

The result should be something like: string "/org/bluez/hci0"

A Bluetooth connection requires a process called 'pairing' to be completed. This process typically involves


Qt Extended Bluetooth currently supports GAP, SDAP and OPP, DUN, Headset and Handsfree profiles. The GAP and SDAP profiles are implemented largely by the BlueZ hcid and sdpd daemons.

The Headset and Handsfree profiles require that a QAudioStatePlugin be provide that suits the device.

The current BlueZ architecture uses the language-independent DBUS layer to communicate with its clients. Qt Extended uses the Qt DBUS bindings to communicate with the BlueZ hcid daemon. Most notifications from the hcid daemon are exposed through the QBluetoothLocalDevice API.


Device Configuration

Each Bluetooth device or local Bluetooth host adapter has an associated Bluetooth address that is stored as a six byte array and is commonly represented as six hexadecimal bytes separated by colons. For example: FF:FF:FF:FF:FF:FF.

BlueZ and Qt Extended support multiple local Bluetooth host adapters, however the most common case is to use a single adapter.

The local host adapter can be controlled through the QBluetoothLocalDevice class where the adapter can be switched on/off and device visibility can be controlled. Visibility is controlled by two variables:

  1. page scan - controls whether remote devices can connect to the local device.
  2. inquiry scan - controls whether remote devices can discover the local device.

This indicates that the discoverable state is controlled by setting the inquiry scan appropriately.


Qt Extended fully supports Bluetooth GAP which handles the discovery and establishment of connections between Bluetooth devices. GAP defines how secure connections are established between two devices by a mechanism referred to as pairing and also defines the basic user interface paradigm that must be used by all Bluetooth devices.

Qt Extended Bluetooth API allows its clients to discover remote devices and various relevant attributes, such as device name, device manufacturer, Bluetooth protocol version supported, etc. Additionally, establishment of trust relationships by pairing remote devices is also supported.

The functionality used to implement this profile is accessible through the QBluetoothLocalDevice class.


SDAP describes how an application should use the Service Discovery Protocol (SDP) to discover services on a remote device. Using the Qt Extended Bluetooth API, clients can enable any application to discover services running on a remote device.

Two discovery modes are supported:

  1. searching - searching for a specific service or services
  2. browsing - searching for any services accessible from the public browse group.


OBEX is a high-level protocol for the transfer of arbitrary objects between devices. More specific protocols for the transfer of particular types of objects are specified in the form of OBEX "profiles": for example, the File Transfer Profile defines the data format to be used when exchanging directory listings to facilitate directory browsing of remote devices.

Qt Extended includes client and server implementations for various OBEX profiles. Its OBEX libraries also enable the development of clients and servers for other OBEX profiles through QObexClientSession and QObexServerSession.

The third-party OpenOBEX library is used internally for OBEX support.

Object Push Profile (OPP)

Qt Extended includes OPP client and server implementations to allow the user to send and receive files over Bluetooth. If a file is received, the user can monitor the progress of the file transfer, and choose to accept or discard the file received. If a business card is received, the user has the option of saving it in his or her address book or discarding.

The built-in OPP client can also be accessed by developers via IPC, through the BluetoothPushingService.

Developers can also use QObexPushClient and QObexPushService to implement their own OPP clients and servers.

File Transfer Profile (FTP)

Qt Extended includes client and server implementations of the File Transfer Profile. The Bluetooth FTP application enables users to browse other devices and transfer files, and a server implementation is included to allow the user's device to be browsed by other devices.

Developers can also use QObexFtpClient and QObexServerSession to implement their own FTP clients and servers.

Basic Printing Profile (BPP)

Qt Extended includes a simple client implementation for BPP that supports the FilePush operation for the Simple Push Transfer Model. This enables end users to send any type of file to Bluetooth-enabled printers. XHTML-Print support is included.

Developers can use QObexClientSession and QObexServerSession to implement their own BPP clients and servers.

Dial Up Networking Profile (DUN)

Qt Extended supports the Dial-Up Networking profile. Using DUN users can use their Qt Extended based Mobile phone to establish a ppp connection to the ISP supported by their provider. The connection is based on the industry standard PPP protocol. Qt Extended provides both a service and client implementations of the DUN profile, so Qt Extended Phone users can use other phones to establish a DUN connection over Bluetooth as well.

Headset Profile (HSAG)

Qt Extended provides a reference implementation of the Headset Audio Gateway profile. This profile allows the use of Bluetooth devices that support the Headset (HS) profile by Qt Extended based devices. Headset profile is used to provide wireless handsfree audio communication between a headset and a handset.

Qt Extended provides only reference support for the Headset Audio Gateway profile, as frequently such support is hardware and device dependent.

Handsfree Profile (HFAG)

Qt Extended provides a reference implementation of the Handsfree Audio Gateway profile (HFAG) This profile allows the user of Bluetooth devices that support the Handsfree (HF) profile by Qt Extended based devices. Handsfree profile is frequently found in Bluetooth based car hands-free kits, and also in Bluetooth headsets. Handsfree profile is in principle very similar to the Headset profile, but provides many more capabilities, including direct dialing, last number redial, three-way calling, and other more advanced features.

Qt Extended provides only a reference implementation for the the Handsfree Audio Gateway profile. Handsfree profile requires the audio gateway to route all audio to the handsfree device. The profile also requires the audio stream to be able to be switched between several audio devices mid-stream. Such support is frequently device and hardware dependent.

Note: The Handsfree Profile depends on telephony components. Therefore it is only enabled if Qt Extended is built with Telephony support.

Service Management Framework

Qt Extended provides a framework for creating and managing Bluetooth services. A Bluetooth service can be created and registered within this framework by subclassing the QBluetoothAbstractService class. The framework allows registered services to be controlled by external sources through IPC messages. For example, the Qt Extended Bluetooth Settings application allows end users to enable or disable registered services, and also modify the security settings of registered services.

The service management framework stores various settings for each known service in the BluetoothServices.conf configuration file. This configuration file can be modified to provide default settings for registered services. As an example, a default configuration file is provided at etc/default/Trolltech/BluetoothServices.conf. This file sets the default security for the OBEX Object Push Service to 0, as Object Push services do not generally require authentication or encryption.

The service management framework is implemented through the service manager in src/server/bluetoothservicemanager.h.

For more information, see the Bluetooth Service Management Framework page.

Copyright © 2009 Trolltech Trademarks
Qt Extended 4.4.3