fix: stop changing phone's Bluetooth device name during BLE advertising by torlando-tech · Pull Request #630 · torlando-tech/columba

torlando-tech · 2026-03-08T17:19:34Z

BleAdvertiser was temporarily setting bluetoothAdapter.name to
"RNS-{identity}" before each advertising start and refresh, then
restoring it after a 1-second delay. This caused the phone's visible
Bluetooth device name to change, which was unexpected and disruptive.

Remove all bluetoothAdapter.name assignments and set
setIncludeDeviceName(false) in the scan response. Device discovery
relies on the service UUID in the advertise data, not the device name.

https://claude.ai/code/session_018JqnJit5nfabGBysYU8QZ6

BleAdvertiser was temporarily setting bluetoothAdapter.name to "RNS-{identity}" before each advertising start and refresh, then restoring it after a 1-second delay. This caused the phone's visible Bluetooth device name to change, which was unexpected and disruptive. Remove all bluetoothAdapter.name assignments and set setIncludeDeviceName(false) in the scan response. Device discovery relies on the service UUID in the advertise data, not the device name. https://claude.ai/code/session_018JqnJit5nfabGBysYU8QZ6

greptile-apps · 2026-03-08T17:21:50Z

Greptile Summary

This PR fixes an unintended side-effect in BleAdvertiser where the phone's visible Bluetooth device name was being temporarily changed to "RNS-{identity}" before every advertising start and refresh cycle, then restored after a 1-second delay.

Key changes:

Removes all bluetoothAdapter.name write assignments (and their 1-second restore coroutines) in both startAdvertising and startAdvertisingInternal.
Changes setIncludeDeviceName(false) in the scan response data in both advertising paths, so the system never broadcasts the local Bluetooth name.
Renames intent of actualDeviceName/deviceName to a logging-only label in comments and KDoc.
The transport identity is still computed and used as the logging label; actual device discovery continues to work via the advertised Reticulum service UUID.

Confidence Score: 4/5

This PR is safe to merge; it removes a disruptive side-effect with no impact on the discovery or connection protocol.
The change is small, well-scoped, and the fix is correct — device discovery was already based on the service UUID, so removing the name from the advertisement payload has no functional impact. The only minor issues are two stale comments left behind that were not updated alongside the new behaviour.
No files require special attention beyond the two stale comments flagged in BleAdvertiser.kt.

Important Files Changed

Filename	Overview
reticulum/src/main/java/com/lxmf/messenger/reticulum/ble/server/BleAdvertiser.kt	Removes all `bluetoothAdapter.name` mutations and sets `setIncludeDeviceName(false)` in the scan response for both `startAdvertising` and `startAdvertisingInternal`. The fix is clean and correct; two pre-existing comments (the `setTransportIdentity` KDoc and the "Move device name to scan response" inline comment) were not updated to reflect the new behaviour.

Sequence Diagram

sequenceDiagram
    participant App as BleAdvertiser
    participant BTA as BluetoothAdapter
    participant BLEA as BluetoothLeAdvertiser
    participant Central as Remote Device

    Note over App,Central: Before this PR (removed behaviour)
    App->>BTA: name = "RNS-{identity}"
    App->>BLEA: startAdvertising(scanResponse: includeDeviceName=true)
    App-->>BTA: restore original name (after 1 s delay)

    Note over App,Central: After this PR (new behaviour)
    App->>BLEA: startAdvertising(advertiseData: serviceUUID only,<br/>scanResponse: includeDeviceName=false)
    Central->>BLEA: scan / connect (discovers via service UUID)
    Note over App: actualDeviceName used for logging only

Comments Outside Diff (2)

reticulum/src/main/java/com/lxmf/messenger/reticulum/ble/server/BleAdvertiser.kt, line 139-145 (link)

Stale KDoc on setTransportIdentity

The KDoc still says "The device will advertise as 'RNS-{32-hex-identity}' when identity is set", but this PR deliberately removes the device name from the BLE advertisement payload. The identity hash is now used only to build the actualDeviceName string for internal logging. The doc should be updated to reflect this so it doesn't mislead future readers.
reticulum/src/main/java/com/lxmf/messenger/reticulum/ble/server/BleAdvertiser.kt, line 232-234 (link)

Stale inline comment about device name placement

The comments still read "Move device name to scan response to fit within 31-byte advertising payload limit / With 128-bit service UUID (19 bytes) + flags (3 bytes) = 22 bytes, no room for name", but this PR stops including the device name in the scan response altogether. The rationale comment is now incorrect and contradicts the updated scan-response comment a few lines down.

_{Last reviewed commit: 7de495c}

…oval Update KDoc and inline comments that still referenced the old behavior of temporarily changing the phone's Bluetooth adapter name for BLE advertising. The code was already fixed but three comments were left behind referencing identity-based naming, payload constraints, and "name moved to scan response". https://claude.ai/code/session_018JqnJit5nfabGBysYU8QZ6

torlando-tech · 2026-03-08T17:28:46Z

@greptileai

sentry · 2026-03-08T17:30:16Z

reticulum/src/main/java/com/lxmf/messenger/reticulum/ble/server/BleAdvertiser.kt

+                // Do not include device name to avoid changing the phone's Bluetooth name.
+                // Devices discover us via the service UUID in the advertise data.
                val scanResponseData =
                    AdvertiseData


Bug: The change removes the identity-based device name from BLE advertisements. The shouldSkipDiscoveredDevice function now fails to find the "RNS-" prefix, breaking the deduplication logic.
_{Severity: HIGH}

Suggested Fix

Re-introduce a mechanism to broadcast the identity-based device name. This could involve restoring the logic that temporarily sets bluetoothAdapter.name before advertising, or finding an alternative way to include the identity in the advertisement or scan response data so that the shouldSkipDiscoveredDevice function can correctly parse it.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: reticulum/src/main/java/com/lxmf/messenger/reticulum/ble/server/BleAdvertiser.kt#L247 Potential issue: The PR removes the code that sets the `bluetoothAdapter.name` to an identity-based string like `"RNS-{identity}"` and also stops including the device name in the BLE advertisement packet. The scanner's fallback to `device.name` will now retrieve the phone's system Bluetooth name, which lacks the expected `"RNS-"` or `"Reticulum-"` prefix. Consequently, the `shouldSkipDiscoveredDevice` function will always return `false`, effectively disabling the deduplication cooldown mechanism. This could lead to reconnection loops with recently discovered devices.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

After removing the bluetoothAdapter.name assignment, the deviceName parameter in startAdvertisingInternal() became unused, which triggers detekt's UnusedPrivateMember rule. Remove the parameter and the now-unused local variable in refreshAdvertising(). https://claude.ai/code/session_018JqnJit5nfabGBysYU8QZ6

sentry · 2026-03-08T17:36:33Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

PR #630 stopped advertising device names in BLE scan responses. This made shouldSkipDiscoveredDevice() always return false since it relied on matching "RNS-"/"Reticulum-" prefixes in advertised names. The GATT-layer identity dedup remains intact. Removed: - shouldSkipDiscoveredDevice() and its scanner callback wrapper - recentlyDeduplicatedIdentities map + deduplicationCooldownMs - BleAdvertiser.setTransportIdentity() + transportIdentityHash - IDENTITY_BYTES_IN_ADVERTISED_NAME constant - 15 dead tests and 6 dead test helpers - Stale detekt baseline entry and docs references Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…edup-code Remove dead name-based dedup code after PR #630

PR torlando-tech#630 stopped advertising device names in BLE scan responses. This made shouldSkipDiscoveredDevice() always return false since it relied on matching "RNS-"/"Reticulum-" prefixes in advertised names. The GATT-layer identity dedup remains intact. Removed: - shouldSkipDiscoveredDevice() and its scanner callback wrapper - recentlyDeduplicatedIdentities map + deduplicationCooldownMs - BleAdvertiser.setTransportIdentity() + transportIdentityHash - IDENTITY_BYTES_IN_ADVERTISED_NAME constant - 15 dead tests and 6 dead test helpers - Stale detekt baseline entry and docs references Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

sentry bot reviewed Mar 8, 2026

View reviewed changes

torlando-tech merged commit 610cf1f into main Mar 9, 2026
22 of 24 checks passed

torlando-tech mentioned this pull request Mar 9, 2026

Remove dead name-based dedup code after PR #630 #633

Merged

4 tasks

torlando-tech added a commit that referenced this pull request Mar 9, 2026

Merge pull request #633 from torlando-tech/cleanup/remove-dead-name-d…

118c091

…edup-code Remove dead name-based dedup code after PR #630

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: stop changing phone's Bluetooth device name during BLE advertising#630

fix: stop changing phone's Bluetooth device name during BLE advertising#630
torlando-tech merged 3 commits intomainfrom
claude/remove-device-name-change-Lpp7y

torlando-tech commented Mar 8, 2026

Uh oh!

greptile-apps bot commented Mar 8, 2026 •

edited

Loading

Comments Outside Diff (2)

Uh oh!

torlando-tech commented Mar 8, 2026

Uh oh!

sentry bot Mar 8, 2026

Uh oh!

sentry bot commented Mar 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

torlando-tech commented Mar 8, 2026

Uh oh!

greptile-apps bot commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Sequence Diagram

Comments Outside Diff (2)

Uh oh!

torlando-tech commented Mar 8, 2026

Uh oh!

sentry bot Mar 8, 2026

Choose a reason for hiding this comment

Uh oh!

sentry bot commented Mar 8, 2026

Codecov Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

greptile-apps bot commented Mar 8, 2026 •

edited

Loading