GB-M0-R6 — Apple Media Service Reuse Spike

[PNHD]

Goal

Avoid inventing a custom iPhone media-control protocol when Apple's built-in Apple Media Service (AMS) already exposes media state and remote commands over BLE.

Dependency

Implementation depends on the shared iPhone/Watch BLE foundation from #1. Research/audit may proceed independently.

Status

RESEARCH_READY / IMPLEMENTATION_BLOCKED_BY_R1

Primary specification

Apple Media Service service UUID:
89D3502B-0F36-433A-8EF4-C502AD55F8DC

Characteristics:

• Remote Command: 9B3C81D8-57B1-4A8A-B8DF-0E56F7CA51C2
• Entity Update: 2F7CABCE-808D-411F-9A0C-BB92BA96C102
• Entity Attribute: C6B2F38C-23AB-46D8-A6AB-A3A870BBD5D7

AMS exposes Player / Queue / Track entities and supports standard remote commands such as play/pause, next/previous, volume, shuffle/repeat and related commands when the active iOS media player advertises them.

Important lifecycle rule: AMS may be published/unpublished dynamically, so implementation must handle GATT Service Changed and rediscovery rather than assuming the service is permanently present.

Reuse-first sources

APPROVED_FOR_ADAPTATION

coredevices/PebbleOS

• pinned research snapshot: 3cb06ce9034bc650741c3b76fe98cb5cd33aef61
• AMS files/tests carry Apache-2.0 SPDX headers
• useful test semantics:
  • service discovery
  • Entity Update subscription
  • Player/Queue/Track registration sequence
  • rediscovery invalidation/reset
  • retry when GATT resources are unavailable
  • remote-command mapping

Do not port Pebble firmware architecture wholesale. Adapt the protocol/test semantics into GalaxyBridge Kotlin tests and implement transport using the current Android BLE stack selected for the project.

REFERENCE_ONLY

GuiyeC/Aerlink-for-Android

• demonstrates AMS usage from Android Wear to iOS
• no clear license verified; do not copy implementation

KhaosT/AMS-Reference

• useful historical protocol reference
• no license detected; do not copy implementation

Proposed implementation direction

Use the same stable Nordic BLE stack selected for R2 and add AMS as another iOS system service client beside ANCS.

Minimum PoC after R1:

1. discover AMS if present
2. subscribe Remote Command supported-command notifications
3. subscribe/register selected Player + Track entity updates
4. display active media app / playback state / title / artist where exposed
5. send Play/Pause and Next only when advertised as supported
6. survive service disappearance/republication and reconnect

Improvement requirements

• deterministic operation queue
• no arbitrary sleeps
• bounds-safe parsing
• only send commands currently advertised by iOS
• explicit unsupported/no-active-player state
• no custom iOS companion protocol for functionality AMS already provides
• physical tests with Apple Music and Spotify

Hardware gate

No PASS from unit tests/emulator alone. Real iPhone + Galaxy Watch6 media behavior is required.

PM handoff rule

Any implementation agent must report exact model/effort, branch, baseline/final HEAD, commits/files, commands/build/tests, hardware-not-tested items, owner steps and final git status, then STOP without merging or starting another task.