Right now it properly uses API from bsp/bsp-bluetooth and BlueKitchen stack.
It's meant to provide interface layer for service-bluetooth like that:
os calls <=> service-bluetooth <=> module-bluetooth <=> bluetooth library <=> bsp/bluetooth
Bluetooth
interface
code - for other modules to useprofiles
- implementation of Bluetooth profiles
glucode
code needed for libraries to work
lib
Libraries used with as little modifications as possible
A2DP
HSP
HFP
(Currently not supported)
NOTE: Remote devices that do not support at least one of above profiles will not be added to list of devices during scan process.
The Bluetooth settings related data flow is directed by three main entities:
ServiceDB
that is responsible for storing data in DBServiceBluetooth
that is responsible for general Bluetooth management, and communication between ServiceDB and ApplicationSettingsApplicationSettings
that is responsible forPurePhone<->User
interactions in this context
ServiceBluetooth
communicates with ServiceDB
via SettingsAgent
, and uses BluetoothMessages
for communication with ApplicationSettings
.
It contains BluetoothSettings
object for caching settings received from ServiceDB
and ApplicationSettings
.
ServiceBluetooth
uses BluetoothWorker
to control bluetooth stack.
When ServiceBluetooth
is being created, it registers on a value change in DB for each variable related to BluetoothSettings and binds callback functions for them.
When DB responds with new values of BluetoothSettiings - related variables, callback function of each variable stores its value in cache object (BluetoothSettings) in ServiceBluetooth
, then unregisters from changes in DB.
When all variables are loaded from DB, then BluetoothWorker reloads Bluetooth stack with data from BluetoothSettings object.
Flowchart below is an example of scenario, when user opens BluetoothWindow, and tries to change some of settings presented there.