[ryanbr]

What #1638 answered, and what it left

The CLIENT_HELLO instrumentation resolved the first question immediately. On a WHOOP 5/MG, every attempt is the same failure:

CLIENT_HELLO outcome: NO write callback after 3153ms …
CLIENT_HELLO outcome: NO write callback after 3158ms …
CLIENT_HELLO outcome: NO write callback after 3160ms …

9 of 9 in a connection bundle, 8 of 8 in a strap log. And the timing is the tell:

n=9   min=3153ms   max=3163ms   mean=3158ms   spread=10ms

A 10 ms spread across nine attempts is a timer, not a link dying of interference. There is no NOOP-side timer at that interval — the only ~3 s constants in the BLE client are RECONNECT_DELAY_MS and RSSI_READ_DELAY_MS, neither of which tears anything down.

Two explanations fit that regularity, and nothing in the log separates them:

1. The confirmed write to an encryption-requiring characteristic triggers OS pairing, which fails or times out and takes the link with it.
2. The write never triggers pairing at all, and the cause lies elsewhere entirely.

The change

NOOP has never observed ACTION_BOND_STATE_CHANGED — there is no such receiver anywhere in the codebase, so the OS transition BOND_NONE → BOND_BONDING → BOND_NONE is invisible to us.

bond state: BOND_NONE -> BOND_BONDING device=FD:… 120ms after CLIENT_HELLO
bond state: BOND_BONDING -> BOND_NONE device=FD:… 3158ms after CLIENT_HELLO — pairing did NOT complete

Seeing that across the window answers the question. Seeing no transition at all answers it the other way, and that absence is just as conclusive — which is why the line has to be equally legible about a transition happening and about one not happening.

Registered and unregistered alongside the existing radio receiver, in the same ContextCompat / RECEIVER_NOT_EXPORTED form and under the same already-registered flag, so the pair cannot drift apart or double-register (the flag's doc now says it covers both).

The elapsed time is measured against the outstanding CLIENT_HELLO and omitted when there is none — a transition from an unrelated pairing must not be timed against a write it has nothing to do with. There is a test for that.

Android-only: CoreBluetooth performs pairing opaquely and exposes no equivalent transition, so there is nothing to twin.

What this replaces, and why

I first proposed deferring commands until the handshake completes, having read → DISABLE_ALARM in the log as a second GATT write landing inside the outstanding CLIENT_HELLO window — in 15 of 16 cycles.

That was wrong. That line is logged at enqueue:

enqueueWrite(PendingWrite(frame, withResponse, cmd))
log("→ ${cmd.name} payload=…")

and drainWriteQueue opens with if (writeInFlight) return. The CLIENT_HELLO holds that flag, so the command is queued and held — the one-outstanding-operation rule was never violated, and the fix I proposed was unnecessary. I had counted a log line as a wire event. Corrected on the issue before building this instead.

One real consequence does follow from the bug: because the ACK never arrives, writeInFlight stays true for the life of the link, so the whole command queue is wedged behind it. That is an effect, not a cause.

Verification

• compileFullDebugKotlin clean; full com.noop.ble suite (438 tests) green.
• 6 tests on the pure line, including the two that matter for reading a capture correctly: a failed pairing must be called out rather than inferred, and a transition with no outstanding hello must carry no elapsed time.
• doc_comment_lint and i18n_audit --ci main clean — gated on, not run alongside the commit.
• No Swift changes, so no app-build dependency.