Bluetooth Profiles

A Bluetooth connection can be initiated either by the vehicle's head unit or by a mobile device. For each requested connection, you must select a Bluetooth profile based on which operations you want to perform.

After the connection has been established, the system creates PPS objects that io-bluetooth uses to manage the connection according to the permissions and other parameters in the selected profile.

The QNX CAR platform currently supports these profiles:

Profile architecture

The following diagram shows the components involved with the operation of the HFP, PBAP, and MAP profiles. Each of these profiles has a control object to accept commands from HMI apps as well as a status object to report command results and the state of the Bluetooth service. The profiles run within io-bluetooth, which subscribes to the control objects and publishes to the status and notification objects. Only the MAP profile uses a notification object, which stores information on messages received.

The PBAP and MAP profiles modify information in their QDB databases, which the HMI can read. Here, the term modify refers to the SQL operations of CREATE, INSERT, UPDATE, and DELETE.

Figure 1. The components involved with the operation of the HFP, PBAP, and MAP profiles
Note: The SPP and AVRCP profiles don't follow the same design of using separate PPS objects for accepting commands and for reporting their outcomes. Apps that need to stream data over SPP may choose to use PPS. For example, the pps-spp service, which supports HTML5 applications that need to access Bluetooth SPP data, uses the /pps/services/bluetooth/spp/spp object. AVRCP is controlled through a C API and doesn't directly use PPS objects. See the descriptions of these two profiles for information on how they interact with other components.