RDK-61371 : Migrating Ble pairing data to /opt/secure/lib

[tharun-kumarv]

Reason for change: Migrate bluetooth pairing data to /opt/secure
Test Procedure: Do bluetooth regression test

Risks: Medium
Priority: P1

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[Copilot]

Pull request overview

Migrates the Bluetooth manager's persistent storage location from /opt/lib/bluetooth/btmgrPersist.json to /opt/secure/lib/bluetooth/btmgrPersist.json, with a runtime fallback to the legacy path when the old directory still exists. Also tightens the fileName parameter types on the internal readPersistentFile / writeToPersistentFile helpers to const char*.

Changes:

• Header now exposes two path macros (BTRMGR_PERSISTENT_DATA_PATH_OPT_LIB and BTRMGR_PERSISTENT_DATA_PATH_SECURE) instead of a single hard‑coded path.
• A new static helper btrMgr_PI_GetPersistentDataPath() picks the path at runtime based on whether /opt/lib/bluetooth/ exists; BTRMGR_PERSISTENT_DATA_PATH is #undef/#defined to call this helper.
• readPersistentFile and writeToPersistentFile (and their prototypes) now take const char* for the filename argument.

Reviewed changes

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

File	Description
include/persistIf/btrMgr_persistIface.h	Replaces the single non-UNIT_TEST BTRMGR_PERSISTENT_DATA_PATH macro with separate _OPT_LIB and _SECURE macros.
src/persistIf/btrMgr_persistIface.c	Adds runtime path selector, redefines BTRMGR_PERSISTENT_DATA_PATH to call it, and constifies the file‑name parameters of the persistent file helpers.

Comments suppressed due to low confidence (4)

src/persistIf/btrMgr_persistIface.c:60

• The existence check is on the directory /opt/lib/bluetooth/, not on the persistent file btmgrPersist.json itself. If the directory exists but is empty (e.g., the file was removed/migrated externally, or the directory was created but never populated), this function will still return the old path and writeToPersistentFile will create/overwrite the file there, defeating the migration. Checking for the file (BTRMGR_PERSISTENT_DATA_PATH_OPT_LIB) — or, better, picking the secure path whenever the secure file already exists — would be more robust.

    if (access("/opt/lib/bluetooth/", F_OK) == 0) {
        return BTRMGR_PERSISTENT_DATA_PATH_OPT_LIB;
    }

    return BTRMGR_PERSISTENT_DATA_PATH_SECURE;

src/persistIf/btrMgr_persistIface.c:65

• Nothing in this change ensures that /opt/secure/lib/bluetooth/ exists before fopen(fileName, "w") is invoked. On a device that does not yet have this directory, the very first write (when /opt/lib/bluetooth/ is absent) will fail in writeToPersistentFile — and that function only logs the error and returns void, so the failure is silently swallowed by callers like BTRMgr_PI_SetAllProfiles (which still returns success). Consider creating the directory (e.g., mkdir -p equivalent with appropriate permissions) when the secure path is selected, or have packaging/init scripts guarantee its presence.

#ifndef UNIT_TEST
static const char*
btrMgr_PI_GetPersistentDataPath(
    void
) {
    if (access("/opt/lib/bluetooth/", F_OK) == 0) {
        return BTRMGR_PERSISTENT_DATA_PATH_OPT_LIB;
    }

    return BTRMGR_PERSISTENT_DATA_PATH_SECURE;
}

#undef BTRMGR_PERSISTENT_DATA_PATH
#define BTRMGR_PERSISTENT_DATA_PATH btrMgr_PI_GetPersistentDataPath()
#endif

src/persistIf/btrMgr_persistIface.c:64

• BTRMGR_PERSISTENT_DATA_PATH is now a macro that expands to a function call, and it is referenced ~27 times across this file (including multiple times within a single API call, e.g., BTRMgr_PI_SetLEBeaconLimitingStatus invokes it for both read and write). Each invocation issues an access() syscall, which is unnecessary overhead and also opens a small TOCTOU window where the read and the subsequent write within the same operation could resolve to different paths if /opt/lib/bluetooth/ is removed in between. Resolving the path once (e.g., caching the result in a static variable on first call, or initializing it in BTRMgr_PI_Init) would be both faster and consistent.

static const char*
btrMgr_PI_GetPersistentDataPath(
    void
) {
    if (access("/opt/lib/bluetooth/", F_OK) == 0) {
        return BTRMGR_PERSISTENT_DATA_PATH_OPT_LIB;
    }

    return BTRMGR_PERSISTENT_DATA_PATH_SECURE;
}

#undef BTRMGR_PERSISTENT_DATA_PATH
#define BTRMGR_PERSISTENT_DATA_PATH btrMgr_PI_GetPersistentDataPath()

src/persistIf/btrMgr_persistIface.c:64

• The #undef BTRMGR_PERSISTENT_DATA_PATH on line 63 is misleading: in the non-UNIT_TEST branch of the header, only BTRMGR_PERSISTENT_DATA_PATH_OPT_LIB and BTRMGR_PERSISTENT_DATA_PATH_SECURE are defined — BTRMGR_PERSISTENT_DATA_PATH itself is not, so the #undef is a no-op and suggests an interaction with the header that doesn't actually exist. Also, redefining a public header macro inside a .c file with #undef/#define is a fragile pattern: any future translation unit that includes the header expecting BTRMGR_PERSISTENT_DATA_PATH will not find it. Prefer either keeping the macro defined to a path constant in the header and selecting the path explicitly via a helper at each call site, or replacing the macro entirely with a function call in the source.

#undef BTRMGR_PERSISTENT_DATA_PATH
#define BTRMGR_PERSISTENT_DATA_PATH btrMgr_PI_GetPersistentDataPath()

---

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