KeelrLeek
f59a2d773e
**Pausing looked like the track restarting, and it was not only a look.** The card carried the position it was BUILT with — zero, on the headless path, because nothing wrote it again. media3 extrapolates a position while playing, so the bar moved and seemed right, but every state rebuild snapped back to that stale zero. Worse than cosmetic: media3 then BELIEVED the player was at zero, and reconciled on resume by seeking there, so the track really did start again. The same staleness made a seek look like it had done nothing — the engine moved and the next rebuild reported zero. `getState()` asks the engine now, on every rebuild, through `positionMs()` and `sounding()`. One JNI call and always true, instead of a number remembered from the moment playback began. A seek moves the reported position immediately rather than waiting for the engine's next event, so the scrubber does not lag a beat behind and read as snapping back. **Search, which is the half of round fifty-two that needed no decisions.** `onSearch` answers the count and `onGetSearchResult` the rows; both run the same couple of LIKEs over the library, because there is no search index in this schema and a few hundred albums do not need one. Albums rank before tracks: "play Discovery" almost always means the record, and whoever wanted the song would have said more — which matters because a voice command takes the first result. Voice comes in by a different door and it is implemented too. "Play X" arrives at `onAddMediaItems` as an item with NO media id and a `searchQuery` instead; Google's own samples disagree about whether Auto uses that or `onSearch`, so both are answered. An empty query is "play some music" and gets Recent rather than an error. The prober gained a `search:` prefix for it — `probe.sh 2 false "search:discovery"` issues `playFromSearch` through the session token, which is the path a spoken sentence actually takes. It answers `auto voice 'discovery' n=1`, `auto play ss:album:2 queued=14`, and the controller reports "One More Time" playing: a sentence turned into a record, in a process with no Activity. Still library-only, and that is now the whole remaining question. Playlists are local and would play from cold exactly as albums do, blocked only on which four root slots to spend. Catalog and Soulseek rows cannot resolve without the WebView, but can whenever the app is warm — browsable always, an honest error only when cold.
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.