KeelrLeek
f50cf2018a
Android Auto starts this app by binding a service. There is no Activity, no WebView, no `tauri::AppHandle` — and until now no way to make a sound, because the engine lived in Tauri's managed state. `src-tauri/src/headless.rs` moves it into a `OnceLock` owned by the PROCESS: whoever needs audio first builds it, `playback::init` on a normal launch or a car tapping a row into a process with no UI, and everyone after that gets the same one. **That singleton is the whole safety story.** `Player::spawn` opens an output stream, so two of them in one process is two AAudio streams playing over each other — the failure this module exists to make impossible. The event receiver is single-consumer, so the pump lives there too and offers a subscription slot for the WebView to claim when it finally appears, rather than a second engine being stood up beside the first. The queue here is deliberately not the app's queue. The JS one keeps shuffle, repeat, `alts` failover, provenance and the three-ahead preload; this is a vector and an index whose only job is that the album keeps playing when there is no JS alive to advance it. Its metadata is read ONCE, when the queue is built, so advancing never touches the database again — which matters when the thing advancing is a background thread in a process with no UI. Resolution happens in Rust, against the library, read-only. A tapped `ss:track:<id>` brings its whole album at the right index, because selecting one song and getting silence after it is not what a record does. Nothing trusts a URI from the controller: the tree only ever publishes `ss:` ids, so there is no file path for anyone to hand back, and an id that resolves to nothing returns a count of zero rather than a guess. Kotlin's half is three things that each fail invisibly on their own. `COMMAND_SET_MEDIA_ITEM` is advertised now — without it a browse row is drawn as playable and does nothing when tapped. `onAddMediaItems` passes ids through instead of media3's default `UnsupportedOperationException`, which kills the tap before it reaches the player. And `handleSetMediaItems` does the work on its own thread, because the first tap in a cold process opens a database AND starts an audio engine, and it is called on the application thread where ten seconds is an ANR. **Two things the device taught, both of which looked like silence.** The headless path has to request audio focus itself: the first run showed a live AAudio track on our uid, decoding perfectly, with `PortMuted=true` and the gain at `-inf` — audible to nobody. On the WebView path the JS asks for focus; a car tapping a cold process has no JS to ask. And it has to write the card itself: `getState()` mirrors `MediaHub.state`, which only the WebView ever fills, so the second run played audio while the session still reported `STATE_NONE` with no title — a head unit showing a blank player over music. The engine knows what it started, and that now goes into `MediaHub.update` in the shape the card already reads. Proven by the prober, which gained a `play` mode for it: bind cold, issue `playFromMediaId` through the session token the browser handed back — Auto's own path, not an interface of ours — and read the state back. `ss:track:1` answers `queued=13` (the album behind it), and the controller reports `state=3` with the title and a position moving 3.8 s → 11.8 s → 19.8 s across the run. `probe.sh <depth> <recent> <mediaId>` is the invocation. **Not done, and it is the display rather than the audio.** Nothing tells Kotlin when the fallback queue advances, so the card will keep showing track one while track two plays. The position moves on its own — `SimpleBasePlayer` extrapolates it while playing — but a track change and a seek both need the pump to push, and the pump currently only speaks to a subscriber that exists when there is a WebView. The handover the design asks for (a UI arriving over live headless playback, and exactly one queue driver surviving) is untested for the same reason.
66 lines
4.0 KiB
Plaintext
66 lines
4.0 KiB
Plaintext
android auto: a tap in the car plays, with no Activity anywhere in the process
|
|
|
|
Android Auto starts this app by binding a service. There is no Activity, no
|
|
WebView, no `tauri::AppHandle` — and until now no way to make a sound, because
|
|
the engine lived in Tauri's managed state. `src-tauri/src/headless.rs` moves it
|
|
into a `OnceLock` owned by the PROCESS: whoever needs audio first builds it,
|
|
`playback::init` on a normal launch or a car tapping a row into a process with
|
|
no UI, and everyone after that gets the same one.
|
|
|
|
**That singleton is the whole safety story.** `Player::spawn` opens an output
|
|
stream, so two of them in one process is two AAudio streams playing over each
|
|
other — the failure this module exists to make impossible. The event receiver
|
|
is single-consumer, so the pump lives there too and offers a subscription slot
|
|
for the WebView to claim when it finally appears, rather than a second engine
|
|
being stood up beside the first.
|
|
|
|
The queue here is deliberately not the app's queue. The JS one keeps shuffle,
|
|
repeat, `alts` failover, provenance and the three-ahead preload; this is a
|
|
vector and an index whose only job is that the album keeps playing when there
|
|
is no JS alive to advance it. Its metadata is read ONCE, when the queue is
|
|
built, so advancing never touches the database again — which matters when the
|
|
thing advancing is a background thread in a process with no UI.
|
|
|
|
Resolution happens in Rust, against the library, read-only. A tapped
|
|
`ss:track:<id>` brings its whole album at the right index, because selecting
|
|
one song and getting silence after it is not what a record does. Nothing
|
|
trusts a URI from the controller: the tree only ever publishes `ss:` ids, so
|
|
there is no file path for anyone to hand back, and an id that resolves to
|
|
nothing returns a count of zero rather than a guess.
|
|
|
|
Kotlin's half is three things that each fail invisibly on their own.
|
|
`COMMAND_SET_MEDIA_ITEM` is advertised now — without it a browse row is drawn
|
|
as playable and does nothing when tapped. `onAddMediaItems` passes ids through
|
|
instead of media3's default `UnsupportedOperationException`, which kills the
|
|
tap before it reaches the player. And `handleSetMediaItems` does the work on
|
|
its own thread, because the first tap in a cold process opens a database AND
|
|
starts an audio engine, and it is called on the application thread where ten
|
|
seconds is an ANR.
|
|
|
|
**Two things the device taught, both of which looked like silence.** The
|
|
headless path has to request audio focus itself: the first run showed a live
|
|
AAudio track on our uid, decoding perfectly, with `PortMuted=true` and the gain
|
|
at `-inf` — audible to nobody. On the WebView path the JS asks for focus; a car
|
|
tapping a cold process has no JS to ask. And it has to write the card itself:
|
|
`getState()` mirrors `MediaHub.state`, which only the WebView ever fills, so
|
|
the second run played audio while the session still reported `STATE_NONE` with
|
|
no title — a head unit showing a blank player over music. The engine knows what
|
|
it started, and that now goes into `MediaHub.update` in the shape the card
|
|
already reads.
|
|
|
|
Proven by the prober, which gained a `play` mode for it: bind cold, issue
|
|
`playFromMediaId` through the session token the browser handed back — Auto's
|
|
own path, not an interface of ours — and read the state back. `ss:track:1`
|
|
answers `queued=13` (the album behind it), and the controller reports
|
|
`state=3` with the title and a position moving 3.8 s → 11.8 s → 19.8 s across
|
|
the run. `probe.sh <depth> <recent> <mediaId>` is the invocation.
|
|
|
|
**Not done, and it is the display rather than the audio.** Nothing tells Kotlin
|
|
when the fallback queue advances, so the card will keep showing track one while
|
|
track two plays. The position moves on its own — `SimpleBasePlayer`
|
|
extrapolates it while playing — but a track change and a seek both need the
|
|
pump to push, and the pump currently only speaks to a subscriber that exists
|
|
when there is a WebView. The handover the design asks for (a UI arriving over
|
|
live headless playback, and exactly one queue driver surviving) is untested for
|
|
the same reason.
|