RDKEMW-15846 : Elite classic controller is not disconnect on standby by natrajmuthusamy · Pull Request #52 · rdkcentral/bluetooth

natrajmuthusamy · 2026-03-23T10:38:41Z

No description provided.

Reason for change : Sets the operation to modify the device's blocked property, enabling dynamic block/unblock control via this function. Priority: P1 Test Procedure: Follow the steps provided in description Risks: High Signed-off-by:Natraj Muthusamy <Natraj_Muthusamy@comcast.com>

Copilot

Pull request overview

This PR introduces a new API intended to programmatically block/unblock a paired Bluetooth device (likely to address the Elite classic controller behavior around standby).

Changes:

Added btrCore_UpdateDeviceBlockState(...) implementation in src/btrCore.c to set enBTDevPropBlocked.
Exposed the new API in include/btrCore.h with Doxygen documentation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

File	Description
`src/btrCore.c`	Adds a helper to set the “Blocked” device property via `BtrCore_BTSetProp`.
`include/btrCore.h`	Exposes/document the new API in the public header.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-23T10:47:07Z

+/**
+ * @brief  Updates the block state (blocked/unblocked) of a Bluetooth device.
+ *
+ * This API sets the device block state for the specified Bluetooth device using its device ID and type.
+ * It may be used to block or unblock a device from interacting with the Bluetooth core.
+ *
+ * @param[in] pstlhBTRCore      Pointer to the Bluetooth Core handle.
+ * @param[in] aBTRCoreDevId     Device ID of the target Bluetooth device.
+ * @param[in] aenBTRCoreDevType Device type of the target Bluetooth device.
+ * @param[in] isBlocked         Desired block state: 1 to block the device, 0 to unblock it.


This PR adds a new externally visible API, but there are no corresponding unit tests (the repo has extensive coverage in unitTest/test_btrCore.c for other BTRCore_* APIs). Please add tests that cover success/failure paths (e.g., device not found, BTSetProp failure, and block/unblock values).

Copilot · 2026-03-23T10:47:08Z

+enBTRCoreRet btrCore_UpdateDeviceBlockState (
+    tBTRCoreHandle*         pstlhBTRCore,
+    tBTRCoreDevId         aBTRCoreDevId,
+    enBTRCoreDeviceType   aenBTRCoreDevType,
+    int                   isBlocked


This function uses aenBTRCoreDevType in the signature but never references it, which will fail the build under -Wall -Werror due to -Wunused-parameter. Either use it (e.g., via btrCore_GetDeviceInfoKnown(...)) or explicitly mark it unused if it’s intentionally ignored.

Copilot · 2026-03-23T10:47:09Z

+    enBTDeviceType enBTDevice = enBTDevUnknown;
+
+    for (i = 0; i < pstlhBTRCore->numOfPairedDevices; ++i) {
+        if (pstlhBTRCore->stKnownDevicesArr[i].tDeviceId == aBTRCoreDevId) {
+            pDeviceAddress = pstlhBTRCore->stKnownDevicesArr[i].pcDeviceAddress;
+            enBTDevice = pstlhBTRCore->stKnownDevicesArr[i].enDeviceType; 


enBTDevice is declared as enBTDeviceType, but it’s being assigned from stKnownDevicesArr[i].enDeviceType (type enBTRCoreDeviceClass). This mixes unrelated enums and will produce an invalid value for later calls; avoid deriving the BT interface type from the device class here.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-23T10:51:49Z

+enBTRCoreRet btrCore_UpdateDeviceBlockState (
+    tBTRCoreHandle*         hBTRCore,
+    tBTRCoreDevId         aBTRCoreDevId,
+    enBTRCoreDeviceType   aenBTRCoreDevType,
+    int                   isBlocked
+) {
+
+    if (!hBTRCore) {
+        BTRCORELOG_ERROR("Invalid BT Core Handle\n");
+        return enBTRCoreInvalidArg;
+    }
+
+	pstlhBTRCore = (stBTRCoreHdl*)hBTRCore;
+
+    const char *pDeviceAddress = NULL;
+    int i;
+    enBTDeviceType enBTDevice = enBTDevUnknown;
+
+    for (i = 0; i < pstlhBTRCore->numOfPairedDevices; ++i) {
+        if (pstlhBTRCore->stKnownDevicesArr[i].tDeviceId == aBTRCoreDevId) {
+            pDeviceAddress = pstlhBTRCore->stKnownDevicesArr[i].pcDeviceAddress;
+            enBTDevice = pstlhBTRCore->stKnownDevicesArr[i].enDeviceType; 
+            break;
+        }
+    }
+
+    if (!pDeviceAddress) {
+        BTRCORELOG_ERROR("Device ID %lld not found\n", aBTRCoreDevId);
+        return enBTRCoreDeviceNotFound;
+    }
+
+    unBTOpIfceProp lunBtOpDevProp;
+    lunBtOpDevProp.enBtDeviceProp = enBTDevPropBlocked;
+    int BlockDevice = block ? 1 : 0;
+
+    if (BtrCore_BTSetProp(pstlhBTRCore->connHdl, pDeviceAddress, enBTDevice, lunBtOpDevProp, &BlockDevice)) {
+        BTRCORELOG_ERROR("Set Device Property enBTDevPropBlocked - FAILED\n");
+        return enBTRCoreFailure;
+    }
+
+    return enBTRCoreSuccess;
+}


There are existing unit tests for btrCore.c logic in unitTest/test_btrCore.c, but no tests cover this newly introduced device-block/unblock API. Please add unit tests for at least: invalid handle, device-not-found, and successful blocked/unblocked property setting (with BtrCore_BTSetProp mocked).

Copilot · 2026-03-23T10:51:50Z

+    enBTDeviceType enBTDevice = enBTDevUnknown;
+
+    for (i = 0; i < pstlhBTRCore->numOfPairedDevices; ++i) {
+        if (pstlhBTRCore->stKnownDevicesArr[i].tDeviceId == aBTRCoreDevId) {
+            pDeviceAddress = pstlhBTRCore->stKnownDevicesArr[i].pcDeviceAddress;
+            enBTDevice = pstlhBTRCore->stKnownDevicesArr[i].enDeviceType; 
+            break;
+        }
+    }
+
+    if (!pDeviceAddress) {
+        BTRCORELOG_ERROR("Device ID %lld not found\n", aBTRCoreDevId);
+        return enBTRCoreDeviceNotFound;
+    }
+
+    unBTOpIfceProp lunBtOpDevProp;
+    lunBtOpDevProp.enBtDeviceProp = enBTDevPropBlocked;
+    int BlockDevice = block ? 1 : 0;
+
+    if (BtrCore_BTSetProp(pstlhBTRCore->connHdl, pDeviceAddress, enBTDevice, lunBtOpDevProp, &BlockDevice)) {
+        BTRCORELOG_ERROR("Set Device Property enBTDevPropBlocked - FAILED\n");


The third argument to BtrCore_BTSetProp is enBTOpIfceType (e.g., enBTDevice), but this function defines enBTDevice as an enBTDeviceType variable and passes it through. That’s a type/semantic mismatch and will either not compile cleanly or call the API with the wrong enum value. Pass the enBTDevice interface type constant here, and keep the device-type enum separate if needed.

Copilot · 2026-03-23T10:51:50Z

+    int i;
+    enBTDeviceType enBTDevice = enBTDevUnknown;
+
+    for (i = 0; i < pstlhBTRCore->numOfPairedDevices; ++i) {
+        if (pstlhBTRCore->stKnownDevicesArr[i].tDeviceId == aBTRCoreDevId) {
+            pDeviceAddress = pstlhBTRCore->stKnownDevicesArr[i].pcDeviceAddress;
+            enBTDevice = pstlhBTRCore->stKnownDevicesArr[i].enDeviceType; 
+            break;
+        }
+    }
+
+    if (!pDeviceAddress) {
+        BTRCORELOG_ERROR("Device ID %lld not found\n", aBTRCoreDevId);
+        return enBTRCoreDeviceNotFound;
+    }
+


aenBTRCoreDevType is currently unused, and this function manually scans stKnownDevicesArr to find the MAC/type. Elsewhere (e.g., connect/disconnect/unpair) the code uses helpers like btrCore_GetDeviceInfoKnown / btrCore_GetDeviceInfo / btrCore_GetKnownDeviceMac, which also handle the aBTRCoreDevId < BTRCORE_MAX_NUM_BT_DEVICES case and keep the lookup logic consistent. Reuse the existing helper(s) here to avoid divergent device-ID resolution and to make use of the aenBTRCoreDevType parameter (or remove it if it’s not needed).

Suggested change

int i;

enBTDeviceType enBTDevice = enBTDevUnknown;

for (i = 0; i < pstlhBTRCore->numOfPairedDevices; ++i) {

if (pstlhBTRCore->stKnownDevicesArr[i].tDeviceId == aBTRCoreDevId) {

pDeviceAddress = pstlhBTRCore->stKnownDevicesArr[i].pcDeviceAddress;

enBTDevice = pstlhBTRCore->stKnownDevicesArr[i].enDeviceType;

break;

}

}

if (!pDeviceAddress) {

BTRCORELOG_ERROR("Device ID %lld not found\n", aBTRCoreDevId);

return enBTRCoreDeviceNotFound;

}

enBTDeviceType enBTDevice = enBTDevUnknown;

stBTRCoreBTDevice lstBTDeviceInfo;

memset(&lstBTDeviceInfo, 0, sizeof(lstBTDeviceInfo));

/* Use common helper to resolve device ID to address/type, so that

* aBTRCoreDevId and aenBTRCoreDevType are handled consistently with

* other operations (connect/disconnect/unpair, etc.).

*/

