GB-M0-R4 — Buds2 Pro Transport Critical Spike

[PNHD]

Goal

Determine whether Galaxy Buds2 Pro (SM-R510) can be managed while audio remains connected to iPhone.

Branch

feature/gb-m0-feasibility

Source packet

agent_tasks/GB-M0-R4.md

Phase A — read-only protocol research

• inspect current GalaxyBudsClient model/protocol support
• verify SM-R510 service UUID acquisition path
• enumerate non-destructive status + ANC command/state families
• document framing/checksum behavior
• do NOT copy GPLv3 implementation code

Phase B — iPhone service inventory

• inventory CoreBluetooth-visible Buds services/characteristics
• classify direct path as DIRECT_IOS_GATT or NO_USABLE_GATT
• do not treat Core Bluetooth Classic as arbitrary RFCOMM

Phase C — Watch6 RFCOMM PoC

First candidate SM-R510 service UUID:
2e73a4ad-332d-41fc-90e2-16bef06523f2

• resolve via SDP/service UUID rather than hard-coded channel
• connect read-only first
• obtain/decode stable status/battery
• only then test one ANC toggle

Critical topology gate

With Buds actively streaming audio from iPhone:

1. Watch management socket connects and remains stable.
2. Watch can read status/battery.
3. ANC toggle changes acoustic behavior and returned state.
4. iPhone audio remains usable.

Final recommendation must be exactly one of:

• DIRECT_IOS_GATT
• WATCH_RFCOMM_BRIDGE
• BLOCKED

Safety / stop conditions

• no firmware flashing/downgrade
• no reset command
• no unknown/destructive writes
• no PASS from source inspection alone
• no merge without owner/PM review

[PNHD]

R4 Phase A research verified against timschneeb/GalaxyBudsClient@dce4735d76cd16abb818cdd96bf458efd4abef47.

Confirmed:

• Buds2ProDeviceSpec selects Uuids.SppNew.
• SppNew = 2e73a4ad-332d-41fc-90e2-16bef06523f2.
• Current packet model uses SOM + modern header + message ID + payload + CRC16-CCITT + EOM, with request/response and fragmentation bits in header.
• No hardware claim is made yet.

Repo evidence updated in docs/PROTOCOL_RESEARCH.md and docs/CURRENT_WORK.md.

Next gate: physical iPhone GATT inventory, then Watch6 SDP/RFCOMM probe if no usable direct management GATT exists.

[PNHD]

CODEX IMPLEMENTATION HANDOFF — GB-M0-R4 HARDWARE DIAGNOSTICS

Session: separate dedicated session; do not mix with R1
Agent: Codex
Model: 5.6 Sol
Effort: High
Speed: Standard
Role: diagnostic implementation owner
Workspace: PNHD/GalaxyBridge → feature/gb-m0-feasibility
Write authority: YES, only R4 diagnostic scope
Sub-agents / parallel agents: OFF
Merge authority: NONE

Read first

• docs/CURRENT_WORK.md
• docs/PROTOCOL_RESEARCH.md
• docs/M0_TEST_PLAN.md
• agent_tasks/GB-M0-R4.md
• this issue and its research evidence

Verified baseline facts

Upstream snapshot already inspected: timschneeb/GalaxyBudsClient@dce4735d76cd16abb818cdd96bf458efd4abef47.
SM-R510 / Buds2 Pro uses the SppNew service UUID candidate:
2e73a4ad-332d-41fc-90e2-16bef06523f2

Do not copy GPLv3 implementation code. Implement only independently derived interface/wire behavior needed for the diagnostic.

Task A — iOS Buds service inventory

Add a minimal iOS diagnostic screen/module that:

1. Scans for the paired/visible Buds2 Pro.
2. Enumerates every CoreBluetooth-visible service and characteristic.
3. Records UUID, properties, readable/writable/notifiable flags, MTU/relevant limits if exposed.
4. Performs NO unknown/destructive writes.
5. Produces exportable redacted diagnostic text.

The purpose is to classify direct iOS management as either:

• DIRECT_IOS_GATT_CANDIDATE
• NO_USABLE_GATT_OBSERVED
• HARDWARE_REQUIRED

Do not claim RFCOMM access from CoreBluetooth.

Task B — Wear OS RFCOMM probe

Add a separate minimal Wear OS diagnostic path that:

1. Locates the physical SM-R510 by paired device/address selection.
2. Uses the platform RFCOMM API with SDP/service UUID resolution for:
   2e73a4ad-332d-41fc-90e2-16bef06523f2
