Skip to content

Breaking: Add bondMode option to ConnectOptions for native BLE#123

Open
microbit-matt-hillsdon wants to merge 1 commit intoappsfrom
review-flow
Open

Breaking: Add bondMode option to ConnectOptions for native BLE#123
microbit-matt-hillsdon wants to merge 1 commit intoappsfrom
review-flow

Conversation

@microbit-matt-hillsdon
Copy link
Contributor

@microbit-matt-hillsdon microbit-matt-hillsdon commented Mar 24, 2026

The native connect() flow previously assumed the caller intended to flash: after a new bond it always reset the device into pairing mode. This is wrong for two other common scenarios:

  1. BLE-enabled firmware, interact with services (sensors, UART, LEDs): The device should end up in application mode, not pairing mode. bondMode: "application" handles this — it still bonds if needed (required to get past the firmware whitelist on first connection) but resets to application mode instead of pairing mode.

  2. Open-link firmware, no bonding needed: bondMode: "none" skips createBond() on Android and the iOS pairing trigger entirely, avoiding an unnecessary pairing dialog and the 15s post-bond firmware reset.

The default for connect() is now "application". flash() explicitly passes bondMode: "pairing" internally, so the flash flow is unchanged.

On web, bondMode is ignored — the browser manages pairing transparently via the OS when accessing encrypted characteristics (well, so Claude claims, we need more practical experience here). But either way we for sure can't trigger it.

The demo app gains a Bond mode selector (native Bluetooth only) to exercise all three modes.

This is breaking for connect then flash scenarios over unknown firmware which now need to pass bondMode: "pairing". Folks who just call flash will be OK.

Fixes #118

The native connect() flow previously assumed the caller intended to
flash: after a new bond it always reset the device into pairing mode.
This is wrong for two other common scenarios:

1. BLE-enabled firmware, interact with services (sensors, UART, LEDs):
   The device should end up in application mode, not pairing mode.
   bondMode: "application" handles this — it still bonds if needed
   (required to get past the firmware whitelist on first connection)
   but resets to application mode instead of pairing mode.

2. Open-link firmware, no bonding needed:
   bondMode: "none" skips createBond() on Android and the iOS pairing
   trigger entirely, avoiding an unnecessary pairing dialog and the
   15s post-bond firmware reset.

The default for connect() is now "application". flash() explicitly
passes bondMode: "pairing" internally, so the flash flow is unchanged.

On web, bondMode is ignored — the browser manages pairing transparently
via the OS when accessing encrypted characteristics.

The demo app gains a Bond mode selector (native Bluetooth only) to
exercise all three modes.

This is breaking for connect then flash scenarios over unknown firmware which
now need to pass bondMode: pairing.

Fixes #118
@microbit-matt-hillsdon
Copy link
Contributor Author

For discussion/experimentation rather than a quick review + merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant