# SPECS — Nils' MG4 Journal for this fork of [fatihdonmezdev/FatihsMG4](https://github.com/fatihdonmezdev/FatihsMG4): what has been changed, and what is still to do. - Our repository: https://git.stinnesbeck.com/nils/mg4 - Upstream: https://github.com/fatihdonmezdev/FatihsMG4 (itself a fork of malys / EVABRPUploader and Leon Kernan / ABRP_Uploader). Credited in the app's About dialog. ## Architecture: car server at car.k8s.stinnesbeck.com The car sends everything to our own server, which stores it in InfluxDB 2, and its live data straight to ABRP with the ABRP credentials kept (encrypted) in the app. The server does not talk to ABRP. Grafana reads InfluxDB directly for the dashboards. ``` car ──live telemetry───▶ car.k8s.stinnesbeck.com (Go) │ ──daily chunks─────▶ │ │ ──charging sessions▶ ▼ │ InfluxDB 2 ◀── Grafana (car-grafana.k8s.stinnesbeck.com) └──live telemetry─────▶ ABRP api.iternio.com/1/tlm/send ``` - **Server:** `server/`, Go 1.26, API only — see `server/README.md` for endpoints, configuration and the storage layout. Replaced the Next.js app from upstream (`web/`, removed 2026-10-17). - **Dashboards:** Grafana, provisioned from `k8s/grafana/`, reading with a read-only token: Live (stats, SoC/range, power/speed, route map, temperatures, tyres), Consumption (period totals, lifetime, SoH, per-day energy, distance and efficiency) and Charging (totals, session table, curves). Prices in euro. - **Pairing:** the car shows a QR code, a phone approves it with the approval password, and the car gets its own token, bound to its installation id (RFC 8628-style; `server/README.md`). The shared `INGEST_TOKEN` still works. The same QR flow carries settings typed on the phone. - **Car app:** tabs Overview, Consumption, Charging, Live data (on/off, ABRP credentials, frequency), Server (URL, pairing, token, installation id, config import), Settings (display, voice key, tyre unit, accent colour, battery, charging price, Wi-Fi), Logs. Live telemetry every 15 s while driving or charging, to the server and straight to ABRP; consumption chunks and charging sessions to the server. - **Deployment:** `k8s/`, plain manifests. **Nothing is ever applied to the cluster by us** — Nils applies them (`k8s/README.md`). TLS comes from Traefik's default certificate. ### Status Current: app 2.38.0 (installed on the car over the air, 2026-10-26), server 2.6.2 (pinned by digest in `k8s/server.yaml`; applied and running since 2026-10-25). - [x] On the car: QR pairing, values on the Overview, voice-key double press, full screen without black bands. - [x] Go server: tests and govulncheck clean; end to end in podman against InfluxDB 2.7.12 (telemetry, consumption, charging, pairing, settings from the phone) and Grafana 13.2.3 (all dashboard queries return data). - [x] Manifests validated offline (kubeconform, with Traefik CRDs). **Applied by Nils only.** - [x] Grafana's host in `k8s/ingress.yaml` is `car-grafana.k8s.stinnesbeck.com`, the one in use (owner, 2026-10-25). - [x] Screen on the car: 1920×720 px at 160 dpi, app window 1778×720 px (Logs → SCREEN). - [x] Car-colour probe on the car: only `ro.build.mtk2712.vehicle_type = AS28`; the paint colour is not in the system properties. It may be in the VHAL (a debug-build VhalProbe listing would tell); until then the accent is chosen by hand. - [x] On the car (owner, confirmed 2026-10-25): live data straight to ABRP (2.11), Enter on phone (2.12), accent colours (2.14), right-aligned values (2.14.1). ### Signals the car does not provide Checked 2026-10-17 against what actually reached InfluxDB (`schema.measurementFieldKeys`). The car sends soc, est_battery_range, odometer, power, voltage, current, speed, hvac_setpoint, the four tyre pressures, GPS (lat, lon, elevation, heading) and the is_* flags. It does **not** send: - **Battery temperature:** read from `EV_BATTERY_AVERAGE_TEMPERATURE`, an Android 14 property; the head unit runs Android 9, and the SAIC services offer none. - **Cabin temperature:** `HVAC_TEMPERATURE_CURRENT` is not published; only the setpoint is. - **Outside temperature:** not published by the vehicle (upstream noted the same). Upstream used the head unit's weather service as a stand-in (`HeadUnitWeather`, removed in `ea8032a`); restoring it was considered and declined. - **Pack energy (`soe`) and capacity:** not published. The Live dashboard computes energy in pack as SOC × usable capacity, from the hidden dashboard constant `usableKwh` (50.8 kWh for the 51 kWh battery) in `k8s/grafana/dashboards/live.json`. - **Adaptive cruise control (set speed, distance to the car ahead, ACC state):** the head unit gets none of it (SWI68, checked 2026-10-25). The `AAD_*` properties of `CarAdvancedAssistedDrivingManager` exist and answer, but stay at their defaults with ACC engaged behind another car (`AAD_EPTCCTRGTSPD` `0x2160A15B` 0.0, `AAD_ACC_OBJ_*` 0.0 / -128.0, modes 0). A signal recording of all 1,194 values while the set speed was 101, 90 and 80 km/h shows none of those numbers (also tried as m/s, mph and ×2/×10/×16/×64) outside the actual speed, and the ACC buttons send no key broadcast. Most likely only the instrument cluster has it. Not yet tried: listening (subscribing) instead of polling, as the head unit's own manager does — the recorder does it since 2.40.3; a drive with ACC will tell. ## To do - [ ] **Grafana high availability needs another database.** Grafana keeps its own state (users, sessions, preferences, provisioned-dashboard records, alerting state) in SQLite at `/var/lib/grafana/grafana.db` on the `grafana-data` PVC. That is fine for one replica, and is why `k8s/grafana.yaml` uses `replicas: 1` and the `Recreate` strategy: only one Grafana may write the file. To run more than one replica, first move Grafana to PostgreSQL or MySQL (`GF_DATABASE_TYPE`, `GF_DATABASE_HOST`, …); the replicas then share that database instead of a volume. The car data itself is in InfluxDB and unaffected. - [x] **EVHardware's comments are partly French.** Translated 2026-10-25 (see the done log). - [ ] **Idea: climate energy on the Overview (motor vs climate).** Nothing the app reads splits energy by consumer: battery power (voltage × current) is the total of motor, climate, 12 V and the rest. SAIC's charging service, which EVHardware already binds, has counters that might: `TotalConsumption`, `TotalRegen` and `AccConsumption`, each since start and since the last charge (`SaicCharging.consumedKwhSinceStart()`, `regeneratedKwhSinceStart()`, `accCounterKwhSinceStart()` and the `…SinceCharge()` twins). Whether "Acc" means *accessory* (a measured climate/auxiliary share; motor ≈ total − acc) or *accumulated* (a duplicate of the total) is unknown — EVHardware deliberately does not call it climate — and whether SWI68 answers at all is untested. Plan: (1) a read-only diagnostic showing the raw counters since start; (2) two drives, climate off and on, with a photo of the counters after each; (3) if Acc grows only with the climate, an Overview card "Climate & accessories since start" with the motor's share beside it — otherwise drop the diagnostic and, at most, show a labelled estimate (power drawn at a standstill with the climate on). ## Done - 2026-10-17 — Translated the app UI from Turkish to English. - 2026-10-17 — Nix flake: `nix develop` provides JDK 21 and the Android SDK. `build-car` builds the unstable APK and signs it with the AOSP test platform key, which the MG4 head unit uses (cert SHA-256 `c8a2e9bc…192ab8`). - 2026-10-17 — OTA update checks disabled by pointing at an unresolvable host (see To do). - 2026-10-17 — Renamed to "Nils' MG4": package ID `com.stinnesbeck.nilsmg4` (`.unstable` for the car build), APK names `NilsMG4-*.apk`. It installs next to the old FatihsMG4 app instead of replacing it, and starts with empty settings and history. - 2026-10-17 — Server rewritten for InfluxDB 2 with live telemetry and ABRP forwarding; Dockerfile; Kubernetes manifests (not applied). - 2026-10-17 — App 2.3.0: Server tab (URL, ingest token, installation id, config import), live telemetry restored from before `ea8032a` and sent to the server, Upload-tab cadence controls reconnected, dead switches removed. The removed ABRP classes' unit tests compile and pass again (AbrpApi and HeadUnitWeather tests deleted with their classes). - 2026-10-17 — Accent colour: MG red instead of muted gold. Web app renamed to Nils' MG4. - 2026-10-17 — Dashboard translated to English (en-GB formatting); euro instead of lira in the dashboard and the car app's charging tab. - 2026-10-17 — Server rewritten in Go (API only); dashboards moved to Grafana with provisioned InfluxDB datasource and three dashboards; the Next.js app (`web/`) removed. Per-host cert-manager certificates dropped in favour of Traefik's default certificate. - 2026-10-17 — Pairing by QR code: server 2.1.0 issues per-car tokens after approval on a phone; app 2.4.0 shows the QR code and collects its token. Tested end to end against InfluxDB. - 2026-10-17 — Incident: a commit swept the filled-in `secrets.example.yaml` (InfluxDB admin token, INGEST_TOKEN) into git and pushed it. Commit amended and force-pushed; both values regenerated in the now gitignored `k8s/secrets.yaml` (since moved to `k8s/secrets/secrets.yaml`, outside `kubectl apply -f k8s/`). Filled-in secrets live only there from now on. - 2026-10-18 — `english-translation` merged into the default branch (merge commit `f54e684`, the summary as its message), `master` renamed to `main`, the work branch deleted. Work goes on `main`. - 2026-10-18 — AGENTS.md rewritten as the entry point for agents: what the project is, rules, confirmed car facts, app structure, UI conventions, build/test/ship, documents. It replaces upstream's EVABRPUploader text. The test emulator is now in the flake: `nix run .#car-emulator` (Android 9 AOSP at 1920×720, 160 dpi; the car build installs as the system user — checked). - 2026-11-07 — App 2.49.1 published (`car-2.49.1`). - 2026-11-07 — App 2.49.1: **the Caterpillar looks more like the one in the book** (owner: "Make it more like the original caterpillar", with the German edition's cover as the reference). It arches over the middle like the cover's: overlapping chunks of mottled green and teal paper, a yellow fringe along the back, olive feet, and a red-orange head with a yellow face, green eyes and purple antennae; the speed is on the face. Power still lights the segments (blue when regenerating) and the back humps while driving. Still my own drawing of it, not the book's artwork. Two screenshots redone. Tested: unit tests, lint, emulator with sample values. Not tried on the car. - 2026-11-07 — App 2.49.0 published (`car-2.49.0`). - 2026-11-07 — App 2.49.0: **the Caterpillar style** (owner: "a theme based on The Very Hungry Caterpillar"; design agreed first, defaults taken: dark night page, named "Caterpillar" not the book's title, fruit as range). `CaterpillarView`, an original cut-paper collage, not the book's illustrations: the caterpillar's red head is the speed and its ten segments the power (blue while regenerating, wiggling while driving); the sun is the battery (a grey moon below 20 %); a leaf holds trip, usage, climate and odometer; a clock in a paper circle; fruit in the story's order (1 apple, 2 pears, 3 plums, 4 strawberries, 5 oranges) is the range, one per 50 km, used ones with a bite out; P R N D are an egg, the caterpillar, a cocoon and a butterfly; hills are the last two minutes of power. The music light (now also for this style) bounces the sun's rays and the segments on the kick drum. What plays: a butterfly and, on the next pass, a ladybird tow a strip of tissue paper (colour fixed by the song); both in `SongCarriers`. Own palette (green). Two screenshots in THEMES.md. Tested: unit tests, lint, emulator with sample values and with the throwaway fake song. Not tried on the car. - 2026-11-07 — App 2.48.0 published (`car-2.48.0`). - 2026-11-07 — App 2.48.0: **the Christmas style** (owner: "let's also do a christmas based theme", with music and something that pulsates; design agreed first). `ChristmasView`: a tree with a big red bauble (speed), fairy lights arching over it (power: gold left to right while drawing, ice blue and right to left while regenerating), a glass mug of cocoa filling with the charge (cold blue and "BATTERY LOW" below 20 %), gift tags (trip, usage, climate, odometer), a wreath clock, a signboard (range) with a candy cane per 50 km, P R N D as baubles, and a snow drift of the last two minutes of power; snow falls and the lights twinkle while driving. Own palette (red); always in the drop-down; English only. The music light is now **"Light follows the music"** for Halloween and Christmas (same `PREF_MUSIC_LIGHT`, off by default): the tree's lights and the arch flare on the kick drum. What plays: Santa's sleigh with a reindeer and, on the next pass, an angel with a trumpet tow a strip of wrapping paper (colour fixed by the song); both in `SongCarriers`. Two screenshots in THEMES.md. Tested: unit tests, lint, emulator with sample values (panel and full screen, and with no data), with the throwaway fake song (both carriers), and the music-tap thread runs only with the switch on. Not tried on the emulator: the pulse itself with real sound (the code path is Halloween's `MusicTap`). Not tried on the car. - 2026-11-02 — App 2.47.0 published (`car-2.47.0`). - 2026-11-02 — App 2.47.0: **now playing in four more styles** (owner: "let's implement Now playing in more styles"; Spanish labels declined). Quest: a red dragon tows a waving scroll across the top of the sky, behind the frames. Empire: an eagle flies a scroll across the top of the world, behind the speed. Terminal: a PLAYING row above the prompt. Sci-fi: the song in black on the top bar. The creatures are in the new `SongCarriers` (dragon, eagle) beside `SongBanner`. Same switch as before (Settings → "Show what's playing"). Not yet in the rest: Gauges, Cockpit, Retro, Futuristic, MG, Minimal, Nixie, Chronograph, Grid, Grid with map, Time circuits, Visor, Cartoon. Tested: unit tests, lint, emulator with the throwaway fake session. Not tried on the car. - 2026-11-02 — App 2.46.0 published (`car-2.46.0`). - 2026-11-02 — App 2.46.0: **Día de Muertos shows what plays** (owner: "Can we also put that into the dia de muertos theme?", then "switch between monarch and alebrije", "one color per song"). A strip of papel picado (zigzag-cut edges) with "♪ title — artist" waves across the sky between the flags and the ring, behind the ring and the clock; a monarch butterfly and an alebrije (a painted horned creature with feathered wings and a curled tail) tow it on alternate passes. The paper's colour is one of the flags', fixed by the song (hash of title and artist, never logged). The banner moved out of `HalloweenView` into the shared `SongBanner`; Halloween looks as before. Same switch as Tiles and Halloween (Settings → "Show what's playing"). Tested: unit tests, lint, emulator with the throwaway fake session. Not tried on the car. - 2026-11-02 — App 2.45.2 published (`car-2.45.2`). - 2026-11-02 — App 2.45.2: Halloween's song banner **waves** (owner: "Can it also be a bit wavy?"): waves run from the bat to the tail, still where the bat holds it and up to 7 units at the tail, and the text follows them (`drawTextOnPath`). Tested: emulator with the throwaway fake session, unit tests, lint. Not tried on the car. - 2026-11-02 — App 2.45.1 published (`car-2.45.1`). - 2026-11-02 — App 2.45.1: **Halloween's song flies through the sky** (owner: "Instead of taking up screen space on the bottom, can we somehow include the title in the theme itself? ... have text fly through the air"). A bat tows a parchment banner with "♪ title — artist" from left to right across the strip of sky above the sign, behind the moon, one pass about every half minute, again and again while something plays (the title is cut first so the artist stays); the line at the foot of the hill is gone. While a banner flies the view draws about 30 frames a second, as it does while driving. Tested: emulator with the throwaway fake session (banner clear of the sign along the whole pass), unit tests, lint. Not tried on the car. - 2026-11-02 — App 2.45.0 published (`car-2.45.0`). - 2026-11-02 — App 2.45.0: **now playing on the Overview** (owner: "can we also implement music titles etc in our app?"; display only, Tiles and Halloween first). `NowPlayingWatcher` follows the active media sessions as the music-sources check reads them (`MediaSessionManager`, MEDIA_CONTENT_CONTROL as the system user), with a change listener and a callback per session, so reading costs no call into another app; it never connects to a media browser service (2.42.0) and sends no command. It runs only while the Overview is on screen in Tiles or Halloween with Settings → "Show what's playing" on (**on by default**, `PREF_NOW_PLAYING`). `NowPlaying` (pure, unit-tested) picks the session that plays, the one updated last of several, else the one paused last, passing over sessions without text (Bluetooth's empty one); CarPlay's YouTube titles lose their `[videoID]`; the radio shows its text (the artist field, e.g. "BLIND MELON - NO RAIN") with the station below. Tiles: the empty slot under the battery shows source ("· paused" when paused), title, artist, a cover (the session's picture, or Bluetooth's `ALBUM_ART_URI` file, read small off the main thread) and how far the song is; invisible when nothing plays; the narrow layout has no room and shows none. Halloween: "♪ title — artist" along the foot of the hill, the title cut first. Titles stay on screen: not logged, not sent. Tested: unit tests, lint, emulator with a throwaway build publishing a fake session (CarPlay-like title with ID removed, cover, bar; Halloween line; the switch hides and brings back both). With Halloween chosen the Settings card has two switches more and scrolls further. Not tried on the car: whether the car's sessions, Bluetooth's cover file and the radio text show as in the music-sources checks. - 2026-11-02 — App 2.44.0 published (`car-2.44.0`). - 2026-11-02 — App 2.44.0: **the pumpkin light follows the bass, and only when switched on** (owner: "more focussed on the bass", "optional via a settings flag"). `MusicPulse` now reads the kick drum's band (40–120 Hz, was 20–250 Hz) and lights only on a jump since the last reading, against the biggest jumps of the last 4 s; a jump under a fifth of that, or under half the bass's average level, lights nothing. So kicks flash, and a held note, a wobbling bass line or a swelling note stay dark (unit tests with made-up patterns). It flares at once and falls in 0.2 s. New switch under the Overview style, shown only for Halloween: "Pumpkin light follows the music" (`PREF_MUSIC_LIGHT`), **off by default**; off, the analyser never starts. Tuned on made-up signals only: no Bluetooth or CarPlay sound report from the car has arrived yet. Next: now playing (title, artist, source) from the media sessions, in its own version. Tested: unit tests, lint, emulator (switch off by default and the analyser thread absent; on, it runs only on the Overview; a throwaway build playing a pulsing test tone: the glow flares with the switch on, and stays exactly still with it off). With Halloween chosen, the Settings card now scrolls a little to reach the tyre unit. Not tried on the car. - 2026-11-01 — App 2.43.5 published (`car-2.43.5`). - 2026-11-01 — App 2.43.5: **update checks log what happens** (`UpdateNetworkCheck`, `UpdateDiagnosis`; owner: updating from the car fails, "Can we log what happens? Maybe my SIM card has no data left"). Each check on Settings writes to the Logs tab: the networks Android sees (type, in use, internet, validated, roaming), whether the server's name resolves, how a failure happened, in words from its type or status only, and how many reports wait. On a failure it also asks `https://www.gstatic.com/generate_204`, the one request to anyone but the car server, to tell no data from a server that is down. A report goes to a USB stick and, when online, the server (`update-check-*.txt`; only the newest waits, so it cannot push out a recording). A check at start logs only a failure. The update log keeps 40 lines, not 10. An out-of-data SIM would also explain why the Bluetooth and CarPlay sound reports did not arrive; not confirmed. Tested: unit tests, lint, emulator with a fake server (online: the name fails, the internet test says it works; airplane mode: both fail, "none in use"; the real build installs and starts, its check not run there, having no server). Not tried on the car. - 2026-11-01 — App 2.43.4 published (`car-2.43.4`). - 2026-11-01 — App 2.43.4: **the Halloween pumpkin's light follows the music** (`MusicTap`, `MusicPulse`; owner: "make the light in the pumpkin react to the equalizer/sound of the music"). The bass, 25 times a second off the main thread, drives the glow and brightens the carving on the beat; yellow and green still mean drawing and regenerating, the embers still the power, and no signal leaves the light as it was. It listens only with the app in front, on the Overview, in Halloween. The owner reports the sound check worked with Bluetooth and CarPlay; those two reports never reached the server (why not is unexplained), so their levels are unseen and the pulse's feel is untuned for the car. Tested: unit tests, lint, emulator (a tone already playing when the analyser starts: the carving and glow move with it; no sound: unchanged; the analyser is released on another tab and when the app leaves the front; no crash). Not tried on the car; how it looks there, and its effect on the head unit over a long drive, are unknown. - 2026-10-31 — Sound check on the car (2.43.3), radio: `com.saicmotor.radio` playing, `isMusicActive` false, analyser enabled without error and silent for all 10 seconds (peak 0.00, -9600 mB). The audio analyser does not hear the radio. The owner ran Bluetooth and CarPlay too; those reports have not reached the server yet (the outbox sends oldest first and stops at the first failure, retrying while the service runs). - 2026-10-31 — App 2.43.3 published (`car-2.43.3`). - 2026-10-31 — Music checks from the car: the radio publishes a session while it plays (`com.saicmotor.radio`, 29 October, DAB: TITLE the station, ARTIST the programme text, AUTHOR the band), with `isMusicActive` false, so its sound may not pass through Android's mix and the audio analyser may not hear it. The sound check with the radio playing will tell. CarPlay playing (31 October, 2.43.2) has `isMusicActive` true, like Bluetooth on 28 October. The sound check itself has not run on the car yet: 2.43.3 was not published and those reports came from 2.43.2's music-sources check. - 2026-10-31 — App 2.43.3: **sound check** on the Logs tab (`SoundProbe`, `SoundLevels`), asked for before the Halloween pumpkin's light follows the music (owner: "make the light in the pumpkin react to the equalizer/sound of the music"). One tap: 10 seconds of levels from `Visualizer` on session 0 (peak, bass, mid, treble, rms), saved and sent like a recording; no sound kept, no microphone. New in the car build's manifest: RECORD_AUDIO and MODIFY_AUDIO_SETTINGS. Grounds for trying: Bluetooth played with `isMusicActive` true (28 October check), `libCarPlayPlatformAudio.so` uses AudioTrack and no direct PCM. Whether the analyser hears anything on the car is what this is to find out. Tested: unit tests, lint, emulator (silence says nothing was playing; a pulsing 110 Hz + 1 kHz test tone from another app is heard, peak 0.27–0.91, bass strongest, the tone kept playing, no prompt, no crash). Not tried on the car. - 2026-10-31 — App 2.43.2 published (`car-2.43.2`). - 2026-10-31 — App 2.43.2: Halloween's teeth are triangles hanging from the grin's upper lip, each in the colour of the rib behind it (the right one was the darker orange on the lighter rib; owner: "the color on the right side is off"). Two screenshots redone. Tested: unit tests, lint, emulator with sample values (drawing in panel and full screen, regenerating in full screen) and with no data. Not tried on the car. - 2026-10-31 — App 2.43.1 published (`car-2.43.1`). - 2026-10-31 — App 2.43.1: Halloween's bats can be seen. They were near-black and small on the darkest part of the sky, and the owner did not spot them; now a moonlit purple-grey with a light edge, a third larger. Two screenshots redone. Tested: unit tests, lint, emulator with sample values (panel and full screen) and with no data (no bats). Not tried on the car. - 2026-10-31 — App 2.43.0 published (`car-2.43.0`). - 2026-10-31 — App 2.43.0: Overview styles **Día de Muertos** (`MuertosView`) and **Halloween** (`HalloweenView`; owner: "let's design a 'dia de muertos' and a 'halloween' style"), each with its own palette (the papel picado's pink, the pumpkin's orange). Día de Muertos, an ofrenda and kept a celebration: papel picado = battery (one flag per 10 %), calavera with the speed on its forehead, a ring of marigolds = power (turquoise and anticlockwise regenerating), candles = range (one per 50 km), a path of petals = the last two minutes of power. Halloween: a jack-o'-lantern with the speed in its grin, burning yellow or, regenerating, green; an arch of embers = power; a potion flask = battery; a tombstone and bats = range; the hill = the last two minutes of power. What a value lights is `Tally` (pure, unit-tested: an unread value lights nothing). The static scene is drawn once per size into a bitmap (about 4.5 MB while the view is attached), so a frame only draws the readings; flags, flames, bats, bubbles and the ghost move only while the car moves. Tests and lint pass. Emulator with sample values, panel and full screen: normal, 12 % with regeneration, 40 % (the flask's words over the potion's surface); real build with no data: "—" and nothing lit. No crash of the app. Not tried on the car, so the frame rate on the head unit is unmeasured. - 2026-10-28 — App 2.42.1 published (`car-2.42.1`). - 2026-10-28 — App 2.42.1: **the music-sources check no longer connects to other apps' media services.** In the car, 2.42.0's check (14:26, Bluetooth music playing) made the head unit ask whether to allow access to media (the owner agreed) and **stopped the Bluetooth music**: it connected to every media browser service, and among them the AOSP car radio's (`com.android.car.radio/.RadioService`, which answered "connecting", most likely taking the audio) and the Local Media Player (`com.android.car.media.localmediaplayer`, whose permission request is most likely the question; it may now read media files). My claim that the check only read was wrong: binding another app's service starts it. Now the services are only listed. Nothing lost: the active sessions alone carried everything — **Bluetooth** (`com.android.bluetooth`: title, artist, album, duration, track, cover as a file path, playing) and **CarPlay** (`com.allgo.remoteui.mediabrowserservice`: title, artist, duration, paused) — readable with MEDIA_CONTENT_CONTROL, no connection needed. Services on the car: CarPlay's, Bluetooth A2DP, Local Media Player, the AOSP car radio, SAIC's radio (DAB, "Brillux Radio"), SAIC's USB 1/2 and online media, and SAIC's video browser. Tests and lint pass; not run on the emulator (stopped for low memory; the change only removes code); not tried on the car. - 2026-10-28 — App 2.42.0 published (`car-2.42.0`). - 2026-10-28 — App 2.42.0: **music-sources check** on the Logs tab (`MediaProbe`, `MediaProbeText`; owner: "is it possible to show playing music in our dashboard as well?", then "yes start the probe"). Before a now-playing display, it finds where the head unit tells what is playing, read only: the players Android's audio service reports (use, app, state), the active media sessions (`MediaSessionManager.getActiveSessions`, MEDIA_CONTENT_CONTROL, which the system user has) with their song, and every media browser service, each connected to, its session read and disconnected. CarPlay's is tried even when not listed: `com.allgo.remoteui.mediabrowserservice/.RemoteUIMediaBrowserService`, which the car's own media library (`com.saicmotor.sdk.media…MediaPlayControlManager` in Allgo's APK) reads CarPlay's title, artist, album and cover from through a plain `MediaBrowser`. Nothing of Allgo's is changed and nothing is played, paused or skipped. The report (`media-probe-YYYYMMDD-HHMMSS.txt`) goes where a recording goes, through the shared `SignalRecorder.saveCopies`: the app, a USB stick, the server (`fetch-logs`). Unit tests for the text; tests and lint pass. Emulator (Android 9): the players are read with their app and state (the system APIs answer the system user), the sessions are readable (none there, no SecurityException), the AOSP music app's browser service connects and is read, CarPlay's (not installed there) is "refused or failed", and the report lands in the outbox. **Not tried on the car.** Unknown until then: whether CarPlay's service lets the app connect, and whether the radio, Bluetooth and USB sources publish a session. - 2026-10-28 — First recordings over the server (14:19 and 14:23, app 2.41.0, ACC on, the set speed raised a few times): the server path works, and listening works in the car (249 assistance properties, 0 refused, 76 and 81 change events). `0x2160A15B` (`AAD_EPTCCTRGTSPD`) stays 0.0 even while listened to: the car does not fill it. `0x2140A15A` (3/7, a few 0s) and `0x2160A1A3`/`A1A4` (always equal, 1.4–5.3, now and then 0.1–0.2 down) do not move with the key presses. New lead: steering-wheel keys **297** (2× at 14:20:09, 2× at 14:20:12) and **300** (14:20:05, 2× at 14:20:40), the car speeding up 27 → 49 km/h after them; key 3 is Home. The 14:23 recording has no key at all. Not confirmed: which buttons these are. Also seen: `0x21401553`–`1556` ≈ 256 are tyre pressures and `0x2140155B`–`155E` (18–24) tyre temperatures, not the set speed. - 2026-10-27 — Skill `car-logs` (`.claude/skills/car-logs/SKILL.md`; owner: "can we write a skill for downloading the logs?"): fetch with `fetch-logs` without ever showing the token, what its errors mean, how a recording is laid out, the cuts that find a lead, the leads so far, and that recordings are never committed. Its commands tried on the 08:52 recording. - 2026-10-27 — Server 2.9.0 pushed (`sha256:c68837f0e53cfca150644987be535e04d5e999bd4c91064d40973db67235df48`, pinned in `k8s/server.yaml`); app 2.41.0 published (`car-2.41.0`). - 2026-10-27 — App 2.41.0, server 2.9.0: **recordings reach the server** (owner: "can we make it so that we can upload the logs to an endpoint in the server, and you can get the logs from there? that way i don't have to carry a usb stick"). A finished signal recording goes to `files/log-outbox` (`LogOutbox`, at most 10 waiting) and is sent at once, gzipped, with the car's token: `PUT /v1/logs/{name}`. Offline, 401 (not paired yet), 404 (a server without logs), 408, 429 or 5xx keep it, and the service's tick sends it again, at most every 2 minutes; any other refusal drops it. The Logs tab says "Sent to the server." or how many wait and why. Server (`logs.go`): `LOGS_DIR` on a new 1Gi volume `mg4-server-logs`, the newest 200 files and none older than 180 days, names as the app's only, up to 2 MB sent and 8 MB unpacked, UTF-8 only; the same name replaces itself. Reading (`GET /v1/logs`, `GET /v1/logs/{name}`) takes `LOGS_TOKEN`, a new optional Secret value that must differ from `INGEST_TOKEN`; the car's token cannot read, the read token cannot write. `fetch-logs` in the dev shell fetches the new ones into `logs/` (gitignored, as are the recordings copied into the checkout's top folder), token from `~/.config/nilsmg4/logs-token`. Tested: server unit tests (both tokens, refusals, pruning, config); the real server code in a harness on this machine took the 08:52 recording gzipped as the app sends it (204), refused the car's token for reading (401), and `fetch-logs` brought it back byte for byte, once. The app's own sending could not be pointed at that harness (the app takes https only); on the emulator the recording lands in the outbox and the Logs tab says it waits. Not tried on the car. - 2026-10-27 — App 2.40.4 published (`car-2.40.4`). - 2026-10-27 — App 2.40.4: **the recorder's listening works on Android 9**. Both recordings from the car (08:49 and 08:52, 2.40.3) said "listening to the assistance properties: not possible": `listenToProperties` looked only for `registerCallback`, Android 10's name; the car's car library (Android 9) has `registerListener(CarPropertyEventListener, int, float)` and `unregisterListener`, as the app's `CarPropertyAdapter` already knew. It now takes either, and unsubscribes property by property (Android 9's one-argument `unregisterListener` removes entries from the list it walks and would leave every other property subscribed). A failure now says why (`EVHardware.listenProblem`: no car service, no way to subscribe, or the exception). Tested with a stand-in manager of Android 9's shape (`PropertyListeningTest`). Correction to 2.40.3: the ignition listener it was compared with also looks only for `registerCallback`, so it most likely never subscribes on the car either (it reads the state once at start); left as it is. What the polled part of the two recordings shows of the block: `0x2160A15B` (by name the target speed) 0.0 throughout; `0x2140A15A` between 3 and 7 every few captures; `0x2160A1A3`/`0x2160A1A4` counting up by 0.1; speeds 8–33 km/h. Not tried on the car. - 2026-10-27 — App 2.40.3 published (`car-2.40.3`; also carries 2.40.1 and 2.40.2). - 2026-10-27 — App 2.40.3: **the signal recorder listens** (owner: "is there really nothing we can do about the readout of the cruise control set point"). The 2.32.0 recording only polled. The head unit's `CarAdvancedAssistedDrivingManager` never polls its 108 `AAD_*` properties: it registers a listener for each (`registerListener(…, 0.0f)`, on change), and a vendor HAL may fill a value from the car network only while someone listens — which would read as the defaults we saw. EVHardware gains `listenToProperties` (read only: the CarPropertyManager's `registerCallback` per admitted property, rate 0 for ON_CHANGE, 1 Hz within limits for CONTINUOUS, one proxy, `unregisterCallback` on close) and `AssistBlock` (global vendor properties `0x21x0A1xx`, which holds all 108 `AAD_*` ids; tested). The recorder subscribes to that block for its 3 minutes; `SignalRecording.event` counts every event and puts value changes on the timeline; the file and the Logs tab list the properties heard, those with changing values first ("heard …"). Emulator (no car service): the recorder notes that listening is not possible, records, saves the new section; no crash. The subscription itself is the same reflection as the ignition listener that works on the car, but untried on the car. - 2026-10-27 — App 2.40.2: **the map moves on the GPU** (owner: "is the map screen gpu accelerated? it looks a bit slow on update"). It was hardware-rendered, but every frame (20 a second) recomputed every road point on the main thread, rebuilt all paths, and drew the big roads three times for the glow; and the car jumped with each GPS fix (1 Hz). Now the map is its own view under the Grid (`MapLayerView`, `LAYER_TYPE_HARDWARE`): drawn once into a GPU texture round an anchor and only redrawn when tiles come or go or the car is ~280 layout units (≈230 m) from the anchor; each display frame (`postOnAnimation`, only while that style is on screen and the map shows) sets its translation, pivot and rotation, which the GPU composites. The car glides towards each fix (eased, snaps beyond 200 m), the heading eases; GridView over the map no longer animates itself (only the readings redraw it), the "far roads fainter" sort is a fixed dark gradient towards the top. Layer size on the car about 2500 px square (~25 MB). Measured on the emulator: with SwiftShader (software GPU) old and new both ~57 ms a frame, and with the host's Intel GPU (`-gpu host`) both run at the display rate (~18 ms) — the emulator is too fast to show the car's slowness, so the gain on the head unit is reasoned, not measured. Not tried on the car. - 2026-10-27 — App 2.40.1: **an update that downloaded but never reached the installer** (owner: "sometimes … downloads the update but then doesn't start the installer"). The car refuses the installer session ("Not allowed to install non-system apps on internal storage"); only a refusal thrown at once led to the installer screen. A refusal that came back through the session's result was a toast and nothing else. Now any answer but success, the confirmation and the driver's own cancel opens the installer screen with the verified APK (path and session id ride on the result intent; `goAsync` for the copy), a confirmation that cannot be shown does too, and a session silent for 20 s is abandoned for it. Emulator, with a throwaway build whose session bytes were damaged (refused later, status 4 `INSTALL_PARSE_FAILED_NOT_APK`) and which read the update from Downloads: the installer screen opened by itself, Install, now 2.40.1; the update log shows every step. The 20 s watch is untested (no way to make a session stay silent). Not tried on the car. OTA.md updated. - 2026-10-27 — App 2.40.0 published (`car-2.40.0`). - 2026-10-27 — App 2.40.0: **Grid with map straight from above, full height** (owner: 2.39.2 "does not look right"; wanted the map over the whole height and fully top-down). The map is the whole background in map mode: orthographic, heading up, 1.2 layout units per metre (about 400 m ahead, 125 m behind, 450 m to each side on the car's screen), the car 150 units above the bottom edge; ground grid every 50 m fixed to the ground; roads from 250 m ahead fainter; the camera, the sky and the floor are gone there. The speed moves to a panel under the gears (120 units), and the battery wall, the clock, the gears and the disc get dark panels. The plain Grid is unchanged. Emulator with the Berlin tiles, both layouts. Not tried on the car. - 2026-10-27 — App 2.39.2 published (`car-2.39.2`). - 2026-10-27 — App 2.39.2: **Grid with map seen from higher up** (owner: the map looked like a fish-eye; wanted it more top-down). The map has its own pinhole camera now: 45° down, 300 m up, the car on its axis just above the read-outs, the top of the floor about 420 m ahead (scale there ~60 % of the car's, before ~1/20 at 900 m); the floor starts at half height in map mode and the speed is 170 instead of 210 units; the floor's grid becomes a ground grid (a line every 50 m, fixed to the ground, turning with the roads); roads from 250 m ahead fainter; the power disc gets a dark backing over the map. Emulator with the Berlin tiles, both layouts. Not tried on the car. - 2026-10-26 — Server 2.8.0 image pushed and pinned in `k8s/server.yaml` by digest `sha256:8b8d94e0562833d196162866b7fdc6910d5dd219f6eb84572d4d5c91b74f7ff1` (checked with skopeo); app 2.39.1 published (`car-2.39.1`). Not applied yet: the owner applies it. - 2026-10-26 — App 2.39.1 and server 2.8.0: **the map's roads come from OpenFreeMap, on demand.** In the car, server 2.7.0 logged `overpass answered 502`, `overpass could not be reached`, and the owner saw 429s: the public Overpass limits per IP, and a tile takes it ~40 s while the car gives up after 8 s (`ServerHttp.TIMEOUT_MS`) — the server then cancelled the query, threw the work away, and the car's retries added to the load. Owner's choice: fetch only the tiles the car asks for (a self-hosted Overpass would need a whole region imported). Server: the zoom-14 OpenStreetMap vector tile (OpenMapTiles schema) from the TileJSON at `MAP_TILES_URL` (default OpenFreeMap, free, no key, no limits; its template re-read every 6 h, https only), decoded by our own minimal protobuf/MVT reader (`mvt.go`, the `transportation` layer; classes motorway/trunk, primary/secondary, tertiary, minor), simplified as before. A fetch runs to its end without the car (requests wait ≤ 6 s, then 503 with `Retry-After: 10`), at most two at once, one per tile; tiles kept 30 days in `MAP_CACHE_DIR` (a 1 Gi volume `mg4-server-maps`, pod `fsGroup` 65532) and the last 300 in memory; `OVERPASS_URL` is gone. Tests with an encoded vector tile and a fake tile host (classes, split lines, scaled extent, malformed tiles, gzip from the host, fetched once and kept across a restart, a slow fetch finished for the next try, failures not cached and no tile in the log, http template refused, config). Real: the 9 Berlin tiles in 0.7 s (9–15 KB each). App 2.39.1: "OpenFreeMap © OpenMapTiles · © OpenStreetMap contributors" on the map, a tile the server did not have yet is asked for again after 15 s (was a minute). Emulator with those tiles: same roads as before. Not tried: the deployed server and the car. - 2026-10-26 — Server 2.7.0 image pushed (`git.stinnesbeck.com/nils/mg4-server:2.7.0`, Go 1.27.3, govulncheck clean) and pinned in `k8s/server.yaml` by digest `sha256:e5da9452a9dbdfabe3340766cc51f18bb1418b2588ab534714550470abe1ce29` (checked with skopeo); manifests valid (kubeconform). Not applied yet: the owner applies it. - 2026-10-26 — App 2.39.0 and server 2.7.0: **Grid with map**, a new Overview style — the Grid over the roads round the car from OpenStreetMap (owner's choice of design: roads through the car's own server, drawn as the floor). Server: `POST /v1/map/roads` `{z:14, x, y}` (the tile, not the position, and in the body so it stays out of access logs) fetches the tile's drivable roads from Overpass (`OVERPASS_URL`, default the public instance, `off` disables; https only; one request at a time, ≥ 1 s apart, identifying User-Agent), turns them into tile-local points in 4 classes simplified with Douglas–Peucker (~1.5 m), caches them in memory (30 days, 3000 tiles; failures not cached), gzips when accepted, answers 503 when Overpass fails and never logs the tile. Tests with a fake Overpass (classes, split at missing points, simplification, cache, gzip, validation, 503 without caching, no tile in the log, config). App: `MapRoads` keeps the 3×3 tiles round the car (files/map, 30 days, 400 tiles; one at a time on a background thread; a failed tile waits a minute), `RoadTile` parses them failing closed, `MapGeometry` does the web-mercator arithmetic (both tested). GPS only while that style is shown and the app is in front; the bearing from the GPS, or worked out from positions 8 m apart when it gives none. `GridView` with a map draws the roads in the floor's perspective, heading up, 40 m floor steps, up to 900 m ahead, far roads fainter, the car as a chevron, its position run on with the speed between fixes, 20 fps while moving; the trail gives way to the map; "© OpenStreetMap contributors" shown; otherwise the plain floor saying why (waiting for GPS, set up the server, loading, not available). `OVERPASS_URL` in `k8s/server.yaml`; LICENSE.md notes the ODbL. Tested: server unit tests; one real fetch of 3×3 tiles in central Berlin through the server code (20–30 KB each; Overpass answered 502 a few times and the retry got them); on the emulator those tiles from the app's cache with emulator GPS, north up and turning with a simulated drive, both layouts, no GPS, no server; no crash. Not tried: the app fetching tiles from the deployed server (not deployed yet) and anything on the car. - 2026-10-26 — App 2.38.0 published (`car-2.38.0`) and installed on the car through the in-app updater, from 2.35.3 (so Grid, Time circuits, Quest, Visor and Empire are on the car). - 2026-10-26 — App 2.38.0: Overview styles **Visor** (after Halo's helmet display, `VisorView`) and **Empire** (after Age of Empires' interface, `EmpireView`). Visor: shield bar = battery (24 segments, red and blinking "BATTERY LOW" below 20 %), ammunition counter = range (number and rounds, one per 10 km), P R N D as grenade slots, a reticle with the speed and power round it (green and anticlockwise in regen), a motion tracker whose blips are the power trail (rim 60 kW, 40 kW regen) and whose sweep turns only while moving (~30 fps, on screen only), the clock and an objective panel; original blue or the accent colour (`hasOriginal`). Empire: a wooden resource bar (battery, range, power, 5-min usage, the age, the clock), an isometric world whose ground and trees move with the speed (6 m tiles, ~30 fps only while moving), the car as the selected unit with the battery as its health bar, the speed large over the world, a carved panel with P R N D as commands, the unit's portrait and stats, and a diamond minimap with the odometer and the way to the next age; ages by odometer in `EmpireAge` (pure, tested: Dark, Feudal from 10,000 km, Castle 30,000, Imperial 60,000); its own palette, the app in the player's blue. `stylePanes` is now built from the canvas list. THEMES.md with two screenshots each. Emulator: sample values, 15 % at a standstill, with and without the navigation, and no data (dashes); no crash. Not tried on the car. - 2026-10-26 — App 2.37.0: Overview styles **Time circuits** (after Back to the Future, `TimeCircuitsView`) and **Quest** (after World of Warcraft's interface, `QuestView`); both with their own palette, the app in red and gold with them. Time circuits: three LED rows in a metal panel with embossed tape — red "DESTINATION" (gear as DRV/REV/NTL/PRK, charge, range, power/regen lamps, usage), green "PRESENT TIME" (date and time from the head unit's clock), amber "LAST TIME DEPARTED" (when the car last left P, tracked from the readings, dashes until seen); the speed in red digits, a flux capacitor whose light runs inwards with the power and outwards in regen; at 88 km/h the speed burns white, the tape reads "88 KM/H — HOLD ON" and the capacitor flashes. Letters on fourteen segments (`Segments14`, pure, tested). Quest: player frame (gear as level, battery as health, power as energy), minimap with the clock, gold speed, a cast bar (Accelerating, Regenerating, Coasting, Resting in P), a road-trip quest tracker, system chat lines, P R N D action buttons, the odometer as experience (a level per 1000 km), a "Low battery!" raid warning below 20 %. Names avoid the trademarks; drawings and fonts are the app's own. THEMES.md with two screenshots each. Emulator: sample values (also 92 km/h and 15 %), with and without the navigation, and no data (dashes); no crash. Not tried on the car. - 2026-10-26 — App 2.36.0: Overview style **Grid**, after the Tron films (`GridView`): neon lines on black, a perspective grid floor that runs towards the driver with the speed (4 m tiles, ~30 fps only while moving and on screen), the speed large and thin, the battery as a 20-segment light wall standing on the floor (orange below 20 %, "LOW ENERGY"), power on a disc (zero at the top, clockwise drawing, anticlockwise regeneration; an inner ring that turns with the power), the last two minutes of power as a light-cycle trail of right angles (`ClusterValues.powerTrail`, the Cockpit's `PowerTrace`; gaps stay gaps), P R N D tiles, the clock, and five read-outs in cut-corner boxes. Glow from layered strokes (no blur filters). Original cyan, or the accent colour (`hasOriginal`; low battery then white); in Original the app turns cyan (`ThemeOverlay.EV.Style.Grid`). Named "Grid", not after the films. THEMES.md has it with two screenshots. Emulator: sample values (full screen, with navigation, accent, 15 %), the floor moving between frames, and no data (dashes, nothing lit, still floor); no crash. Tests and lint. Not tried on the car. - 2026-10-25 — Server 2.6.2: **the update relay logs what it hands out**, per car (installation ID, or "shared token"): `update check` with the number of releases and the newest pre-release, `update download started` with file and size, then `update handed out` with bytes and time, or `update download cut short`; refusals by the forge name the car too. No forge address or token in the log (tested: `TestUpdatesAreLogged`). Go 1.27.3 (build image and `go.mod` toolchain), up from 1.26.9: `govulncheck` had found GO-2026-6809 (compromised intermediate certificates, `crypto/x509`, reached through the server's TLS); now no vulnerabilities, in the source and in the built binary. go vet, tests, podman build. Pushed as `mg4-server:2.6.2` (`sha256:e4de1e75…`, checked in the registry) and pinned in `k8s/server.yaml`. Applied by the owner, together with the real `FORGE_TOKEN`: the car then updated itself to 2.35.3 over the air (owner, 2026-10-25). - 2026-10-25 — `k8s/influxdb.yaml`: the values Kubernetes fills in itself are written out — the NetworkPolicy port's `protocol: TCP`, and `apiVersion`, `kind` and `volumeMode: Filesystem` on the StatefulSet's volume claim template. Without them every `kubectl apply -k k8s/` reported both as "configured" while `kubectl diff -k k8s/` was empty (owner). Applied by the owner: both now "unchanged". Validated offline (kustomize + kubeconform). Also found: the in-app update check failed with an IOException because the cluster's `FORGE_TOKEN` was still the template placeholder — the forge refuses it and the server answers 502; `apply -k` does not include the Secrets, so a new token needs `kubectl apply -f k8s/secrets/secrets.yaml` and a restart. - 2026-10-25 — App 2.35.3: a car build with the English EVHardware (comments, log lines, the "Layer" names); no change in behaviour. Emulator: starts, no crash, the log reads "Layer1: …" to "Layer5: …". Not tried on the car. - 2026-10-25 — EVHardware in English: the French comments (and the half-translated ones like "l'screen", "registersment", "initialisesd") in `EVHardware.kt` and five test files, the French log messages ("aucun init() fonctionnel", "introuvable", "state initial", "ERREUR"), the French test names and assertion messages (`CatalogConsistencyTest`, `GlassEvidenceTest`, `GlassProbeTest`). Comments, log texts and test names only: no code changed (checked in the diff). Kept on purpose: the French translation `values-fr/strings.xml`, place names in test data, the quoted French sentence in `ChargeStopPlan` and the voice phrase in `SaicNavGuidance`, and "Katman" (Turkish for layer), which named the layers in function names and logs — renamed to "Layer" right after (`whenLayer1Ready`, `initLayer4Swi69`, `Layer5: …` in the log, and so on; nothing outside EVHardware used the names). EVHardware, app tests and lint pass. - 2026-10-25 — README.md brought up to date: the tab screenshots retaken with 2.35.2 on the emulator right after installing (`screenshots/nilsmg4-2.35.2-*.png`, the 2.18.1 ones removed), "read-only" now names the drive mode exception, the upload frequency matches the app (1 min by default, 15 s at low battery, 15 min parked), and the Settings and Logs rows list what is there now (Overview style, drive mode, signal recorder). - 2026-10-25 — App 2.35.2: the full-screen button is round. Its disc was an even inset in a 64 × 72 dp (narrow: 64 × 76) area, so an oval; the area is now a square 72 × 72 dp (inset 18 dp, a 36 dp disc), pulled 8 dp into the panel's padding in the wide layout so "MG4" keeps its line. **THEMES.md**: the twelve Overview styles, each with and without the navigation (`screenshots/themes/`, 1920 × 720 from the emulator with sample values from a throwaway build, never committed), with what inspired each and how it takes colour; linked from README.md (Screenshots, Contents, Project documents) and AGENTS.md. Emulator: the round button, the header with "MG4" on one line. Not tried on the car. - 2026-10-25 — App 2.35.1: **Aviation removed** (owner's choice: `AviationView`, its palette and string; a stored "AVIATION" opens Tiles). The Sci-fi palette for the app is now the lilac of the console frame's lower elbow (`scifi_lilac` #CC99CC) instead of the orange of the upper one. Tests and lint; emulator: Sci-fi with the lilac navigation. Not tried on the car. - 2026-10-25 — App 2.35.0: **the app takes on the style's own colours.** While the Overview style shows its own palette — Sci-fi, Cartoon, Aviation and Nixie always, Retro and Terminal with "Original" — the navigation, buttons, switches and titles take that palette instead of the accent colour: Retro turquoise (`retro_lit`), Terminal green phosphor, Sci-fi orange, Cartoon orange, Aviation cyan, Nixie neon orange (`StylePalette`, overlays in `res/values/style_palettes.xml`, laid over the accent overlay in `onCreate`; a style or colour choice that changes the overlay recreates the activity, as an accent change did). The accent colour stays stored for the styles that use it. **Blueprint and Mascot removed** (owner's choice): `BlueprintView`, `MascotView`, `MascotMood`, `MascotCharacter`, `ChibiBase`, `ChibiFigure`, `FoxFigure`, their strings and the Mascot field on Settings; a stored "BLUEPRINT" or "MASCOT" opens Tiles. Fix: the navigation (`nav_bar`) no longer saves view state — it is a ScrollView in the wide layout and a LinearLayout in the narrow one, and restoring one into the other crashed when the width changed (seen on the emulator only; the car's width does not change). Tests (`OverviewStyleTest`: palettes per style, removed styles) and lint; emulator: each palette, the switch to Retro recolouring at once, the width change. Not tried on the car. - 2026-10-25 — `styles-retro-future` (app 2.23.0–2.34.1) merged into `main` (merge commit `aff79cb`, the summary as its message). Work goes on `main` again. - 2026-10-25 — App 2.34.1 (branch `styles-retro-future`): the Overview's full screen without the app's full screen. With the car's bars shown, the car's own sidebar sits at the left edge, so a swipe from the edge lands on it, not on the app (owner, on the car). There a small tab now sits at the app's left edge instead of the faint handle (48 × 96 dp touch area, a dark tongue with ›): a tap brings the navigation back, and so does a swipe starting in the app's first 56 dp (`tabSwipe`). In the app's full screen nothing changed (handle and edge swipe, the owner's preference: least clutter). Switching Full screen on Settings updates it at once. Emulator: the tab shows, a tap and a swipe on the left strip both bring the navigation back. Not tried on the car. - 2026-10-25 — App 2.34.0 (branch `styles-retro-future`): **drive mode at start.** The car falls back to its own default mode when switched on; with "Set at start" (on by default, the switch in the drive mode card) the app sets the mode last chosen on Settings again. Only a choice the car confirmed counts (`PREF_CHOSEN`, saved on APPLIED). `AbrpUploadService` starts with the head unit and runs `DriveModeWrite.atStart` (pure, tested) once a second on its own thread: wait for gear, speed and mode; nothing when the car already reports the mode; one write, in P at 0 km/h, through the same `DriveModeSetter` as the buttons (write, read back up to 3 s); give up for this start as soon as the car is out of P or moving, or after 2 minutes. So a mode set with the car's own button after driving off stands. The result is kept with its time and shown under the buttons ("At start (25.10. 20:31): Sport set."). Assumes the head unit starts (and the service with it) when the car is switched on; a start without that (head unit kept running) is not caught. A service restart (app update, after a kill) counts as a start, still only in P at 0 km/h. Hints shortened to fit the page. Emulator: page fits, the start check waits and gives up (no readings), no crash. Not tried on the car. - 2026-10-25 — App 2.33.0 (branch `styles-retro-future`): **drive mode from Settings**, the first vehicle setting the app writes. The owner lifted rule 3 for the drive mode only (AGENTS.md). A card at the top of Settings' second column: Eco, Normal, Sport, Snow, Custom (codes 2, 3, 4, 6, 7 at `0x2140A17C`; the 2.32.0 recording read 2, Eco). The lit button is the mode the car reports, from every 0.2 s reading. A tap reads gear and speed fresh and writes only in P at 0 km/h (`DriveModeWrite`, pure and unit-tested; unreadable gear or speed is a refusal), through the new `EVHardware.writeDriveModeProperty`: the CarPropertyManager write behind `VehicleWriteGate` (0 km/h, supported firmware), without `setDriveMode`'s fallback binder transaction. Then the mode is read back for up to 3 s, and the status beside the title says what the car reports ("set", "not applied: the car still reports …", "could not be read back"). One change at a time, on the settings thread; each attempt goes to logcat. To fit the page, the wide layout's charging price row moved into the battery card ("Battery and charging price"). Emulator: the card fits, a tap is refused (no gear or speed there). Whether the car takes the write at all is untested: the first try on the car decides. - 2026-10-25 — App 2.32.1 (branch `styles-retro-future`): the cruise control work ends. The ACC recording of 2.32.0 (ACC set to 101, 90 and 80 km/h, a car ahead) found nothing: see "Signals the car does not provide". Removed: `CruiseLog` and its section on the Logs tab, and in EVHardware the set-speed read (`getCruiseTargetSpeedRaw`, `EnergySnapshot.cruiseTargetSpeedRaw`), `readAccDebug` and `ReadFailureLog.reason` — EVHardware is again as before 2.27.3. The old log files are deleted on start. The recorder stays as a general tool, renamed **Signal recorder** (`SignalRecorder`, `SignalRecording`, `signal-recording-