3. Connects read-only first.
4. Captures connection success/failure, SDP/RFCOMM errors and incoming raw bytes with bounded logs.
5. Does not send reset/FOTA/unknown commands.

Only after an independently understood non-destructive status request is available may the tool send that one request. ANC write testing is deferred until stable read/status evidence exists.

Critical topology test runbook

Prepare exact owner steps for this physical state:

• Buds2 Pro actively playing audio from iPhone
• Watch6 independently runs the management probe

Evidence must answer:

1. Does Watch RFCOMM connect while iPhone A2DP remains active?
2. Does audio continue without takeover/drop?
3. Can Watch receive stable status bytes?

Do NOT mark ANC/config parity yet.

Validation

• confirm branch/HEAD/clean state before edits
• build/test all created modules where host environment permits
• no fabricated device results
• diff/hygiene review
• explicit commit

Final task status

Until real hardware evidence exists, maximum status is:
PARTIAL — HARDWARE_REQUIRED.

Return:

• branch + HEAD
• files changed
• exact build/test output summary
• iOS service-inventory implementation status
• Watch RFCOMM implementation status
• safety boundaries
• exact owner test steps
• blocker classification if any

Do not merge PR #3. Do not start product Buds controls/UI.

[PNHD]

CURRENT EXECUTION SETTINGS — GB-M0-R4

Use the current Codex model picker available to the owner:

• Model: GPT-5.6 Sol
• Effort: Max for R4 protocol/RFCOMM diagnostic work
• Speed: Standard
• Sub-agents / parallel agents: OFF

Reason: R4 contains ambiguous platform behavior, Bluetooth Classic/RFCOMM interoperability, protocol framing, safety constraints, and cross-device topology decisions. This is a better fit for Sol + Max than Terra/High.

Do not use stale GPT-5.3-Codex naming for this task.

PM HANDOFF — REQUIRED

At completion, return a complete PM handoff including TASK ID, status, repo, branch, baseline/final HEAD, commits, exact files changed, implementation summary, architecture decisions, exact commands run, build/test results, unvalidated items, hardware evidence/not-tested items, known risks, reviewer attention, owner actions, next recommended task, and final git status. Then STOP; do not merge or start the next task.

[PNHD]

R4 RESEARCH ADDENDUM — INDEPENDENT PROTOCOL CROSS-CHECK

Do not interrupt/restart the currently running Codex R4 session for this note. Use it during PM review/revision if needed.

A second independent open-source implementation family was identified:

Freeyourgadget/Gadgetbridge

• License: AGPLv3 — REFERENCE_ONLY, no implementation copy into GalaxyBridge main codebase.
• GitHub mirror is archived and project has moved to Codeberg.
• Archived changelog independently confirms:
  • Galaxy Buds2 Pro initial support by Gadgetbridge v0.73
  • later Buds2 Pro recognition fixes in v0.79

Why this matters:

• R4 protocol conclusions should not depend on GalaxyBudsClient as the only reverse-engineered source.
• Where possible, cross-check non-destructive Buds2 Pro message families / feature behavior against both GalaxyBudsClient (GPLv3) and Gadgetbridge (AGPLv3), then independently implement only the minimum wire behavior needed by GalaxyBridge.

License boundary remains strict:

• protocol facts / observed wire behavior / interoperability knowledge: usable as research
• copied GPL/AGPL implementation: forbidden in current GalaxyBridge codebase

Current physical hardware gate and safety stop conditions are unchanged.

[PNHD]

R4 SOURCE REUSE / CROSS-CHECK ADDENDUM — PASS 3

Do not restart or interrupt the currently running R4 agent for this note. PM should use these findings when reviewing its handoff or preparing the next repair pass.

1. IMPORTANT: two independent RFCOMM service-selection paths now exist

Current GalaxyBudsClient@dce4735d76cd16abb818cdd96bf458efd4abef47 explicitly defines:

• SppLegacy = 00001102-0000-1000-8000-00805f9b34fd
• SppStandard = 00001101-0000-1000-8000-00805f9b34fb
• SppNew = 2e73a4ad-332d-41fc-90e2-16bef06523f2
• SmepSpp = f8620674-a1ed-41ab-a8b9-de9ad655729d

Its Buds2 Pro spec selects SppNew.

However archived Gadgetbridge's independent Galaxy Buds implementation (AGPLv3, reference-only) routes all non-original Galaxy Buds including Buds2 Pro through the standard serial UUID 00001101-0000-1000-8000-00805f9b34fb.

This conflict is useful evidence, not something to resolve by assumption. R4 hardware diagnostics should enumerate actual SDP service records on the owner's SM-R510 and record service name + UUID + RFCOMM channel. If the current implementation probes only SppNew, the PM should request a repair pass that also inventories/probes SppStandard non-destructively before declaring RFCOMM unavailable.

