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.
69 lines
3.0 KiB
Bash
69 lines
3.0 KiB
Bash
#!/usr/bin/env bash
|
|
# Build, install and run the Android Auto prober, then print what it saw.
|
|
#
|
|
# bash tools/auto-prober/probe.sh # depth 2, the ordinary root
|
|
# bash tools/auto-prober/probe.sh 3 true # depth 3, the RECENT root
|
|
#
|
|
# This installs a SECOND app on the phone — com.soulstream.autoprober, about
|
|
# 50 KB, no permissions, no network, no storage, no UI. `adb uninstall
|
|
# com.soulstream.autoprober` removes it completely. It never signs in,
|
|
# downloads, joins a room, writes the config or touches the library; the only
|
|
# thing it force-stops is SoulStream, which the phone walk already does.
|
|
#
|
|
# Gradle comes from the GENERATED project's wrapper on purpose: that pins
|
|
# Gradle 8.14.3, AGP 8.11.0, Kotlin 1.9.25 and JDK 17, all of which are
|
|
# already in Kyle's Gradle cache, so this downloads nothing new. There is no
|
|
# gradle-wrapper.jar in this directory and there should not be one.
|
|
set -euo pipefail
|
|
ROOT=/f/Coding/SoulStream
|
|
cd "$ROOT"
|
|
source src-tauri/android/env.sh
|
|
|
|
DEPTH="${1:-2}"
|
|
RECENT="${2:-false}"
|
|
# A media id here plays it instead of walking the tree — the only way to prove
|
|
# a car's tap without a car. The run takes ~25s because the claim being tested
|
|
# is that the SECOND track starts on its own.
|
|
PLAY="${3:-}"
|
|
APK=tools/auto-prober/prober/build/outputs/apk/debug/prober-debug.apk
|
|
GRADLEW="$ROOT/src-tauri/gen/android/gradlew.bat"
|
|
|
|
test -f "$GRADLEW" || { echo "no generated Android project — run a normal build first"; exit 1; }
|
|
|
|
echo "== this installs com.soulstream.autoprober on the phone (adb uninstall com.soulstream.autoprober removes it)"
|
|
echo "== gradle $(date +%T)"
|
|
(
|
|
cd tools/auto-prober
|
|
MSYS_NO_PATHCONV=1 "$GRADLEW" :prober:assembleDebug -q 2>&1 | grep -v "^$" | tail -20 || true
|
|
)
|
|
test -f "$APK" || { echo "no prober APK — gradle's tail is above"; exit 1; }
|
|
ls -la "$APK"
|
|
|
|
echo "== install $(date +%T)"
|
|
"$ADB" install -r "$APK" > /dev/null
|
|
|
|
echo "== cold: force-stopping SoulStream $(date +%T)"
|
|
"$ADB" logcat -c
|
|
"$ADB" shell am force-stop com.soulstream.app
|
|
"$ADB" shell am start -W -n com.soulstream.autoprober/.ProbeActivity \
|
|
--ei depth "$DEPTH" --ez recent "$RECENT" --es play "$PLAY" > /dev/null
|
|
if [ -n "$PLAY" ]; then sleep 25; else sleep 7; fi
|
|
|
|
echo
|
|
echo "== the probe (one JSON object per event)"
|
|
"$ADB" logcat -d -s SoulAutoProbe:I
|
|
|
|
echo
|
|
echo "== the root, as the service saw it"
|
|
"$ADB" logcat -d -s SoulStream:I | grep "auto root" | tail -3 || echo " (no root line — the callback was never reached)"
|
|
|
|
# androidx/media #3158: a host that binds with nothing playing can put the
|
|
# service in a create/destroy loop at ~30 Hz. The singleton in MediaHub means
|
|
# nothing is allocated per cycle, but the loop itself is Android Auto's bug
|
|
# to fix — so this number is the thing to watch, and it is why those two
|
|
# lifecycle log lines exist at all. One or two is normal.
|
|
echo
|
|
echo "== androidx/media #3158: how many times the service was built"
|
|
"$ADB" logcat -d -s SoulStream:I | grep "auto service created" | tail -1 \
|
|
|| echo " (no creation line — the service was never built)"
|