Bluetooth-Manager: When receiving a 'device_changes' event, we don't have all informations about the device that just connect

Closed for GG RC4 and FF 6.0.4

Changes to 4a-hal-generic are merged

Patchset Ref: https://gerrit.automotivelinux.org/gerrit/#/c/18559/

This patchset adds proper A2DP endpoint connect/disconnect reporting to clients. See README.md changes for full documentation.

But this has the added advantage of reporting actual media endpoints and not AVRCP profile connections.

Yeah, it is totally fine with me if Matt looks at 4a-hal bluetooth plugin code to make it work again.

The plugin is maintain into '4a-hal-generic' repository into 'plugins/lib/bluetooth' directory. Here are some pointers to understand how are used Bluetooth-Manager functionalities/calls into the plugin (for both flounder/master branches) :

• Most of the definitions used to call 'Bluetooth-Manager' is defined in 'hal-bt.h' file (api, verbs, event).

• The plugin starts by calling a verb to check if a bluetooth adapter is connected to the platform in 'CTLP_INIT(plugin, callbacks)' function of 'hal-bt.c' file.

• Then, the plugin registers itself to redirect events from 'Bluetooth-Manager' to 'CTLP_CAPI(events, source, argsJ, queryJ)' function (available in 'hal-bt.c' file). The 'subscribe' call is made in 'CTLP_CAPI(init, source, argsJ, queryJ)'of 'hal-bt.c' file.

• After that, a call to 'Bluetooth-Manager' is made to get initial list of bluetooth devices in 'CTLP_CAPI(init, source, argsJ, queryJ)'of 'hal-bt.c' file.

• All the received bluetooth objects (coming from the initial list, or from received events) are handled by the same functions ('HalBtDataHandleReceivedMutlipleBtDeviceData' and 'HalBtDataHandleReceivedSingleBtDeviceData') in 'hal-bt-data.c'.

• The list of connected compatible bluetooth devices is stored using a linked list of 'struct HalBtDeviceData' structures (defined in 'hal-bt-data.h').

However, I must warn you that the plugin hasn't been updated since the recent changes in 'Bluetooth-Manager', so everything related to 'Bluetooth-Manager' must be updated (verbs names, request form, response parsing, ...). I was working on it but it my development is blocked because I didn't find an event equivalent to the previously provided 'device_updated' event.

I also want to add that I think it will probably faster for you to add an event in 'Bluetooth-Manager'.

Anyway, thanks for the help.

I propose that Matt look at the 4a-hal bluetooth code and work up a solution to get it working again.  Does that sound okay as a path forward?