GB-M0-R7 — Watch6 HFP/PBAP System Profile Feasibility

[PNHD]

Goal

Determine whether Galaxy Watch6 system Bluetooth firmware can provide actual iPhone call audio and contact/phonebook sync when paired outside Samsung's normal Android-phone path.

This is separate from ANCS notification/call actions.

Why this gate exists

ANCS can expose notification actions such as answering/declining an incoming call, but that does not create SCO/HFP audio between iPhone and Watch.

Current Android platform source shows:

• BluetoothHeadsetClient (HFP Client role) is @SystemApi, @hide, and privileged; current AOSP source requires BLUETOOTH_CONNECT + BLUETOOTH_PRIVILEGED for relevant APIs.
• BluetoothPbapClient is also @SystemApi / hidden.

Therefore a normal third-party Wear OS app must NOT assume it can directly own HFP Client or PBAP Client through public SDK APIs.

Primary question

Does Samsung's system Bluetooth stack on Galaxy Watch6 already enable and negotiate the needed profiles with an iPhone when the watch is paired/bonded through the custom GalaxyBridge/ANCS path?

Phase A — read-only system inventory

On a physical Galaxy Watch6, using ADB only:

• record exact watch model / Wear OS / One UI Watch build
• inspect Bluetooth service/profile support with available dumpsys / cmd diagnostics
• enumerate bonded-device UUIDs/profile state after pairing iPhone
• determine whether HFP Client / PBAP Client services are present/enabled at system level
• do not modify secure settings or system packages
• do not use root

Phase B — physical call test

With iPhone paired to Watch through the supported test path:

1. receive a real phone call
2. verify ANCS alert/action independently
3. answer from watch if ANCS exposes the action
4. observe whether SCO audio route appears on the Watch
5. verify Watch mic/speaker audio in both directions
6. inspect Bluetooth profile state/logs

Classify:

• SYSTEM_HFP_AVAILABLE
• ANCS_CONTROL_ONLY_NO_HFP
• UNRESOLVED

Phase C — contacts/PBAP

If system PBAP Client is enabled:

• test whether iPhone requests contact-sharing authorization
• verify read-only contact/caller-ID availability
• do not scrape private contacts into persistent diagnostics

Classify:

• SYSTEM_PBAP_AVAILABLE
• NO_PBAP
• UNRESOLVED

Reuse policy

AOSP Bluetooth HFP/PBAP source is useful to understand profile state and system behavior, but copying hidden framework classes into an app does not grant privileged Bluetooth services/permissions. Do not pursue reflection/hidden-API hacks as the default product architecture.

Commercial products (Merge/Bridge/etc.) may be benchmarked for observed behavior, but their implementation is proprietary and does not prove a normal app-level API exists.

Hardware gate

No PASS from source inspection. Physical Watch6 + iPhone call/audio evidence is required.

Safety

• no root
• no system-app replacement
• no bootloader modification
• no privileged-permission injection
• no hidden-API bypass as part of this milestone

PM handoff

Any implementation/diagnostic agent must report model/effort, exact branch/HEAD, commands run, system profile output summary, physical evidence, unvalidated assumptions, owner steps and git status, then STOP.