ble: experimental LE 2M PHY preference for the offload burst (#533)

[ryanbr]

The finding

NOOP has never called setPreferredPhy — grep finds no PHY handling anywhere in the tree. So every historical offload has run on the 1M PHY, and BLE 5's LE 2M has simply never been asked for. 2M doubles the symbol rate: the same bytes spend half the air-time.

minSdk = 26, which is exactly when setPreferredPhy landed — it's been available the whole time.

Why this is the better-behaved of the two levers

	#536 (connection interval)	this (2M PHY)
Mechanism	~2.7× more radio wakeups	half the air-time per packet
Battery	ambiguous — depends on link- vs firmware-limited	should cost less energy per byte
Stacks with the other	yes	yes

They're orthogonal, so they're deliberately separate toggles: bundling them would make a field report un-attributable, and they have opposite battery profiles — a cost from one could mask a gain from the other.

Design decisions worth calling out

Requested at offload START, not on connect. The connect handshake is fragile: the code explicitly warns that an extra GATT op before requestMtu can make it return false → MTU skipped → the offload capped (#85), plus the OnePlus double-MTU bug (#50). Touching that path to speed up sync could cap the very thing it's speeding up. The burst is where throughput matters anyway, and PHY persists once negotiated.

The mask always includes 1M — never 2M alone. It's a preference; keeping 1M lets the controller fall back rather than cling to a 2M link gone marginal (2M trades range for speed). The strap may decline it outright.

onPhyUpdate logs what was actually negotiated. This is the only way to learn whether WHOOP supports 2M at all, and it lands in the strap log right next to the offload's existing session started/ended + persisted N rows — so one before/after log yields records/sec and the PHY together. Log-only; nothing branches on it.

Battery

Unlike #536, the mechanism here points the right way: same bytes, half the air-time, radio on for less of it. But it's still unproven — the strap may decline 2M (no-op), or a marginal link could retransmit and eat the gain. That's what the toggle and the onPhyUpdate line are for.

Experimental, default OFF

Settings → Strap → "Faster Bluetooth link (experimental)". Off is byte-for-byte today's behaviour: applyPreferredPhy early-returns and issues zero BLE ops.

Not validated on hardware — I have no strap, and BLE behaviour can't be CI- or Linux-tested. Default-off makes it safe to merge; proving it needs an on-strap before/after.

Tests

• PreferredPhyTest — 4/4. Pins that off = plain 1M, that on always keeps 1M in the mask for fallback, and that phyLabel reads the PHY_LE_* value (1/2/3) rather than the *_MASK constants — the two numbering schemes overlap, so a label comparing against masks would misreport the link.
• Full com.noop.ble suite green — including GattCrashSafetyTest 7/7 after the GattOps interface addition.
• compileFullDebugKotlin + i18n audit (all focus locales) green.

How to measure

Flip it, sync a real day-or-two backlog, compare the strap log before/after:

• PHY negotiated: tx=2M rx=2M → the strap supports it and it took.
• still 1M → WHOOP declined; that alone is worth knowing.
• records/sec from session started/ended + persisted N rows.

If neither this nor #536 moves the needle, that's strong evidence the offload really is firmware-paced — which genuinely earns the HCI capture #533 is asking for.

Cross-platform: no Swift twin (deliberate)

Per the parity contract this needs an explicit "why not": CoreBluetooth exposes no app-side API for this. The peripheral proposes the GAP connection parameters and Apple's stack negotiates them (and the PHY) itself — apps get no say. #477 already records the same divergence in-code: "Android-only by necessity … so there is no Swift twin — a deliberate platform divergence, not a parity gap."

Useful corollary: because iOS/macOS have their link parameters chosen for them, they are effectively "Android with these levers permanently on and untunable" — which makes them a control group. If a Mac drains a comparable backlog at a much higher rows/sec than Android (compare Backfill: session started / session ended / persisted N rows, which both platforms log identically), the strap is provably not firmware-paced, since the strap is the constant across the test. If they match, these levers likely will not help and #533's HCI capture is the better investment.

The one lever here that does have a Swift twin is the scheduler (MAX_AUTO_CONTINUES / the 15-min BACKFILL_INTERVAL_MS, mirrored by BLEManager.maxAutoContinues / BackfillPolicy.periodicFloorSeconds) — deliberately untouched in this PR, and it would need both platforms if changed.