2. Gadgetbridge independently confirms a meaningful Buds2 Pro feature surface

Archived Gadgetbridge has a dedicated GalaxyBuds2ProDeviceCoordinator with 3 battery endpoints (case / left / right) and a Buds2 Pro settings screen exposing, among others:

• noise control
• voice detect + duration
• ambient during calls
• ambient left/right level + tone
• EQ preset
• touch lock and left/right touch actions
• double-tap edge
• in-ear detection
• seamless connection
• one-earbud noise control
• left/right balance
• game mode

This is still REFERENCE_ONLY because Gadgetbridge is AGPLv3, but it independently confirms that these command families are not merely GalaxyBudsClient UI inventions.

3. Gadgetbridge protocol is useful as an independent wire-format check, but not production-quality code to copy

Its Galaxy Buds protocol independently shows the 0xFD ... CRC16-CCITT ... 0xDD framing family for Live/Pro/Buds2/Buds2 Pro and recognizes battery messages 0x60/0x61. It also contains many command IDs overlapping the broader ecosystem research (noise controls, ambient, balance, seamless, voice detect, spatial audio control, etc.).

Do NOT copy this AGPL implementation. Also note its IO layer performs a 1 MiB read buffer and disables auto-connect; that is not a design target for GalaxyBridge.

4. MIT source found for spatial/head-tracking protocol building blocks

timschneeb/BudsPro-Headtracking

• License: MIT
• audited snapshot: 63b321aa0536fd28233eaaf3a05c4f3b3f8201fe
• reusable/adaptable parts after R4 transport is proven:
  • modern packet framing + CRC implementation
  • spatial sensor command/data IDs
  • attach/detach/keepalive state model
  • quaternion extraction semantics

Relevant protocol values in that MIT code:

• spatial enable message: 124 / 0x7C
• spatial data: 194 / 0xC2
• spatial control: 195 / 0xC3
• attach/detach/keepalive control IDs: 0 / 1 / 4
• gravity quaternion event: 32

Caution: the project was written for Buds Pro and later only broadened SDP service-name matching to FACTORY for Buds2-family devices. Public issue evidence includes Buds2 Pro connections that establish and then abort/stutter without stable spatial data. Therefore this is APPROVED_FOR_ADAPTATION, not proof that Buds2 Pro head tracking already works.

5. Current GalaxyBudsClient Buds2 Pro spec confirms the target has the capability

The current Buds2 Pro spec declares SpatialSensor and firmware-gated HeadTracking, alongside ANC, ambient, voice detect, case battery, touch, fit test, charging state, auto-adjust sound, rename and other capabilities. This is GPLv3 source, so use it only as protocol/feature research.

PM consequence

For the R4 review, do not accept a conclusion of RFCOMM_UNAVAILABLE unless actual SM-R510 SDP evidence covers at least the relevant standard/new service candidates. After base management transport passes, spatial/head tracking should become a separate follow-up spike using the MIT head-tracking implementation as the reusable baseline and real Buds2 Pro hardware as the gate.

Safety rules remain unchanged: no reset/FOTA/fuzzing/unknown writes.

[PNHD]

PM REVIEW — R4 DIAGNOSTIC IMPLEMENTATION

Status: PARTIAL — HARDWARE_REQUIRED

PM verdict

Software-side diagnostic scope is ACCEPTED for physical execution based on the implementation handoff. This is not an architecture PASS and does not select DIRECT_IOS_GATT, WATCH_RFCOMM_BRIDGE, or BLOCKED.

Reported local commit:
01eda8c9e372055be5e5fea7c033561faa7095e0

Reported baseline:
80943f1936d940c53d83dac360eaa45076e40814

Important remote-state note: PR #3 still points at 80943f1936d940c53d83dac360eaa45076e40814; the R4 commit has intentionally not been pushed, so PM cannot yet perform a remote file-by-file diff review of the 32 changed files.

Accepted safety boundary for hardware run

• iOS: service/characteristic inventory, read-only reads, notify/indicate subscriptions, bounded/redacted logging only
• Watch: explicit bonded-device selection, RFCOMM connect using SDP/service UUID resolution, input stream only, bounded raw logging, manual disconnect
• exactly zero protocol payload writes
• no status query yet
• no ANC/config commands
• no reset/FOTA/debug/fuzzing

Physical gate to execute now

