You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement proposal related to a problem? Please describe.
Bluetooth Audio can/should be seen as a user of the BT Host and should not depend on any internal APIs or header files.
Additional context
Some of the internal access can be replaced by existing public APIs.
Some of the internal access can be fixed by moving internal APIs to a public API citing LE Audio as a user.
Some of the internal access should perhaps be kept internal like accessing the LTK, but that would prevent 3rd party CSIS implementations.
Access to the BT settings is similarly also a necessity for some services, but perhaps LE Audio should have its own settings and not rely on bt_settings?
The text was updated successfully, but these errors were encountered:
Is your enhancement proposal related to a problem? Please describe.
Bluetooth Audio can/should be seen as a user of the BT Host and should not depend on any internal APIs or header files.
Describe the solution you'd like
bt_conn
directly but usebt_conn_get_info
or others where application (Bluetooth: PACS: Do not use conn struct directly #84993, Bluetooth: Host: Add API functions to determine PAST support for conn #85597)Describe alternatives you've considered
N/A
Additional context
Some of the internal access can be replaced by existing public APIs.
Some of the internal access can be fixed by moving internal APIs to a public API citing LE Audio as a user.
Some of the internal access should perhaps be kept internal like accessing the LTK, but that would prevent 3rd party CSIS implementations.
Access to the BT settings is similarly also a necessity for some services, but perhaps LE Audio should have its own settings and not rely on bt_settings?
The text was updated successfully, but these errors were encountered: