accessibility label for the leading icon. Defaults to null because the visible text usually describes the action; override when the icon carries information the text does not.
diff --git a/api/core/testing/org.meshtastic.core.testing/-robolectric-ble-bonding/index.html b/api/core/testing/org.meshtastic.core.testing/-robolectric-ble-bonding/index.html index 05a39fafc3..465f6f34cd 100644 --- a/api/core/testing/org.meshtastic.core.testing/-robolectric-ble-bonding/index.html +++ b/api/core/testing/org.meshtastic.core.testing/-robolectric-ble-bonding/index.html @@ -95,7 +95,7 @@
Reusable Robolectric helpers for driving Android Bluetooth bonding logic in androidHostTest source sets.
These let a unit test exercise the real AndroidBluetoothRepository.bond() (and any future BLE bonding code) without an emulator and without a production seam. They rely on two Robolectric behaviors (verified against Robolectric 4.16.x):
android.bluetooth.BluetoothAdapter.getRemoteDevice caches the returned BluetoothDevice by address in a static map, so the shadow configured here is the same instance production code reads when it calls getRemoteDevice(mac) internally.
ShadowBluetoothDevice.createBond calls checkForBluetoothConnectPermission() first, so tests must call grantBluetoothConnectPermission or createBond() throws SecurityException instead of returning a value.
Isolation note: because the device cache is static and survives across tests in the same JVM, give each test a distinct MAC so bond-state cannot bleed between tests.
Reusable Robolectric helpers for driving Android Bluetooth bonding logic in androidHostTest source sets.
These let a unit test exercise the real AndroidBluetoothRepository.bond() (and any future BLE bonding code) without an emulator and without a production seam. They rely on two Robolectric behaviors (verified against Robolectric 4.16.x):
android.bluetooth.BluetoothAdapter.getRemoteDevice caches the returned BluetoothDevice by address in a static map, so the shadow configured here is the same instance production code reads when it calls getRemoteDevice(mac) internally.
ShadowBluetoothDevice.createBond calls checkForBluetoothConnectPermission() first, so tests must call grantBluetoothConnectPermission or createBond() throws SecurityException instead of returning a value.
Isolation note: because the device cache is static and survives across tests in the same JVM, give each test a distinct MAC so bond-state cannot bleed between tests.
Shared "icon + label" button used throughout the Connections screen. Centralises M3 sizing conventions (ButtonDefaults.IconSize, ButtonDefaults.IconSpacing, and the variant-appropriate *WithIconContentPadding) so every scan / add / empty-state affordance renders identically.
accessibility label for the leading icon. Defaults to null because the visible text usually describes the action; override when the icon carries information the text does not.
Shared "icon + label" button used throughout the Connections screen. Centralises M3 sizing conventions (ButtonDefaults.IconSize, ButtonDefaults.IconSpacing, and the variant-appropriate *WithIconContentPadding) so every scan / add / empty-state affordance renders identically.
accessibility label for the leading icon. Defaults to null because the visible text usually describes the action; override when the icon carries information the text does not.
Each ⇊ line between two nodes is one relay hop, and the SNR on that line is the quality of that segment alone. The app colors it against the demodulation floor of the preset in use, not a fixed number: green above the floor, yellow within 5.5 dB below it, orange within 7.5 dB, and red beyond that. The floor is −7.5 dB on Short Fast and improves 2.5 dB per spreading-factor step, so it is −17.5 dB on Long Fast — the same SNR reads differently on different presets. See Signal Meter. A request that also gets a reply adds a second block under Route traced back to us:.
| What to look for | What it means |
|---|---|
| All hops show Good SNR (green) | Healthy path — messages flow reliably |
| One hop shows a poor SNR (orange or red) | Weak link — this relay segment is fragile |
| Many hops (4+) | Long path — consider repositioning a node to shorten it |
| Different path on retry | Mesh is adapting — multiple routes exist (this is good!) |
💡 Tip: Run traceroute several times over a few minutes. If the path changes, your mesh has redundant routes — a sign of a well-connected network.
The Neighbor Info module lets each node broadcast a list of the nodes it can directly hear (single-hop). When multiple nodes share their neighbor lists, you can piece together a topology map of the entire mesh.
Once enabled and transmitting over LoRa, your node periodically broadcasts its neighbor list. Other nodes with Neighbor Info enabled do the same.
ℹ️ Note: Neighbor Info increases airtime usage because every enabled node periodically broadcasts its neighbor list. The firmware doesn’t accept an interval shorter than 14400 seconds (4 hours) for this reason; on busy meshes, leave it at the 21600-second default or raise it further.
The node list itself is a powerful discovery tool when you use its filtering and sorting features effectively.
See Nodes for full details on filtering and sorting options.