android-v0.7.4

Bump to v0.7.4: cross-check Spotify release years against MusicBrainz…

android-v0.7.3

Bump to v0.7.3: further review fixes (Nearby callback ownership, tunn…

android-v0.7.2

Bump to v0.7.2: follow-up review fixes (identity, IPv6 SSRF, Nearby l…

android-v0.7.1

Bump to v0.7.1: Android reconnect/permission fixes and server hardening

Bundles the fixes from the last three commits (Android state-machine
regressions from the code review, and the server security/robustness
fixes plus their new test coverage) into a release.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

android-v0.7.0

Formalize connection/session state with Tinder/StateMachine, enable R8

Two live-tested bugs this session traced back to the same root cause:
state tracked as scattered, ad hoc booleans (discoveryActive,
connecting, manualDisconnect, isHosting, connectedEndpointId used as a
proxy for "connected") that could drift out of sync with each other —
e.g. MainActivity showing a stale "reconnecting…" message because
nothing reset it once the underlying peer had actually gone idle.

Replaces that bookkeeping with com.github.Tinder:StateMachine:0.3.0
(resolved via JitPack — not on Maven Central despite what some
mirrors list; see settings.gradle.kts) in the three places with a
genuine multi-step lifecycle:
- NearbyPeer: connection lifecycle (idle/discovering/connecting/
  connected/active/reconnecting/given-up) — discovery gets its own
  small machine rather than being folded into the connection states,
  since a device can legitimately be discovering AND connecting to a
  different host at the same time.
- NearbyHost: advertising/retry-attempt state.
- MainActivity: screen mode (idle/hosting/discovering/connecting),
  replacing the isHosting boolean and an untracked "connecting" text
  mutation with an actual ConnectingToHost state.

Deliberately NOT applied to HostForegroundService — its "state" already
is the Android Service lifecycle enforced by the OS itself.

Side effects (the actual Nearby Connections/view calls) stay exactly
where they were; only the state bookkeeping moved into the machines,
verified against the pre-refactor behavior end to end on two physical
devices (host + Nearby guest): full game round, playlist import, and
notification-triggered stop-hosting mid-game, all producing identical
outcomes to before the refactor.

Also enables R8 minification for the release build type
(isMinifyEnabled = true, previously off), with proguard-rules.pro
keeping the WebView JS bridge (@JavascriptInterface methods) and
NodeRuntime's external JNI method — both resolved by name at runtime,
both silently broken by naive minification otherwise. Verified on
device: the JS bridge (getControlToken via the playlist-management
screen) and JNI (embedded Node actually starting) both still work
correctly under the minified build.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

android-v0.6.3

Fix WebView error flash on quick game entry, and a stray Nearby recon…

android-v0.6.2

Fix guests seeing a raw disconnect instead of "host stopped" on stop

Two bugs, both from 0.6.0's move to a hard Process.killProcess() on
stop:

1. HostForegroundService.onDestroy() called nearbyHost.stop() BEFORE
   telling the server to notify guests. A Nearby peer's connection is
   tunneled over Nearby Connections itself, so tearing that transport
   down first killed the tunnel before the server ever got a chance to
   push 'hostStopped' through it — a Nearby guest only ever saw a raw
   disconnect. Reordered: notify first, then tear down Nearby.

2. Even with that fixed, the Kotlin side blocking on the HTTP response
   only proved server.js's handler function had returned quickly, not
   that guests actually received anything — sock.send() returning
   doesn't confirm delivery. /api/local/host-control now waits (up to
   500ms per socket, in parallel) for each socket's own 'close'
   confirmation before responding, turning the Android-side wait into
   one tied to an actual completion signal. Bumped the Kotlin-side
   timeout from 1.5s to 2.5s to comfortably cover that.

Verified in-browser with a real WebSocket guest connection: the
'hostStopped' message arrives 2ms before the socket's close event, and
the whole host-control round-trip (which now waits for that close)
completed in 8ms.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

android-v0.6.1

Fix playlist import missing local-control-token auth on Android

importPlaylist() used a raw fetch() instead of the shared api()
helper, so it never attached X-Local-Control-Token — the Android
host's own "Manage playlists" import button hit requireAdmin with no
credential at all and failed with "admin functions not configured"
(ADMIN_PASSWORD_HASH isn't set for local/Nearby play, so there was no
password to fall back to either). Verified in-browser: same request
now passes both requireAuth and requireAdmin (reaches the actual
gzip-parsing code instead of being rejected at the auth gate).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

android-v0.6.0

Run the embedded host server in its own process for a real "stop host…

android-v0.5.8

Fix "Stop hosting" not returning to the start screen and breaking res…