docs: M7 now-playing telemetry is Pi-side AVRCP broadcast, no Android app needed

poc/yaris-mediacenter-plan.md

@@ -290,34 +290,33 @@ Add M6 later as an optimization for Spotify specifically.
 
 ---
 
-### Phase M7: Android Auto "now playing" telemetry readout (stretch goal)
-**Goal:** Show live OBD values (speed, RPM, coolant) on the portable CarPlay/Android Auto
-screen. The 9.26" display only runs CarPlay/AA — it has no Android app surface — so the only
-viable path is a templated AA app that spoofs media metadata (the "now playing field" trick).
+### Phase M7: Idle "now playing" telemetry broadcast (stretch goal)
+**Goal:** Show live OBD values (speed, RPM, coolant) on the car radio's display using the
+Bluetooth link that M1-M6 already establishes — **no Android Auto, no extra app.** When
+nothing is playing, the Pi's A2DP source broadcasts live telemetry as the AVRCP track
+metadata, so the radio's "now playing" field shows the gauges instead of a song.
 
-- [ ] Register the yaris-obd Android app as an Android Auto **media** app
-      (`CarAppService` + `MediaSession`) — Fermata Auto / OBD2AA style.
-- [ ] Push live values into the now-playing fields, refreshed every 1–2 s from the Pi's
-      `/api/obd/status` (or a new lightweight endpoint):
+- [ ] When the audio pipeline is idle (no phone A2DP stream, loopback inactive), have the
+      Pi's BlueZ `org.bluez.MediaPlayer1` (source side, facing the radio) emit a synthetic
+      track:
       - Title: `87 km/h`
-      - Subtitle: `RPM 2400 · Coolant 90°C`
-- [ ] One APK, two surfaces: the full Compose app stays on the phone; the AA surface is a
-      separate templated screen.
+      - Artist: `RPM 2400 · Coolant 90°C`
+- [ ] Refresh the metadata every 1–2 s from `modules/app_obd.py` (speed, RPM, coolant)
+      via a lightweight DBus call — no new hardware, no new app.
+- [ ] The moment real audio starts (phone stream appears / loopback goes active), swap the
+      metadata back to the real track (Title/Artist relay from M2).
 
 **Constraints:**
-- **No gauges** — AA only exposes templated text/buttons; this is a text readout, not a
-  gauge cluster.
-- **WiFi conflict** — wireless AA owns the phone's WiFi, so it can't also be on the Pi
-  hotspot. Requires **wired AA** (USB) so WiFi stays free for the Pi, or real-time OBD
-  pushed via the server over cellular (adds latency + load).
-- **Distribution** — custom AA apps need Google Play review (unlikely to approve) or a
-  whitelist patch (`aa-rs`/root/ADB); AAAD only installs its fixed list and Google patches
-  these routes regularly.
-- **Driver safety** — AA is templated and driver-safety-limited; treat as a parked/glance
-  readout.
+- **Text only** — the radio shows whatever fields it supports (usually Title/Artist/Album);
+  this is a text readout, not a gauge cluster.
+- **Radio-dependent** — the car radio must display AVRCP metadata (Q5); otherwise the
+  readout is invisible. The portable 9.26" CarPlay/AA screen already satisfies this.
+- **No conflict** — unlike an Android Auto app, this rides the existing A2DP link, so there
+  is no WiFi conflict, no Play review, no distribution problem.
 
-**Note:** this phase is Android-side (lives in `android/`), unlike M1-M6 which are
-Pi-side. It lands under the same "media center" umbrella the car converges on.
+**Note:** this is Pi-side (lives in `modules/app_mediacenter.py`), consistent with M1-M6.
+It also makes the telemetry readout work on the portable CarPlay/AA screen **without** any
+Android Auto app — the Pi is the "player" from the radio's perspective.
 
 ---