bluetooth: GAP Device Name and Apperance write callbacks

[rkel]

Is your feature request related to a problem? Please describe.

Zephyr Bluetooth stack supports GAP Name and Appearance to be writable. Currently this parameters can be changed without any possibility for the application to know about the change. Application may want to update advertising data when this happen or do anything else (like update the displayed name).

Describe the solution you'd like

Implementation similar to bt_conn_cb with its BT_CONN_CB_DEFINE macro. Lets add BT_CONN_GAP_CB_DEFINE that would hold name_updated_cb and appearance_updated_cb.

Describe alternatives you've considered

Would it make more sense to add the callbacks to bt_conn_cb?

[Thalley]

I don't think it makes sense to add to the bt_conn_cb, as those callbacks are usually connection specific, where the device name is a local value change.

When the name is dynamic, it's being handled by GATT. If we implement a callback not sure if it should have the bt_gatt or a bt_gap prefix.

Arguably we could also have a callback for the write request itself, so that application(s) can also reject changes (e.g. if it's in the middle of a procedure where the device name matters for some reason).

[rkel]

No problem with adding callbacks to check the name/appearance before committing.
When it comes to prefix used I am softly towards using bt_gap, but it is not a strong opinion.

[rkel]

@Thalley, @cvinayak -> I am looking into the Bluetooth specification and from what I can see the Name property in GAP does not support notification? It would make sense to notify the value change here, but from what I can see we cannot expect it to work, right?

[Thalley]

@Thalley, @cvinayak -> I am looking into the Bluetooth specification and from what I can see the Name property in GAP does not support notification? It would make sense to notify the value change here, but from what I can see we cannot expect it to work, right?

That's correct, the Core spec does not define the characteristic as being notifiable, so we can only notify the local application if it changes.

I wonder what would happen if Zephyr added support for notification anyways, and if that would break some remote devices or not.

[rkel]

@Thalley This is tempting to implement such an experimental feature. I don't see any good reason it might break the communication. And this would allow to solve easily some issues I have right now with the device I am creating. But the real question is if such device might fail the certification process.
I was testing a few approaches to allow the update of the device name displayed by the Android system:

• Setting the name in AD - it updates only when pairing new device
• Setting the name in SD - it updates only when pairing new device
• Setting the name in Ext ADV - it updates only when pairing new device

My goal is to update the device name and with the new name it should appear while pairing but also it should update in the application. Best even before connecting. Little worse - just after connection and while being connected.

The only fully Bluetooth compatible solution seems to be to implement our own characteristic that would notify about device name / appearance change. Then the App is required to set the local name of the device. Or just send the name always in AD and rest of data in SD.

Nevertheless I still need notify the App about the name change.

[Thalley]

is if such device might fail the certification process.

I have seen PTS fail tests if characteristics has other properties than what they expect, so this is quite likely. The "proper" approach would be to raise an erratum to optionally allow notifications or indications for the characteristic, but that will take quite a while to get through, if at all.

I was testing a few approaches to allow the update of the device name displayed by the Android system:

Does Android even read the Device Name characteristic, or does it only use the advertised values?
i.e. if you advertise with "DEVICE_NAME_1" and the GATT characteristic is "DEVICE_NAME_2", what is shown by Android?

Nevertheless I still need notify the App about the name change.

Yub, this make sense regardless :)