KeelrLeek
8f46f9c663
Every entry in a streamed playlist is `kind='stream'` with no file on this phone — only a catalog id. A service-only process cannot turn that into audio: the resolver is hundreds of lines of shared JS that exist while a WebView does and not otherwise. So the car tapped those rows and nothing happened, which is the worst of the three possible answers. Now the process asks whether the APP can do it instead. Rust, finding nothing local, reports WHICH playlist and entry were meant rather than just failing — a catalog row is not a broken row, it is one this process cannot do alone, and that difference is what decides between an error and a hand-off. Kotlin carries it over `MediaHub.onRemote`, which is non-null only while the plugin is loaded, which is only while a WebView exists: the same fact is both the channel and the test for "is the app warm". And the JS plays it with `playFrom(playlist, items, item)` — the exact call the half-sheet makes when the same row is tapped in the app, so the queue, the provenance and the failure message are the app's own. Nothing about the car is special once it arrives. Cold, it says so instead of pretending: the focus is handed back rather than held for silence, and the log names the row. A phone in a pocket genuinely cannot play a Deezer id, and a tap that quietly does nothing is worse than one that stops. Two things the same change fixed on the way past. A streamed entry has no cover FILE, only a remote URL, so `COALESCE(art_path, art_url)` gives those rows their sleeves and a remote uri now goes to the host untouched instead of through a FileProvider whose root check it could never pass. And Recent, playlists and an artist's albums join Albums as GRIDS — all four are things known by the picture, which is what the grid is for. `probe.sh` gained `SS_KEEP=1`, without which the warm path cannot be tested at all: the script force-stops SoulStream, which is precisely the app the hand-off needs alive. **Proven:** cold answers `auto cold, cannot resolve` and releases focus; warm answers `auto hand-off to the app` and the event reaches the JS with no console error. **Not proven:** that the audio then starts. Those Deezer ids have to go through the resolver exactly as they do when tapped in the app, and if the app cannot play them the car will not either — which is correct behaviour and indistinguishable, from here, from a bridge that silently failed. It wants checking with the app in front of you.
handoff/ — the Android port's pending work
Saved 2026-09-14 when the session ended. Nothing here is on main; main holds
only rounds that were built, walked on the device and committed.
rounds/— every round's patch script and commit message, and the insertion files they read. Rounds 43 to 48 are written and verified but not yet shipped; 49 is incomplete (authoring was stopped mid-flight). The earlier ones are kept because a patch is the record of how a round was made.tools/— the pipeline.preflight.shapplies a wave in order to a throwaway copy;chain.shpatches and ships a list of rounds;reset-tree.shputs the tree back after a failure (a plaingit checkout --leaves new files behind and trips the round's own re-run guard);compare-walks.shandbaseline-mock-steps.txtare the A/B for the unverified adaptive-wait change;audit-commands.cjslists backend commands the phone never calls.notes/— the Android Auto design in full, and the icon background comparison mock (openicon-mock.htmldirectly; it needs no server).
Start with ../HANDOFF-2026-09-14-android-auto-and-icon.md.