bluetooth: Fix the issue where disabling does not disconnect the AVRC…#457
bluetooth: Fix the issue where disabling does not disconnect the AVRC…#457jialu522 wants to merge 1 commit intoopen-vela:devfrom
Conversation
jialu522
requested review from
chengkai15,
gzh-terry,
huangyulong3,
hyson710,
zhangyuan376 and
zhongzhijie1
as code owners
…P target (tg) connection. bug: v/85747 Fix connection manager disconnection logic: Only AVRCP Controller (CT) instances register explicit disconnect callbacks with the connection manager, while AVRCP Target (TG) connections are not proactively terminated during disable operations, leading to stale connection states and potential resource leaks. Signed-off-by: jialu <jialu@xiaomi.com>
There was a problem hiding this comment.
Pull request overview
This PR addresses a Bluetooth AVRCP issue where disabling Bluetooth does not properly tear down the AVRCP Target (TG) connection, by ensuring the TG role is integrated with the connection manager’s disconnect sequencing.
Changes:
- Replaces the CT-only disconnect handler with a shared AVRCP disconnect handler (
bt_sal_avrcp_disconnect). - Registers the AVRCP TG profile with the connection manager on connect so it can be disconnected during adapter disable.
- Adds TG-side connection-manager “connected/disconnected” callbacks to mirror existing CT behavior.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| bt_sal_cm_profile_connected_callback(&avrcp_info->bd_addr, PROFILE_AVRCP_TG, CONN_ID_DEFAULT); | ||
| bt_sal_profile_disconnect_register(&avrcp_info->bd_addr, PROFILE_AVRCP_TG, CONN_ID_DEFAULT, PRIMARY_ADAPTER, bt_sal_avrcp_disconnect, NULL); |
There was a problem hiding this comment.
The connection-manager integration for TG connect/disconnect is wrapped in #ifdef CONFIG_BLUETOOTH_AVRCP_TARGET. However, BLUETOOTH_AVRCP_ABSOLUTE_VOLUME can be enabled without BLUETOOTH_AVRCP_TARGET (see root Kconfig), and this file still registers TG callbacks in that configuration. In that case the TG connection will still not be registered for disconnect handling, so disabling Bluetooth may continue to leave the TG connection up. Consider widening the preprocessor guard to include CONFIG_BLUETOOTH_AVRCP_ABSOLUTE_VOLUME (or moving these CM calls outside the TARGET-only guard) so any configuration that brings up a TG link registers/unregisters it with the connection manager.
|
|
||
| bt_sal_cm_profile_disconnected_callback(&avrcp_info->bd_addr, PROFILE_AVRCP_TG, CONN_ID_DEFAULT); | ||
| #endif |
There was a problem hiding this comment.
Same conditional-compilation issue on the disconnect side: bt_sal_cm_profile_disconnected_callback() is only called when CONFIG_BLUETOOTH_AVRCP_TARGET is set, but TG connections can exist when only CONFIG_BLUETOOTH_AVRCP_ABSOLUTE_VOLUME is enabled. If the TG disconnect isn’t reported to the connection manager, its disconnect handler node may remain registered and can interfere with later disconnect sequencing.
| bt_sal_cm_profile_disconnected_callback(&avrcp_info->bd_addr, PROFILE_AVRCP_TG, CONN_ID_DEFAULT); | |
| #endif | |
| #endif | |
| bt_sal_cm_profile_disconnected_callback(&avrcp_info->bd_addr, PROFILE_AVRCP_TG, CONN_ID_DEFAULT); |
3 participants
…P target (tg) connection.
bug: v/85747