david/changeling
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Page: Screen Design
Pages
Architecture Building and Testing Home Project Status Screen Design Setup
2 Screen Design
David Spitzer edited this page 2026-07-02 16:15:02 -07:00
Table of Contents

Screen Design

This page tracks design thinking for the on-car UI (M4 and beyond), ahead of and alongside actually building it. It's a working document, not a spec — expect it to change as decisions get made.

We're not constrained to look like Android Auto

Worth restating from an earlier discussion: the video channel is effectively screen mirroring. The phone renders actual pixels and streams them (H.264) to the car; the head unit just displays whatever it receives. Since Changeling implements the phone side, we decide what gets rendered — there's no "Android Auto's UI" baked into the head unit; that UI is the video stream from a real session. So the plan is a genuinely own-designed UI, not a clone.

The real constraints (confirmed from the protocol schema)

These aren't stylistic opinions — they're what the wire format actually allows for, from VideoConfigData.proto and related enums:

  • Resolution: the head unit advertises one of 480p, 720p, 1080p, 1440p (plus portrait variants — _p suffixed entries in the enum, e.g. for cars with a portrait-oriented screen). We render at whatever it asks for.
  • Frame rate: 30 or 60 fps.
  • DPI + margins: the config includes a dpi field and margin_width/margin_height — the head unit's screen may not be a clean rectangle (rounded corners, a status bar area reserved by the car, etc.), so the UI needs to respect those margins rather than assume full-bleed.
  • Input isn't just touch: ButtonCodeEnum.proto defines a full set of hardware button/knob codes the head unit can send — HOME, BACK, MENU, PHONE/CALL_END, directional UP/DOWN/LEFT/RIGHT/ENTER (for rotary-knob-controlled infotainment systems with no touchscreen), media transport buttons (PLAY/PAUSE/NEXT/PREV/TOGGLE_PLAY), hard buttons for MUSIC/NAVIGATION/RADIO/TEL, and a SCROLL_WHEEL code. The UI has to be usable via D-pad-style navigation, not just touch, since not every car (and not every mode within a car) offers a touchscreen.

Practical/safety considerations (not technically enforced, but worth holding ourselves to)

  • Large touch targets, high contrast, minimal text — this is used while driving.
  • A D-pad/rotary navigation model needs a clear focus indicator at all times (since there's no cursor or hover state to rely on).
  • Should support both light and dark themes reasonably, since cars vary in ambient lighting expectations (some auto-switch based on headlights).

Decisions (as of the first design pass)

Worked through interactively using mockups rather than describing layouts in prose — see the reasoning behind each choice below.

  • Visual identity: playful, leaning into the "Changeling" shapeshifter theme (a simple sparkle/spark mark for now) — easy to roll back to something more utilitarian later if it doesn't hold up in daily use.
  • Color palette: shades of blue throughout (roughly #042C53 darkest to #E6F1FB lightest), both for the light and a dark preview variant.
  • Layout: map-first, not a launcher grid. The main screen area is reserved for the map/video surface (once M4 exists), with a persistent now-playing dock anchored at the bottom showing album art, track title, source app, and transport controls (prev/play-pause/next) — this is much closer to how real Android Auto actually behaves than an app-icon grid you navigate away from.
  • Reflects what exists today: right now that means the map area shows a "not built yet" placeholder and the dock is the only really functional piece; the layout is meant to grow into itself as M4+ lands, not be over-designed for features that don't exist yet.
  • Tapping the dock expands into a full browse view — back button, larger transport controls, and a scrollable list of tracks/artists so you can actually pick something different, not just control what's already playing.
  • Third-party media integration, not our own player: for real usage (Spotify, Symfonium during testing), Changeling doesn't play audio itself. It integrates with whatever's actually playing on the phone:
    • Control + metadata (title/artist/art, play/pause/skip) via Android's standard MediaSessionManager (accessed through a NotificationListenerService, a permission the user grants once) — this is the same generic mechanism Bluetooth car kits and smartwatches use, not something exclusive to Google's official Android Auto app. Works with any well-behaved media app.
    • Actual audio bytes via AudioPlaybackCaptureConfiguration (API 29+) with one-time MediaProjection consent — captures the system's mixed media-usage audio output regardless of which app produced it, and that's what feeds the MEDIA_AUDIO channel.
    • Known caveat: some apps restrict full library browsing to specific verified clients even while leaving playback control open — Spotify has historically done this; Symfonium (built to work with generic Android-Auto-style integrations) is expected to be more open. The browse view design accounts for this with a "can't browse, use your phone" fallback state for locked apps, rather than assuming every app behaves the same way.
    • The AudioFileDecoder/local-file-picker built during M3 becomes a fallback/demo path rather than the primary one.

Remaining open questions

  • How much of the screen is "ours" vs. system chrome: does the car reserve any of the frame for its own status bar/back button (tied to the margin_width/margin_height fields above), and if so, do we know that yet or is it something we'll only learn once we see a real head unit's negotiated VideoConfig?
  • Exact visual treatment beyond the mockup stage (typography, spacing system, icon set) hasn't been finalized — the mockups used Tabler icons and rough spacing as a stand-in, not a committed design system.

Status

Design direction agreed (map + persistent now-playing dock, blue/playful theme, third-party media session integration over a built-in player). No implementation yet — M4 (navigation/maps + the video/rendering channel) hasn't started, and neither has the NotificationListenerService/MediaProjection media integration work this design depends on. Both are candidate next engineering steps.