BT: Handle Duplicate SHO request from AVRCP
- Race condition arise out of UI based SHO and
play based SHO can result in duplicate SHO
processing for same device.
- Earlier this condition was handled at A2DP
level.
- With new design, this condition is being
handled ay entry point. So, A2DP is handling
for UI based SHO and AVRCP is handling for
play-based SHO.
CRs-Fixed: 2588019
Change-Id: I5f01c0135aab3011ab1c60fe8ccd092406c9d381
diff --git a/packages_apps_bluetooth_ext/src/avrcp/Avrcp_ext.java b/packages_apps_bluetooth_ext/src/avrcp/Avrcp_ext.java
index 8c8062a..e4b666d 100644
--- a/packages_apps_bluetooth_ext/src/avrcp/Avrcp_ext.java
+++ b/packages_apps_bluetooth_ext/src/avrcp/Avrcp_ext.java
@@ -1657,6 +1657,12 @@
boolean PlayReq = (msg.arg1 == 1);
boolean isRetry = (msg.arg2 == 1);
boolean ret;
+ BluetoothDevice prevActiveDevice = mA2dpService.getActiveDevice();
+ if(Objects.equals(dev, prevActiveDevice)) {
+ isShoActive = false;
+ Log.w(TAG, dev + " device is already active");
+ break;
+ }
ret = mA2dpService.startSHO(dev);
if(!ret) {
isShoActive = false;