Run docs/GB-M0-R4_OWNER_RUNBOOK.md on the real iPhone + Watch6 + SM-R510 and return:
A. RFCOMM connect result
B. iPhone audio continuity
C. source-switch/takeover behavior
D. received byte count + bounded redacted hex
E. status query = NO — NOT IMPLEMENTED
F. post-disconnect iPhone audio result
plus exact iOS/Wear OS/Watch model/SM-R510 firmware and timestamped notes/recording.

Decision rules after evidence

• Useful iOS management GATT surface observed -> DIRECT_IOS_GATT_CANDIDATE, then inspect exact characteristics before any write.
• No usable iOS GATT + stable Watch RFCOMM while iPhone audio remains uninterrupted -> WATCH_RFCOMM_BRIDGE_CANDIDATE.
• RFCOMM cannot connect, persist, or coexist with iPhone audio -> remain HARDWARE_REQUIRED until alternate advertised service(s) are tested; do not immediately classify BLOCKED from one UUID failure.

Explicit hold

DO NOT authorize protocol status query, ANC toggle, product Buds UI, push, PR merge, or R8 spatial/head-tracking execution yet.

Next PM action: review native-build + physical-device evidence, then decide whether a second read-only RFCOMM-service probe is necessary before any protocol transmission.

[PNHD]

PM EVIDENCE UPDATE — R4 WEAR DEPLOYMENT PASS

Owner/Android Studio Agent physically prepared the Watch6 diagnostic environment.

Verified handoff:

• JDK: OpenJDK 17.0.20 (Microsoft Build)
• Android SDK: Platform 35 verified
• Gradle: BUILD SUCCESSFUL
• APK: wear/app/build/outputs/apk/debug/app-debug.apk
• Watch6 ADB: connected at 192.168.0.65:41027
• APK install: SUCCESS
• App launch on physical Galaxy Watch6: SUCCESS
• Launch Logcat: no crash / no critical error
• Source files modified during deploy step: NONE

PM classification:
SOFTWARE/DEPLOYMENT GATE ACCEPTED — PHYSICAL RFCOMM TOPOLOGY TEST NEXT

Still forbidden:

• no protocol/status writes
• no ANC writes
• no automatic reconnect/fuzzing
• no architecture classification yet

Next physical gate: pair/bond SM-R510 to Watch6, return active Buds audio ownership to iPhone, then perform exactly one read-only RFCOMM connection attempt while observing audio continuity/source switching/received bytes. R4 remains PARTIAL — HARDWARE_REQUIRED.

[PNHD]

HARDWARE PREFLIGHT EVIDENCE — 2026-08-11

Owner successfully installed and launched the R4 Wear diagnostic on physical Galaxy Watch6. Native UI hierarchy/report confirms target SM-R510 is bonded and exposes/caches 16 Bluetooth service UUIDs on Watch6, including:

• 00001101-0000-1000-8000-00805f9b34fb — standard Serial Port / RFCOMM
• 2e73a4ad-332d-41fc-90e2-16bef06523f2 — Samsung SppNew candidate
• f8620674-a1ed-41ab-a8b9-de9ad655729d — Samsung SMEP alternate
• 0000111e-0000-1000-8000-00805f9b34fb — Handsfree
• 0000184e-0000-1000-8000-00805f9b34fb — LE Audio

App state is still IDLE; no R4 RFCOMM connect attempt to the Buds has occurred yet. Current diagnostic remains read-only and reports BOND_BONDED for the selected SM-R510.

This materially strengthens the service-discovery hypothesis: SppNew is not merely a source-code guess; it is present in the physical Watch6 cached UUID list for the owner's Buds2 Pro. Standard SPP and SMEP are also physically visible, so a failed SppNew connection must NOT be interpreted as final BLOCKED without alternate-service probing.

Unrelated system logcat RFCOMM errors observed against a different Bluetooth address belong to Wear OS companion/system traffic and are not accepted as R4 Buds test evidence.

NEXT HARDWARE GATE

1. iPhone actively streams audio to Buds2 Pro.
2. Watch6 keeps SM-R510 bonded but does not own audio.
3. Owner selects the SM-R510 in GalaxyBridge and taps Connect exactly once.
4. Observe 60 s: RFCOMM state, duration, received byte count, iPhone audio continuity, unexpected source switch.
5. Disconnect exactly once; observe iPhone audio another 30 s.
6. Do not send status/ANC/spatial packets yet.

R4 remains PARTIAL — HARDWARE_REQUIRED.

[PNHD]

PM CORRECTION — FIRST PHYSICAL TOPOLOGY RUN INVALID / PERMISSION-BLOCKED

Owner evidence from Watch6 shows the first manual Connect attempt did not establish RFCOMM.

