Bluetooth interface layer
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
Layout
Bluetoothinterfacecode - for other modules to useprofiles- implementation of Bluetooth profiles
glucodecode needed for libraries to work
libLibraries used with as little modifications as possible
Supported profiles
A2DPHSPHFP(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.
Events flowchart
Table of content
Proposal of Bluetooth settings data flow
The Bluetooth settings related data flow is directed by three main entities:
ServiceDBthat is responsible for storing data in DBServiceBluetooththat is responsible for general Bluetooth management, and communication between ServiceDB and ApplicationSettingsApplicationSettingsthat is responsible forPurePhone<->Userinteractions 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.
