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.
43 lines
2.5 KiB
Plaintext
43 lines
2.5 KiB
Plaintext
android auto: a catalog row is handed to the app, not failed at
|
|
|
|
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.
|