Observed on-device report:

• connection_established: false
• socket_state: disconnected
• exception_type: java.lang.SecurityException
• exception: Need android.permission.BLUETOOTH_SCAN ... BluetoothAdapterServiceBinder.cancelDiscovery()
• bytes_received_total: 0
• disconnect_reason: connect_failed

Root cause is confirmed in current source:

• AndroidManifest.xml declares BLUETOOTH_CONNECT but not BLUETOOTH_SCAN.
• MainActivity requests only BLUETOOTH_CONNECT at runtime.
• ReadOnlyRfcommProbe.runConnection() calls BluetoothAdapter.cancelDiscovery() before socket creation.
• Android 12+/S requires runtime BLUETOOTH_SCAN for cancelDiscovery().

Therefore any interpretation such as ~47 seconds connected is rejected. The grey Disconnect button is expected because the probe fell back to disconnected state immediately after the SecurityException.

Required repair before repeating hardware topology gate

1. Add android.permission.BLUETOOTH_SCAN for S+ and request it at runtime together with BLUETOOTH_CONNECT.
2. Keep cancelDiscovery(); do not remove it just to bypass the permission because Android recommends cancelling discovery before RFCOMM connect.
3. Add diagnostic/UX protection so the 60-second physical probe is not invalidated by watch screen timeout/activity recreation; minimum acceptable approach is keep-screen-on only while probe is active and clear it when inactive.
4. Rebuild/install on the same Watch6.
5. Repeat exactly one read-only connection attempt using 2e73a4ad-332d-41fc-90e2-16bef06523f2 while iPhone audio remains active.

Do not try alternate UUIDs yet. Do not send protocol/status/ANC bytes. Maximum status remains PARTIAL — HARDWARE_REQUIRED.

[PNHD]

PM EVIDENCE REVIEW — GB-M0-R4-R1B

Verdict: ACCEPTED — SPPNEW TOPOLOGY PHYSICALLY PROVEN

Reviewed owner-supplied evidence bundle GB-M0-R4-R1B-PM-EVIDENCE.zip.

Verified:

• ZIP SHA-256: B52CDF0C743797F21279A1962D53D952D0FD61F3FA975BDFF456ECA4862408E6 (matches handoff).
• Remote commit exists: 53bb959ba12fa44444ccd8b045e37ccd87ebd317 (fix(gb-m0-r4): lock Buds target and bound RFCOMM connect), parent ecf0805f69c82ea303d7a699cf6bdf3bddd3d2c2.
• Target identity is valid: SM-R510 / Buds2 Pro, redacted suffix AB:E4.
• Service under test: 2e73a4ad-332d-41fc-90e2-16bef06523f2.
• Android Bluetooth stack logs show SDP success, resolved RFCOMM SCN/channel 27, RFCOMM open event, and BluetoothSocket connected to AB:E4.
• Low-level socket timing: connect called 15:21:08.472, connected 15:21:10.039 (~1567 ms). App-level timer starts slightly earlier and reports ~1900 ms; both are consistent with different measurement boundaries.
• Mid-test physical UI shows target Buds2 Pro ... AB:E4, state CONNECTED, with 3294 bytes already received.
• Later diagnostic evidence reaches 3363 bytes received.
• commands_sent: 0; no status/ANC/FOTA/reset command was sent.
• Final state records owner-requested disconnect.
• Owner observation: iPhone audio remained OK during test, Buds did not switch audio to Watch, and iPhone audio remained OK afterward.

Architecture consequence:

• WATCH_RFCOMM_BRIDGE is now the accepted Buds transport candidate for M0.
• Do not spend the next step probing Standard SPP merely because SppNew was uncertain; SppNew is now physically proven.
• Do not send any control command yet.

Next gate:
GB-M0-R4-R2 — Read-only Protocol Decode.
First decode the captured unsolicited SppNew stream offline, validate framing/CRC and identify stable non-destructive message families. The capture already contains a valid-looking EXTENDED_STATUS_UPDATED (0x61) frame plus other unsolicited frames, so a status query may not be necessary to obtain minimum state.

Evidence QA notes (non-blocking):

• Archive contains 37 files although handoff said 38.
• SHA256SUMS.txt contains 36 hashes because it does not hash itself; all listed hashes verify.
• r1b-pre-test.xml is empty, but verify_target.xml, mid-test screenshot, low-level Bluetooth logs, and final reports provide sufficient target/connection proof.
• r1b-mid-test.png and r1b-post-test.png are byte-identical, so do not use the latter as independent post-disconnect screenshot evidence.

Keep PR #3 draft/unmerged. No product Buds controls yet.