The HandsFreePhone plugin

Overview

The HandsFreePhone event-source plugin represents the Bluetooth HFP phone service. This plugin is responsible for notifying the HNM of incoming phone call events. The plugin generates display events so that subscribing HMI applications will know how to handle incoming handsfree phone calls.

This plugin subscribes to the /pps/services/bluetooth/handsfree/status object, which the Bluetooth Manager uses to publish the results of commands sent to the /pps/services/bluetooth/handsfree/control object. For details on these objects, see their entries in the PPS Objects Reference.

HFP states

The plugin generates display events in response to state changes in the Bluetooth HFP service. When the plugin detects a state change in the HFP status object, one or more events will be generated to open and close display windows appropriately. New events are added to the tail of the queue following HFP state changes.

Although the HFP status object can report several state values (HFP_CALL_ACTIVE, HFP_CALL_ACTIVE_HELD, etc.), the HandsFreePhone plugin considers only a small set of HFP states:
HFP state Plugin behavior
HFP_INITIALIZED

When the HFP system is first initialized, there should be no active call. When the HFP status object gets to this state, a display-end event is issued to ensure that no displays associated with handsfree calls are currently displayed.

Note that the initialized state occurs when a call ends as well as when the system is first initialized. No priority is explicitly assigned to the initialized state—this state issues only display-end requests, which do not depend on priority.

HFP_CONNECTED_IDLE The HFP service is connected and ready for call activity.
HFP_CALL_OUTGOING_DIALING A remote party's number is being dialed.
HFP_CALL_INCOMING

When an incoming call is received, the plugin will issue a display-start event requesting an Overlay window type. The name of the event is simply the state's name (i.e., HFP_CALL_INCOMING). The HMI view responsible for handling the specific display request is the Communication app.

If the incoming call can't be displayed by a popup overlay, then the fallback display type is a growl notification. This growl will require that the user activate the Communication app (e.g., by tapping the growl notification window) to accept or reject the incoming call.

Whether a communication dialog can be displayed depends on the priority of the currently display application and on the priority of the incoming call event. An incoming call event has default priority unless a custom priority is specified in the policy configuration. You can set a custom priority by adding the line HFP_CALL_INCOMING = 0 to the HandsFreePhone module definition in the policy configuration file as shown: 
modules {
    ...
    HandsFreePhone {
        dll = /lib/dll/hpm/event-source-handsfree.so
        event-priorities {
            ...
            HFP_CALL_INCOMING = 0   # Set custom priority
            ...
        }
    }
    ...
}

Callback functions

Since the HandsFreePhone plugin wraps the Bluetooth HFP service's PPS status object, the open() callback must subscribe to this PPS object so that the plugin will be notified of any state changes by the HFP subsystem.

The close() callback closes the PPS object that this plugin subscribes to.

The read_event callback is the mechanism that the HNM uses to get event information from this plugin. If there's a pending event from the Bluetooth HFP service, this callback will return the event data in the specified event buffer.

For more information, see "API Reference" in this guide.

Loading the plugin

The following lines in the modules section of the HNM policy configuration file (policy.cfg) will load the HandsFreePhone plugin. You can adjust the HFP state priorities as mentioned above: 
HandsFreePhone {
			dll = /lib/dll/hmi-notification/event-source-handsfree.so
			event-priorities {
				HFP_INITIALIZED = 0
				HFP_CONNECTED_IDLE = 0
				HFP_CALL_OUTGOING_DIALING = 1
				HFP_CALL_INCOMING = 1
			}