if (btrCore_GetDeviceInfo(pstlhBTRCore,

aBTRCoreDevId,

aenBTRCoreDevType,

&lstBTDeviceInfo) != enBTRCoreSuccess) {

BTRCORELOG_ERROR("Device ID %lld not found\n", aBTRCoreDevId);

return enBTRCoreDeviceNotFound;

}

pDeviceAddress = lstBTDeviceInfo.pcDeviceAddress;

enBTDevice = lstBTDeviceInfo.enDeviceType;

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-23T10:57:10Z

+enBTRCoreRet btrCore_UpdateDeviceBlockState (
+    tBTRCoreHandle*         hBTRCore,
+    tBTRCoreDevId         aBTRCoreDevId,
+    enBTRCoreDeviceType   aenBTRCoreDevType,
+    int                   isBlocked
+) {
+
+	stBTRCoreHdl*           pstlhBTRCore = NULL;
+    if (!hBTRCore) {
+        BTRCORELOG_ERROR("Invalid BT Core Handle\n");
+        return enBTRCoreInvalidArg;
+    }
+
+	pstlhBTRCore = (stBTRCoreHdl*)hBTRCore;
+


The new API takes tBTRCoreHandle* (i.e., void**) but the rest of BTRCore public APIs take tBTRCoreHandle (void*). The implementation then casts hBTRCore directly to stBTRCoreHdl*, which will be an invalid pointer if callers pass the handle by value like other APIs. Please change the signature to take tBTRCoreHandle hBTRCore and align the null-handle return code with the existing pattern (enBTRCoreNotInitialized).

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

sync with develop

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

NatrajMuthusamygithubpractice and others added 3 commits March 23, 2026 09:51

Update btrCore.c

2d94910

Update btrCore.h

2e03b61

natrajmuthusamy requested a review from a team as a code owner March 23, 2026 10:38

Copilot AI review requested due to automatic review settings March 23, 2026 10:38

Copilot started reviewing on behalf of natrajmuthusamy March 23, 2026 10:41 View session

natrajmuthusamy added 2 commits March 23, 2026 16:15

Update btrCore.c

b267872

Update btrCore.h

0e9e89a

Copilot AI reviewed Mar 23, 2026

View reviewed changes

Update btrCore.c

36a497d

Copilot AI review requested due to automatic review settings March 23, 2026 10:48

Copilot started reviewing on behalf of natrajmuthusamy March 23, 2026 10:48 View session

Update btrCore.h

abc5d80

Copilot AI reviewed Mar 23, 2026

View reviewed changes

Update btrCore.c

7c25b41

Copilot AI review requested due to automatic review settings March 23, 2026 10:53

Copilot started reviewing on behalf of natrajmuthusamy March 23, 2026 10:54 View session

Copilot AI reviewed Mar 23, 2026

View reviewed changes

Apply suggestion from @Copilot

9d47b90

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings March 23, 2026 15:40

Copilot started reviewing on behalf of natrajmuthusamy March 23, 2026 15:40 View session

natrajmuthusamy and others added 4 commits March 23, 2026 21:11

Apply suggestion from @Copilot

b7f6b66

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Merge pull request #55 from rdkcentral/develop

8857e25

sync with develop

Update btrCore.c

d55b49d

Update btrCore.h

90131d0

Copilot AI reviewed Mar 23, 2026

Uh oh!

Conversation

natrajmuthusamy commented Mar 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants