app-flutter/docs/impl/plans/DASH-NEXT.md

type, status, updated

type	status	updated
plan	draft	2026-10-15

Dash and app: what comes next

Ideas collected on 2026-10-15, before building anything. Each needs a short discussion first; specifics are open where marked. Where the app stands now: lib/README.md (the shell with its swipe-in menu, the Dash, the seven-role palette, hudFont), and contracts signals.json for what the Orin publishes.

1. Orin status in a top banner, like a phone's

First cut (2026-10-15): widgets/status_bar.dart, drawn by the shell over every view (the Dash's own top line is gone; its menu button moved in). Left: the menu (Dash only) and the link. Right: Orin temperature (only from 80 °C), CAN (alarm when absent or bus-off), OBD (only while the ELM is connected), GNSS fix icon and satellite count, LTE bars and technology (only with a modem), WiFi bars, UPS battery and % (caution on battery, alarm under 20 %), then the dark/bright button. Tapping the strip does nothing yet. What was asked:

A thin strip across the top of the app (the Dash's own top line included) showing the Orin the way a phone's status bar shows the phone: its network links and its power.

• Already on the bus, no Orin work needed: net_wifi_up and net_wifi_ssid, net_wifi_signal_dbm; net_lte_state, net_lte_tech, net_lte_signal_pct; net_tablet_up; ups_battery_pct, ups_state (charging / discharging / idle), ups_battery_v; can_up, can_bus_state; elm_connected; temperatures (orin_tj_temp_c). GNSS: gnss_fix, gnss_satellites (which undercounts: gpsd drops GPS from its sky view, see below).
• To discuss: which of these earn a place in the strip, and in what form (icons with palette roles, a number, or both); what tapping the strip does (the menu's link header already goes to Settings).
• Note for the satellite count: the receiver's own GGA count (e.g. 9) is right where gpsd's SKY (e.g. 5) is not; svc-core gnss would take it from there.

2. Dash layouts, and whether navigation is in them

Revamp the Dash's layout(s), and decide whether navigation (svc-nav: Valhalla routing, a MapLibre map, turn-by-turn on yukart/nav/guidance) lives on the Dash, beside it, or not at all. Inputs to the decision:

• Screen room: the tablet is 1340 × 800 dp in landscape; the boxed pattern already fills it.
• Several layouts are possible (a driving one, a navigating one), chosen in the menu or by state (a route active).
• New signals worth placing since the first Dash: vehicle_speed_kph (CAN), coolant_temp_c (CAN), steering_angle_deg, main_beam, front_fogs, front_wiper, imu_yaw_rate_dps.

3. Media controls for the Android player

A play/pause/next strip for whatever plays on the tablet. Google Maps' built-in media controls stopped working with Symphonium (the music app in use).

• Android's way in: MediaSessionManager.getActiveSessions() with a NotificationListenerService the user grants once in settings. That reaches any app that publishes a media session (Symphonium should: check what it exposes). Needs a small Kotlin part in the app's Android side (the app already has one: net.dart's method channel).
• To discuss: where it sits (the Dash, the top banner, a menu page), and how much (track title, artwork, seek).

4. Long shot: a floating window

The app as a small, movable overlay over other apps (Maps, the music player), showing a few chosen readouts.

• Android's way: SYSTEM_ALERT_WINDOW ("display over other apps", granted in settings) plus a foreground service drawing the overlay; Flutter can render into it with a second engine. Picture-in-picture is the lighter alternative, but PiP windows are not interactive.
• "Customisable (kind of)": which readouts it shows, chosen from the same widgets the Dash uses (the boxed pattern is already sized from its box, which suits a small window).

5. Dark/bright: automatic or fixed, the Android way

Done (2026-10-15): Settings has Auto / Dark / Bright (a segmented control, kept across restarts). Auto follows Android's dark theme (platformBrightness, so its schedule too). The status bar's button (it moved there with item 1) holds the other variant, and a long press returns it to auto.

Light sensor, tried (2026-10-15): Auto takes a light sensor over Android's dark theme where the device lets an app read one (theme/light.dart: dark at ≤ 15 lux, bright from 60, held 5 s; Settings shows the reading). The Redmi Pad SE does not: its only light sensor, camera_light_Sensor, is derived by Xiaomi from the front camera, and registerListener refuses apps at every rate (only the system's auto-brightness reads it). Its automatic brightness is not exposed either (screen_brightness is the manual level). Google Maps here reads no light sensor either (checked while it navigated in its night colours): it goes by time and place, and tunnels from map data.

Sun, done (2026-10-15): without a light sensor, auto follows the sun at the tablet's own rough location (Android's coarse location, polled; kept across restarts; not the Orin's GNSS, since the tablet has its own GNSS and cellular): dark below −4° (theme/sun.dart). Android's dark theme is the last fallback, before any location is known. Tunnels and car parks are not seen; the quick button covers them. What was asked:

Today the variant is a switch (the Dash's top-right button, and Settings). Wanted:

• Auto or fixed, chosen in Settings. Auto could follow Android's own dark mode (MediaQuery.platformBrightness, which follows the system schedule or sunset), or the tablet's ambient light sensor directly (smart-serow switched its theme from a light reading).
• Fully Android: when fixed, the switch should feel like a system control.
• Linked with the Dash's quick button: the dark/bright button at the Dash's top right stays the quick way to switch, and follows the same choice (auto or fixed) as Settings. It may move into the top banner (item 1) with the Orin's indicators.

Order

Not decided. 1 and 5 share the banner and are small; 2 decides the shape of everything else; 3 and 4 need Android-side work and permissions.