202 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	43e3c7b69f	feat(ci/android): play-upload can attach release notes and promote a build ... Two things it could not do, both needed now that a tag ships to production. Release notes: it never sent `releaseNotes`, so Play's "What's new" was whatever the previous release said. It now takes --release-notes-file, and refuses text over Play's 500-char-per-language cap with the actual count — that check has to happen before the upload, because the API only rejects it at commit, by which point the AAB is already on Play. Promotion: --promote assigns a versionCode that is already on Play instead of uploading, so what reaches production is the byte-identical artifact the testers ran. Rebuilding would mint a fresh versionCode from possibly-newer sources and ship something nobody tested. --promote-from asserts the code really is on that track (a typo'd versionCode now fails before it touches production) and clears that track in the SAME edit, so the build is never active on both at once. --user-fraction comes along because --status inProgress is an API error without it; it is validated as strictly between 0 and 1 rather than left to Google. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 09:29:04 +02:00
enricobuehler	2d3f9f8690	Merge remote-tracking branch 'origin/main' into audio/mic-latency-echo	2026-08-01 00:54:20 +02:00
enricobuehler	951bcec650	Merge remote-tracking branch 'origin/main' into audio/mic-latency-echo	2026-08-01 00:47:50 +02:00
enricobuehlerandClaude Fable 5	badda070ef	docs(android): the stats-array KDoc counts the doubles it actually returns ... nativeVideoStats grew to 33 with the decode split and the overflow counter, but its own KDoc still promised 30 and StatsOverlay still said 26 — a count that was already two extensions stale before this one. Both now list the full index set, with the JNI KDoc named as the authoritative one so the next extension has a single place to update. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:47:04 +02:00
enricobuehlerandClaude Fable 5	f9c56eaf5c	feat(android): Automatic prefers AV1 where the silicon says it should ... The P3 format A/B (NP3 ↔ RTX 4090, identical conditions) measured AV1 ~1.2 ms faster end-to-end than HEVC with slightly better codec-pure decode time. Under "Automatic" the client now sends AV1 as its soft preference when this device hardware-decodes it (the advertised AV1 bit is already gated on a real, non-blocked hardware decoder) AND it lacks FEATURE_PartialFrame — a partial-frame device keeps HEVC, whose slice-progressive overlap AV1 cannot ride (no slices, the chunked poll never arms). The host honors the preference only inside its probed shared codec set, so an AV1-less encoder still resolves HEVC, and an explicit user choice wins unchanged. The codec picker caption mirrors the same rule so "Automatic" says what it does on this device. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:40:58 +02:00
enricobuehlerandClaude Fable 5	b69ef02f4d	fix(android): a cold-start connect no longer loses HDR or the native mode ... A punktfunk:// deep link can reach the connect before the activity is attached to its display; context.display then throws and the display probes silently fell to their worst answers — displaySupportsHdr advertised SDR (the whole session pinned to 8-bit BT.709) and nativeDisplayMode fell back to 1080p60. Seen live on the NP3: one cold connect advertised hdr=false, the warm retry true, nothing in the log either way. Both probes now share probeDisplay: the context display when attached, else DisplayManager DEFAULT_DISPLAY — which IS the panel on phones and TVs; the activity-display distinction only matters on multi-display setups, where the attached path still wins whenever available. Each fallback leg logs itself, so a downgraded session can never again be silent about why. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:40:58 +02:00
enricobuehlerandClaude Fable 5	849baea881	feat(android): the stream re-votes its refresh rate and touches keep their curvature ... surfaceChanged re-asserts the frame-rate vote (FIXED_SOURCE; ALWAYS only on the TV low-latency path, mirroring the native hint) — a buffer-geometry change on some OEM builds silently drops the 120 Hz pin mid-stream. Touch passthrough and direct-pointer moves forward the MotionEvent historical samples before the current point, so a fast swipe lands with its real shape; the trackpad path keeps summed deltas on purpose — its acceleration curve is tuned for per-frame dt and historicals would change the feel, not the sum. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:40:58 +02:00
enricobuehlerandClaude Fable 5	c767a904d2	feat(android): the decode stage answers where its time goes, HUD on or off ... P3 decode science: every AU is stamped as its last piece enters the codec, so the decode stage splits into feed (received→queued: hand-off + input-slot wait) and codec (queued→decoded: the decoder alone — a slice head start would show here). The split + an always-on capture→decoded e2e ride the 1 Hz pf-present line, so a wireless HUD-off A/B reads everything from logcat; the HUD equation gains the split (indices 30/31), the skipped counter tells benign newest-wins pacing from parked-AU overflow (32), and a −2-refresh Apple-HUD-equivalent twin makes iPhone comparisons honest (Apple shaves its OS floor; Android shows raw). Connect now logs the per-mime decoder picks + FEATURE_PartialFrame verdicts (tag pf.caps) — on the NP3 all three c2.qti low-latency decoders say no, so parts delivery never arms and P2d is inert there; a debug.punktfunk.force_parts sysprop overrides the probe for the on-glass question the API cannot answer. Forced on glass: c2.qti accepts PARTIAL_FRAME pieces without erroring but only assembles them — codec time unchanged, so the overlap is dead on SM8735 either way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:40:58 +02:00
enricobuehlerandClaude Fable 5	8e877ad25f	fix(android): a mute is a pause, not a hole the host tries to conceal ... The Android uplink kept advancing `seq` while muted, so the first frame after an unmute looked to the host like loss the width of the mute. The de-jitter reads that as a gap: up to five concealment frames of stale voice, and a seq gap counted in the uplink-health line. Past 600 ms the pump's stale flush resets the chain first and hides it, which is why the usual long mute looks fine — a quick toggle does not. Freeze `seq` while muted, as the desktop uplink already does, so the frame after an unmute continues the chain. `reset_stream` says it plainly: a pause is not loss, and must not conceal or count a gap. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 23:15:03 +02:00
enricobuehlerandClaude Fable 5	253e0bbe7c	feat(android): the mic has an off switch you can reach mid-stream ... Wave 1 gave the Android client a mic worth using. It gave it no way to stop talking: leaving the stream, or digging through Settings to turn the whole feature off, were the only ways to stop the room being heard. Now a tap (or Select + Y on a pad) mutes it, and the screen says so while it lasts. How muting gates the capture, and why that way. The AAudio input stream is never stopped: a stop/start would re-run the input-preset fallback ladder and re-prime the buffers on every toggle — hundreds of milliseconds, and possibly a landing on a different rung, silently losing the HAL echo canceller wave 1 went to some trouble to get. Instead the encode loop reads an AtomicBool per 10 ms frame and, while it is set, drains the frame out of its ring and drops it there — the last point before it would have become an Opus packet. Nothing is encoded, nothing is sent, and the realtime capture callback is untouched, so its allocation-free discipline and the queue policy stay exactly as wave 1 verified them. A toggle costs one atomic store and takes effect on the next 10 ms boundary. The frame counter keeps advancing across a mute, because it numbers the captured 10 ms TIMELINE rather than the datagrams. The gap the host then sees is exactly the audio that never came: its de-jitter conceals at most a few frames of it before the pump's 600 ms stale-gap flush resets the chain outright, which is the right reading of a mute. Encoding silence instead would have kept a pointless uplink and a host-side ring alive for its whole duration. Mute is per session and nothing is persisted — a new stream always starts unmuted, and no new setting exists. The flag lives on the session handle rather than on the capture, so the mic stop/start a surface recreate performs brings the user's choice back with it, with no window in which the fresh capture could send an unmuted frame. The control is offered on the evidence that a capture is actually running (nativeMicActive), not on the setting: with the mic disabled, RECORD_AUDIO denied, or every AAudio input rung refused, there is nothing on screen to lie about. On touch it is a pill in the corner the stats HUD doesn't use — the one in-stream control, so it sits above the gesture layer to take its own taps — dim while live, a red "Muted" badge while it isn't. On TV that badge is the indicator alone: Select + Y is the control there, and a focusable button would fight the game for the D-pad. Y is deliberately not one of the exit chord's buttons, so neither chord can be reached through the other. One honest consequence of keeping the stream open: the platform's recording indicator stays lit while muted, because the mic really is still open. What stops is the encode and the send. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 22:41:09 +02:00
enricobuehlerandClaude Fable 5	a681de7e5c	feat(android): the mic goes through the echo canceller, and the host stops hearing itself ... The capture stream opened under AAudio's default VoiceRecognition input preset, which deliberately bypasses the HAL's acoustic echo canceller — so a phone playing the game audio out of its own speaker fed that audio straight back to the host. Two layers fix it, both behind a new "Echo cancellation" setting (default ON, next to the Microphone toggle in the touch and console settings, per-profile like every tier-P setting): - Native: the mic opens under the VoiceCommunication preset (HAL AEC/NS on the capture path) and allocates an audio session id. The open ladder is Exclusive+voice → Shared+voice → Exclusive → Shared — some HALs refuse the preset or a session id outright, and a mic without echo cancellation still beats no mic; the last rungs are exactly the preset-less open this always did. - Kotlin backstop: nativeStartMic now returns the allocated session id (0 = none), and StreamScreen hangs the Java AcousticEchoCanceler + NoiseSuppressor off it (guarded by isAvailable), releasing them on every mic-stop path — the surface teardown and the final dispose — so a surface recreate re-attaches instead of leaking effect engines. The playback stream is untouched: retagging it voice/communication would route it through the phone-call chain and regress quality. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 21:53:01 +02:00
enricobuehlerandClaude Fable 5	a7d4213778	feat(android): the mic uplink drops to mono 10 ms frames, and stops hoarding stale audio ... Latency, three ways, all inside mic.rs: - 48 kHz stereo 20 ms becomes mono 10 ms: speech gains nothing from a second channel, the shorter frame shaves a buffering interval off the uplink, and the host already decodes any Opus frame <= 120 ms with its stereo decoder (mono packets upmix) — no protocol change. The encoder follows: 48 kbps, complexity 5, in-band FEC at an assumed 10% loss so a dropped datagram reconstructs from its successor instead of a hole. - The latency ratchet is gone: the capture callback drops the NEWEST chunk when the hand-off channel fills, so an encode-side stall used to convert into standing mic delay that never drained. The encode loop now drains the whole backlog in one lump and, past ~60 ms, jumps to the newest ~20 ms (one audible blip, live again), counting what it shed in the periodic log line. The realtime callback stays exactly as allocation-free as it was. - The encode thread registers with the client's hot-thread set, so the ADPF session keeps mic encode on a fast core alongside audio decode. No .frames_per_data_callback() pin: AAudio's own docs say leaving it unset is the lowest-latency path (the callback runs at the device's optimal burst), and the encode side re-chunks to 10 ms frames anyway. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 21:46:44 +02:00
enricobuehlerandClaude Fable 5	7cf71dd218	feat(clients): the Apple deadline presenter reports its latch phase ... Phase-locked capture had no client half on Apple — the host's v3 controller (grid-locked submits, coherence-gated engage) shipped with only the Android reporter feeding it. Now the stage-4 link thread flushes the same v2 circular arrival-phase statistic at ~1 Hz: - PhaseReporter (Stage2Pipeline): the decode callback deposits per-AU reassembly-completion stamps, the CAMetalDisplayLink update deposits the latch grid (period = window-min of update spacing), and the flush ports punktfunk_core::phase::circular_latch verbatim — a period-smeared Wi-Fi link reads coherence ≈ 0 and the host correctly never engages; a wired link opens the gate. Binds/unbinds per session like DecodeReport. - PunktfunkConnection.reportPhase wraps the existing ABI entry point. - Hello honesty: iOS/tvOS advertise CLIENT_CAP_PHASE_LOCK (macOS stays without — the stage-2 arrival presenter has no latch grid), Android now sets the bit its reporter already earned, and the ABI grows the PUNKTFUNK_CLIENT_CAP_PHASE_LOCK mirror const (header regenerated). Advisory in v1: the host arms on report receipt. - Stage-3 doc comment no longer calls itself the tvOS default (stage-4 took that over in the 2026-07 rebuild). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 17:41:46 +02:00
enricobuehlerandClaude Fable 5	c002ca8746	fix(clients): pen batches split at the wire cap and the heartbeat survives tracking mode ... Three drawing-path defects on the pen clients: - The Apple in-range heartbeat was re-armed on every emit (~120 run-loop mutations/s during a stroke) and lived in .default run-loop mode only — a tracking-mode excursion >200 ms with a stationary pen crossed the host's force-release failsafe and dropped the held stroke. Now one long-lived 50 ms timer in .common mode, resending only after ≥50 ms of send silence. - Both clients TRUNCATED an over-8-sample coalesced run instead of splitting it into consecutive batches (the send_pen contract): Apple suffix(8) dropped the oldest samples, the Android JNI clamped count. An over-cap run means the UI thread hitched — exactly when dropping stroke geometry hurts most. Apple splits in emit(); the Android JNI loops send_pen over ≤8-sample chunks (Kotlin's per-emit ceiling is now 64 = a >250 ms stall). - The iOS letterbox mapper did a lock+FFI currentMode() read per coalesced sample on the main thread, contending the ABI lock the batch send takes next — now a 250 ms TTL cache (mid-stream requestMode still tracked). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 17:41:15 +02:00
enricobuehlerandClaude Fable 5	780791ed81	feat(android): the presenter's latch margin starts at zero and earns its width ... The 2.5 ms submit margin ahead of expected present assumed SurfaceFlinger latches well before the vsync. On-glass (NP3, 120 Hz) that lead is not needed: with the margin at zero every release still made its vsync (paced=0 across full sessions) - meaning the constant was 2.5 ms of pure display latency on every frame, and it was quantizing away exactly the readiness gains the slice-overlap pipeline just bought. e2e on the Linux-host pairing dropped from 22-24 ms to 14-18 ms. The margin is now adaptive instead of assumed: it starts at 0 and only widens (+500 us per 1 Hz window, capped at the old 2.5 ms) when the paced counter shows real latch misses - one-way per stream, so a margin that proved necessary is never re-gambled mid-session. A device that needs lead converges within seconds; a device that doesn't keeps the full win. debug.punktfunk.latch_margin_us (0..=8000) pins the margin for rebuild-free sweeps, and the presenter logs the resolved mode at stream start. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 17:34:31 +02:00
enricobuehlerandClaude Fable 5	4240b76182	feat(android): slices feed the decoder as they arrive, not when the AU closes ... The decode loop used to hold every access unit until its last wire packet landed. With slice-progressive delivery (frame_parts) each newly contiguous piece now goes straight into MediaCodec under BUFFER_FLAG_PARTIAL_FRAME, the closing piece drops the flag, and the decoder chews the front of the frame while its tail is still on the wire. Feeding partial input means owning its failure modes without a codec flush: a broken sequence (dropped piece, orphan, oversize) closes the dead AU with an empty non-partial buffer at its own pts, arms the re-anchor freeze so the concealed output never reaches glass, and requests a recovery keyframe - the same machinery ordinary loss already rides. Per-AU accounting keeps its units: the RFI gap detector notes an AU once, and the HUD stamps, host/network split and the phase-lock arrival sensor ride only the completing delivery. The opt-in is decoder truth and loop truth: every decoder this device would use must pass FEATURE_PartialFrame, and only the async loop may see parts - the legacy sync loop feeds whole AUs and stays that way. Smoke-checked on-glass (NP3 vs the Windows host): byte-identical degenerate path, presenter profile unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 17:34:31 +02:00
enricobuehlerandClaude Opus 5	de8430097e	chore(clients): the bundled licence notices catch up with the root file ... The Apple and Android apps carry their own copy of THIRD-PARTY-NOTICES.txt and show it on the acknowledgements screen. `7fc2775f` refreshed the root file but not the copies — running the python generator directly skips the sync `scripts/gen-third-party-notices.sh` does — so they had drifted to a 531-crate snapshot that predates the whole vendored-source section. That section is where the OS marks' attribution lives, so both apps have been shipping Font Awesome's CC BY 4.0 icons with no attribution visible at all. Re-synced, which also carries the Bazzite Apache-2.0 notice the previous commit adds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 14:17:02 +02:00
enricobuehlerandClaude Opus 5	5520167958	feat(clients): the OS marks tell gaming distros apart, and Windows looks current ... Three things were wrong with the host-card OS icons. The Windows mark was Font Awesome 5's, which is still the Windows 8/10 flag with the perspective skew — dated next to the flat four-pane mark Microsoft has shipped since Windows 11. No icon set has the current one (Simple Icons carries no windows/microsoft slug at all), so it is drawn here: four equal squares at the authentic 11.377 + 1.246 proportion. The Decky plugin was pulling FaWindows straight from react-icons, so it now inlines the masters like the web console does, or it would have kept the old flag regardless. Bazzite, CachyOS and Nobara collapsed onto their family's mark. The host already advertises the full chain, so this is purely missing art: all three now ship a leaf mark, because "a Bazzite box" and "a Fedora box" are different machines to the person reading the card. CachyOS and Nobara come from Simple Icons; Bazzite has no icon anywhere, so its "b" is lifted out of the project's own badge (Apache-2.0, attributed). On Android every non-square mark was stretched. A VectorPainter maps the viewport onto the ImageVector's default size with independent x and y scales, so declaring a 448x512 Tux as 24x24 dp squashed it — silently, no crash, no warning. The longest viewport edge now sets the 24 dp box and the other follows the ratio, which is what Icon()'s ContentScale.Fit expects. A unit test pins the invariant; every other client was already correct. Also: scripts/gen-os-icons.sh replaces the undocumented hand-run pipeline that turns a master into the GTK symbolic SVG, the Windows PNG and the Apple template PDF. It reproduces the committed artifacts byte-identically. Verified: web and Decky typecheck, Decky bundles, Android compiles and its tests pass, PunktfunkKit builds, osinfo's tests pass. Not verified on glass, and the GTK/Windows client crates do not build on macOS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 14:17:02 +02:00
enricobuehlerandClaude Fable 5	f4f83202cb	feat(core/client): an AU's prefix reaches the decoder while its tail is on the wire ... Delivery used to be all-or-nothing: the decoder saw byte 0 only after the last packet of the AU landed, so the whole transmit time sat in front of decode. With the slice-streamed wire (previous commit) blocks now arrive addressable, and a client can opt in (connect's new frame_parts) to receive each AU's newly-contiguous prefix as Frame::part pieces - offset tiling, first/last marked, the completing push carrying only the suffix. A PARTIAL_FRAME-capable decoder then chews slices concurrently with the remaining network transfer. The reassembler walks a per-frame cursor over successfully-completed blocks (failed FEC reconstructs don't advance it), coalesces blocks that finished out of order into one part, keeps probe filler whole, and stops short of the final block so the zero-padded tail still trims at completion. Whole-frame consumers see byte-identical behavior - parts never flow without the opt-in, and never on PyroWave (its newest-wins draining assumes whole AUs). Per-AU accounting keeps its units: OWD/ABR feeds, the inter-arrival series and the clock-based jump-to-live detector only count completing deliveries, and FrameChannel::depth() counts AUs so a part-rich queue can't trip jump-to-live at a fraction of the real backlog. The consumer contract (gap or orphan part = AU lost: abandon, flush, resync on the next first) is documented on FramePart; the C ABI keeps parts off until PunktfunkFrame can express them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 14:14:46 +02:00
enricobuehlerandClaude Fable 5	43868af1f5	feat(android): the client advertises multi-slice tolerance per-decoder ... The P0 gating branch deliberately left Android off VIDEO_CAP_MULTI_SLICE ("embedder-set decoder truth") — this is that deferred item, and the P2 slice-pipeline prerequisite. VideoDecoders.multiSliceTolerant() probes the pick for every advertised codec: tolerant unless any pick is an Amlogic decoder (the 0.17.0 device-rebooting wedge) or uninspectable (a null pick = platform default → conservatively single-slice). nativeConnect carries the bit; the JNI ORs it into the Hello's video_caps beside the panel-truth HDR bits. Phones (Qualcomm/Exynos) advertise it; the Amlogic TV boxes the gate exists for never will. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 14:14:46 +02:00
enricobuehlerandClaude Fable 5	759aac255b	feat(phase-lock): controller v3 — grid-locked submits, arrival sensing, antipode damping ... Midday on-glass falsified v2's remaining assumptions: a per-frame additive hold SATURATES the arrival-slaved loop once hold + work >= interval — submits free-run at their own cadence and the commanded phase dissolves (measured: +-2 ms hold steps, zero client response) — and the latch statistic hovers at the target's ANTIPODE, where shortest-way errors sign-flip on noise (the 0<->2<->4 ms offset chatter). v3, one change per falsified assumption: - ACTUATOR: submits lock to an absolute grid (epoch + k x period + offset); the controller walks only the offset. A periodic grid cannot free-run — occupancy is one frame per period whatever the offset — so phase actuation is linear BY CONSTRUCTION. Disengaged = no grid sleeps = zero cost; every failure path DISENGAGES (never parks: v2's e2e-tax lesson). - SENSOR: the client reports the circular mean + coherence of the ARRIVAL lead (per-AU reassembly stamps vs the panel latch grid) — the phase the host actually controls; latch measured downstream of the decoder pipeline, which absorbed the actuation. pf.phase logs "arrival lead circ= coh=". - ANTIPODE DAMPING: errors within 1 ms of +-period/2 take half-steps until they commit to a side. Harness rewritten around plants glass validated: a GRID plant (linear by construction), the DECOUPLED plant (v2's saturation — must disengage, not orbit or park), an antipode start (must converge within one period of travel), incoherence (never engages), a regime change (re-engages after backoff), and the actuator's own periodicity/offset-linearity. Also fixes the harness's SIM_TARGET (a mis-derived max asserted 3.5 ms where the controller's actual target is 2.5 — the controller was right, the ruler was wrong; the Python cross-check inherited the same constant, a lesson in replicating the CODE, not the author's belief about it). Gates: v3 simulations 6/6; host bin suite 345/1 (the documented environmental qemu UDP test); clippy --all-targets -D warnings clean; cargo ndk arm64 check clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 12:20:39 +02:00
enricobuehlerandClaude Fable 5	4457356ee4	test(phase-lock): a closed-loop simulation harness — both on-glass failures become CI regressions ... The controller iterated twice on the user's gaming PC before this existed; never again. punktfunk_core::phase::circular_latch is extracted from the Android presenter (shared: iOS reports next, and the harness generates its synthetic reports through the IDENTICAL statistic the clients ship), with unit tests including the wrap-straddling cluster an arithmetic mean gets maximally wrong. The stream.rs harness models the plant — latch = (base − hold + noise) mod P, deterministic LCG noise — and drives PhaseController::adjust through five regimes: - tight jitter locks into the deadband within ~5 adjusts and stops moving; - a wrap-side start takes the SHORTEST way (travel < P/2 asserted); - an incoherent phase never steps (zero hold, ever); - a v1 pinned-median report trips the travel budget and DECAYS TO ZERO — the 2026-07-31 orbit and the parked-hold e2e tax, both as asserts; - a post-decay regime tightening re-locks. Gates: host bin suite 344 passed / 1 failed = the documented environmental qemu UDP-loopback test (clean main fails identically in this container); core phase tests 4/4; clippy --all-targets -D warnings clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 11:18:30 +02:00
enricobuehlerandClaude Fable 5	fe552a50bb	fix(android): the phase reporter actually sends the v2 circular statistic ... The v2 client edit missed its anchor against rustfmt's reshaping and the reporter kept sending the v1 median — caught by the arm64 build the moment the tuple signature landed. Sends (circular mean, coherence) now. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 10:58:19 +02:00
enricobuehlerandClaude Fable 5	1d31e4c565	feat(phase-lock): controller v2 — circular phase, coherence gate, decay-to-zero ... Round-1 on-glass falsified two v1 assumptions in one morning (NP3 ↔ .173): - A median lead is immovable under period-spanning jitter (uniform mod P), so v1 orbited the period at 2 ms/s forever — and the dead-signal freeze hotfix never armed, because ±1.5 ms of window sampling noise kept resetting its 'error responded' check. Thresholds can't referee noise. - A HELD hold is not free: it delays sampling after the capture stamp, taxing e2e by up to a period (user-measured: ~+4 ms during the orbit). The correct failure response is DECAY TO ZERO, never freeze-in-place. v2, all three layers: - Wire: PhaseReport grows a length-discriminated coherence tail (27-byte form; the u16::MAX sentinel encodes as the byte-identical 25-byte v1 — strict-prefix discipline, both forms pinned by tests). - Client: the reporter sends the CIRCULAR vector-mean latch phase mod the panel period + its coherence (‰); pf.present logs circ=/coh=. - Host: steps only while coherent (floor 300‰; a v1 report bypasses the gate), along the signed SHORTEST way around the period, under a cumulative 1.25-period travel budget that is noise-immune by construction (it integrates applied steps, not reported errors); incoherence or budget exhaustion decays the hold to zero and re-arms once flat. Deadband convergence resets the budget — tight regimes lock exactly as designed. report_phase + the C ABI mirror gain the coherence parameter (canary-only ABI, hours old, sole caller in-tree). Gates: docker amd64 clippy --all-targets -D warnings (host+core, nvenc) clean; core suite 244/244; cargo ndk arm64 check clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 10:55:24 +02:00
enricobuehlerandClaude Fable 5	a5896f0883	feat(android): the phase-lock ACK is logged — the closed loop reads out in logcat ... The host's applied hold rides the 0xCF tail but nothing client-side showed it; 'adb logcat -s pf.phase' now logs transitions. This line is what exposed the dead-median controller orbit on the first on-glass run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 10:12:56 +02:00
enricobuehlerandClaude Fable 5	fa822744ff	feat(core/host/android): phase-locked capture — frames arrive on the client's latch schedule ... The host's capture tick and a client's panel vsync are independent ~120 Hz oscillators; their drifting phase sweeps every frame's wait-for-latch across a full refresh period (measured on-glass: latch p50 oscillating 5.4-8.9 ms with a fixed margin) — the beat is the residual judder and the fat p95, and no client can fix it alone. Design: punktfunk-planning design/phase-locked-capture.md. Protocol (punktfunk-core): - PhaseReport (control 0x32, next to the clock family): the client's next display latch ALREADY CONVERTED to host clock (the skew offset lives only client-side), panel period, uncertainty, and the measured median arrival-lead — the controller's error signal. ~1 Hz, latest-wins. CLIENT_CAP_PHASE_LOCK advertises it; CtrlRequest::Phase + report_phase() + the C ABI mirror carry it. - The 0xCF host-timing tail grows a phase ACK (applied_phase_ns, 29-byte form) under the same strict-prefix append discipline — old readers parse the shorter forms; degradation pinned by tests. Host engine (arrival-slaved loop — no backend can move the source vsync, per the tick-ownership audit in the design doc): - PhaseCtl bridges control task → encode loop (the fec_target pattern, multi-field). PhaseController walks a per-frame HOLD before submit toward the client's reported lead hitting target = max(2.5 ms, uncertainty+1ms): 1 Hz adjust, 2 ms max step, 300 µs deadband, period-wrapping (the newest-wins capture slot makes a wrapped hold sample fresher content, not staler). A loop local, so every mid-stream rebuild keeps the lock; a new session re-acquires. PUNKTFUNK_PHASE_LOCK=0 disarms. Android reporter: the presenter's 1 Hz pf.present flush returns the window's measured latch p50; the async loop converts the vsync clock's next timeline monotonic→realtime→host and reports. Inert toward old hosts. Gates: docker amd64 clippy --all-targets -D warnings (host+core, nvenc) clean; core suite incl. the new wire tests; cargo ndk arm64 check/clippy clean. On-glass A/B vs the .173 host owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	f9faab780e	tune(android): the latch margin drops to SF's real lead (2.5 ms) ... Each ms of submit-margin is a ms on every frame's display stage; SF's latch runs ~1-2 ms before present and the release is a sub-ms binder call, so 4 ms was padded. Measured (A024, 120 Hz game load): latch p50 8-10 → 5.4-8.9 (phase-drift dependent), paced stays 1-5/s. A device that misses at this margin shows it as a paced-counter rise, not stutter — the widen signal. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	a6ff0350e4	feat(android): frames target SurfaceFlinger's latch, not the GPU-render deadline — display 21→9.5 ms ... The remaining ~21 ms display stage was the conservative release target: the presenter aimed at the first frame timeline whose DEADLINE was still ahead, and the platform's deadline budgets for GPU rendering the app has yet to submit (presDeadline = 11.3 ms on the A024 — more than a full 120 Hz period). A decoded video buffer has no GPU work left; its only real constraint is SurfaceFlinger's own latch lead. Every frame paid a whole extra refresh of waiting for a budget it never used. next_target now gates (and subdivides) on the timeline's EXPECTED PRESENT minus a 4 ms latch margin; the glass budget reopens at that latch instant (expected present − margin) rather than the deadline, which under the aggressive gate can already lie in the past — an instant reopen would let two releases pile onto one vsync. A mis-gamble presents one vsync later, which is exactly what the deadline gate paid on every frame — the trade is one-sided. On-glass (A024, 2800×1260@120 HDR, game load): latch p50 21→8-10 ms, display 26,3→9,5 (pace 0,8 + latch 7,7), e2e 43,7→26,4 p50 / 29,2 p95, released=displays=120, paced≈0, forced=0. The latch now sits under one refresh interval — the vsync-latch floor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	984f7be896	fix(android): the presenter paces to the panel's real grid, not the app's down-rated vsync ... On-glass (A024, 120 Hz panel, 120 fps session) the first presenter build released only 60/s and the HUD display term hit 40 ms. Root cause, in two layers: Android down-rates a game-category uid's choreographer stream to 60 Hz (frame-rate categories / game default frame rate), and under that override Display.getRefreshRate REPORTS THE OVERRIDE — so the presenter's panel grid read 16.67 ms on an 8.33 ms panel and the subdivision became a no-op, pacing the video at half rate and dropping every other frame. Three-part fix, verified live on the same device: - Kotlin passes the panel rate from the supported-modes TABLE (MainActivity.streamPanelFps — the mode list is not override-filtered) instead of display.refreshRate, and votes the app's render rate up via View.requestedFrameRate = streamHz (API 35+) while streaming. - The native vsync clock LEARNS the panel period from observed timeline spacing (downward-only: the finest spacing SurfaceFlinger ever reports is the true grid) and next_target subdivides the reported timeline onto it — full-rate on down-rated devices, a no-op where callbacks match the panel. - OnFrameRendered display/latch samples get the e2e clamp (0..10 s): a vendor's first callbacks can carry a garbage system_nano (observed: an epoch-sized latch max) that would poison every max it lands in. pf.present gained panelMs next to vsyncMs, and a one-shot cadence diagnostic logs Δ/timelines/spacing/panel on the third tick. After: released=120 displays=120 paced=0, pace p50 <1 ms, latch p50 ~16 ms idle / ~22 ms under game load (2 refresh intervals at 8.33 — the same composited-pipeline law the Apple client measured), HUD display ~17-26 ms vs 40 before. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	e08fd91cd1	feat(android): a timeline presenter — frames reach glass on the panel's schedule, not decode's ... The Android port of the Apple client's stage-4 deadline discipline, closing the side-by-side feel gap (both clients 120 Hz; Android released decoded buffers the instant they appeared, with zero vsync awareness — the latch phase inherited every network+decode jitter and bursts queued behind the display). The presenter (async loop only; the sync loop stays the untouched escape hatch behind the Low-latency toggle): - decode/vsync.rs: an AChoreographer thread (dlsym'd like the other above-floor symbols) publishing the panel's vsync grid + frame timelines (postVsyncCallback, API 33; postFrameCallback64 fallback on 31/32) and ticking the decode loop's event channel. Started lazily on the first decoded frame. - decode/presenter.rs: a newest-wins slot (Lowest latency, default) or a 1-3 frame smoothing FIFO with preroll/underflow re-arm (Smoothness) between decode and release; a glass budget of exactly ONE undisplayed release in flight, reopened at the target timeline's DEADLINE (SurfaceFlinger's latch — reopening at present time would halve the sustainable rate) with a 100 ms stale force-open backstop; the release itself via releaseOutputBufferAtTime(expectedPresent) so the latch phase is deterministic. debug.punktfunk.presenter=arrival sysprop restores the legacy path for a rebuild-free on-device A/B. - Metrics: DisplayTracker is now always-on and carries the release stamp, so the display stage splits into pace (decoded→release) + latch (release→displayed); a 1 Hz pf.present logcat line (released/displays/ paced/noBudget/forced/qDry + pace/latch p50/max + measured vsync) makes a HUD-off wireless A/B readable; nativeVideoStats grows to 30 doubles (26=paceP50, 27=latchP50, 28=presents, 29=presenterActive; 0-25 frozen) and the DETAILED HUD prints the split + presents. - Intent parity: present_priority/smooth_buffer — the Apple client's stored values and labels — as globals, profile-overlay fields (round-trip + scope markers), and Settings pickers under Decoding; threaded through nativeStartVideo into the presenter config. Verified: cargo ndk check/clippy clean for arm64 (the two type_complexity warnings are pre-existing audio/mic ones), armv7 via the kit gradle task, host cargo check clean, rustfmt clean, gradle :app/:kit unit tests all pass. On-device before/after on the Nothing Phone 3 still owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	581320df0c	fix(android): the stream stops fighting large displays and owns the cutout explicitly ... The three Play Console pre-release findings for 0.22.3, resolved: - Orientation restriction: the in-stream SENSOR_LANDSCAPE lock is now applied on compact devices (sw < 600 dp) only. On tablets/foldables/desktop windows it is a large-display anti-pattern (Android 16+ ignores it there outright) and unnecessary — the aspect-ratio letterbox renders correctly in any orientation; the lock was always a phone-ergonomics choice. No manifest restriction existed, and resizeability stays unrestricted. - Edge-to-edge determinism: the stream window now sets LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS explicitly (and restores it on the way out) — SDK-35 enforcement makes that the immersive default, pre-15 devices letterboxed the notch as a dead bar; being explicit gives both the same, correct behaviour. The stream's own letterbox is black, so the cutout region can never show anything wrong. - Deprecated edge-to-edge APIs: audited — no in-app use of setStatusBarColor/setNavigationBarColor/systemUiVisibility/translucent flags or theme attrs; enableEdgeToEdge (androidx.activity 1.13.0) is already in place with explicit SystemBarStyle. What the scanner sees are androidx's own API-level-guarded compat branches, which Google documents as ignorable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	87b6fa8813	feat(android): the panel is pinned to the stream's refresh, and touch skips the vsync batch ... Three quick latency wins for phones, ahead of the presenter rebuild: - setStreamDisplayMode: the window-level preferredDisplayModeId is pinned to the stream's refresh (exact rate, else the smallest integer multiple, else the highest available) for the session. The surface-level frame-rate hint alone is advisory and some OEM refresh governors (Nothing OS's LTPO logic among them) ignore it for third-party apps — leaving a 120 Hz session presenting on a 60/90 Hz panel. nativeVideoSize gained a trailing refreshHz element for this (old readers index only 0/1). TV keeps the native HDMI mode switch instead. - The surface hint itself now passes compatibility = FIXED_SOURCE on every form factor: the stream is fixed-rate video the client cannot re-pace; DEFAULT invited governors to not switch. - requestUnbufferedDispatch(SOURCE_CLASS_POINTER) on the hosting view while streaming: touch/pointer events were vsync-batched — up to a frame of input latency the stream shouldn't pay. - The HUD polls the panel's live refresh each second and flags '⚠ panel N Hz' when it sits below the stream rate, so an unpinned panel is visible instead of reading as inexplicable judder. Stale nativeStartVideo kdoc (low-latency 'off, the default') corrected — it defaults ON under low_latency_mode_v2. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:44:09 +02:00
enricobuehlerandClaude Fable 5	ec675261fc	feat(android): the Sony-pad USB grant is asked on connect, not found in Settings ... On-glass feedback: burying the grant in the Controllers screen made the user go find it. Now MainActivity asks the moment a Sony pad appears — a fresh attach while the app is open, or the app foregrounding with one already plugged in — once per attach (a deny doesn't re-nag; the Controllers card's button stays as the re-ask). Nothing starts on the grant: an uncaptured pad is an ordinary InputDevice at menu time, so the grant is simply recorded and the next stream's capture engages silently. The grant broadcast is shared with the Controllers card so an open card refreshes from either dialog. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 18:34:57 +02:00
enricobuehlerandClaude Fable 5	1984ddb942	feat(android): a USB Sony pad is captured — rumble, adaptive triggers, lightbar, gyro ... A DualSense on a phone had rumble only where the kernel exposed force feedback, and adaptive triggers / lightbar / player LEDs nowhere — Android has no platform API for any of them, and Bluetooth offers no raw path (L2CAP is LE-only; hidraw is root-sealed — Sony's own Remote Play declares Android triggers unsupported). Claiming the pad's HID interface over USB is the one unrooted route, so that is what the client now does. - HidUsbLink: the device-agnostic half of Sc2UsbLink (claim, multiplexed UsbRequest loop, newest-wins write queue, signalled-unplug discipline), parameterized by device match / interface filter / keep-alive. Sc2UsbLink keeps only its SC2 specifics (Puck interfaces 2..5, lizard refresh). - GamepadFeedback.PadFeedbackSink: 0xCA rumble + 0xCD Led/PlayerLeds/ Trigger now route to a capture link that owns the pad BEFORE the InputDevice vibrator/lights paths — Trigger stops being log-and-drop. - DsDevice: the byte-exact inverse of the host's dualsense_proto / dualshock4_proto — input report 0x01 parse (buttons/sticks/triggers, gyro+accel, both touch points; Edge FN/BACK → wire paddles) and output builders (DS5 0x02 valid-flag-selective incl. the 11-byte trigger blocks and the lightbar-animation release; DS4 0x05 as composed full-state writes). Covered by DsDeviceTest (pure JVM). - DsCapture: stream-mode capture for DualSense / Edge / DS4 — lazy wire slot on the first parsed report, typed mirror (exit chord included), touch normalized onto the rich plane + per-report motion, feedback rendering with a rumble backstop (a USB pad holds its level, so a stalled poll thread self-terminates via a scheduled zero-write) and a teardown motor-stop over EP0. The claim releases the pad's InputDevice slot itself so the wire index hands over deterministically; uncaptured (toggle off / permission denied / Bluetooth) the pad stays on the ordinary InputDevice path. - Rich-input shims: nativeSendPadTouch / nativeSendPadMotion → RichInput::Touchpad / Motion — the plane the desktop and Apple clients already feed; Android pads gain gyro + touchpad on the virtual pad. - Settings: "DualSense / DualShock passthrough (USB)" (ds_capture, opt-out like the SC2 toggle); Controllers screen card with capture status and a front-loaded USB grant so streams start without the permission dialog. The host needs nothing: the DS5/DS4 backends already consume the typed + rich planes and already emit every feedback event rendered here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 18:34:57 +02:00
enricobuehlerandClaude Opus 5	a94b1d3ccc	fix(client/android): the stream keeps its aspect instead of stretching to the panel ... MediaCodec scales whatever it decodes to fill the Surface it renders into, and the Surface filled the screen — so a stream whose resolution didn't match the panel's aspect came out stretched. Nothing downstream of the Surface can correct that; the Surface itself has to carry the aspect. Size the video to the negotiated mode's ratio, centred, with the remainder black. The mode is known from the handshake before the first frame arrives, via a new `nativeVideoSize` (the same `client.mode()` the HUD already reports as `w×h@hz`); an older native lib returning nothing falls back to filling, exactly as before. Input follows the picture. Direct-pointer touch, multi-touch passthrough and the pen lane all map positions against the size of the node they sit on, so the gesture layer moves onto the same rect as the video and all three stay correct by construction instead of each needing an offset threaded through it. The physical-mouse path can't work that way — its events arrive from the activity in WINDOW coordinates — so it now measures against the SurfaceView's rect on screen, subtracting the letterbox origin and clamping into the picture: a pointer out on a bar has no host position of its own, and the edge is the honest answer for it. One deliberate consequence: trackpad swipes that START inside a letterbox bar no longer register. Trackpad input is relative and could have kept the whole panel, but one rule — input lands on the picture — beats a mode- dependent input surface, and the pen lane rides inside trackpad mode too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:48:38 +02:00
enricobuehlerandClaude Opus 5	9ed967cbaf	feat(client/android): the host card wears its OS mark where the initial was ... The OS mark rode along at 12 dp in front of the address, competing with the text it prefixed. The avatar circle above it was showing the host's first letter — which says nothing the name underneath doesn't already say, twice over on a row of home-worker-N boxes. Put the mark in the circle instead, at 24 dp in the avatar's own onPrimaryContainer tint, and drop it from the address line. A host that advertises no OS chain — or one we ship no mark for — keeps the initial, so those cards look exactly as they did and a mixed row still reads as one set. On glass: the two Arch hosts wear the Arch mark; steamdeck and the Windows runner, both predating the `os=` TXT, keep their letters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:32:22 +02:00
enricobuehlerandClaude Opus 5	6a6be17ce7	fix(client/android): a session that receives no video at all now asks, and says so ... The keyframe backstop added for the black LG TV only arms while AUs are actually going into the decoder (`fed > fed_at_output`) — deliberately, so an idle stream never asks for anything. That leaves its mirror image uncovered: a session that receives NOTHING. A decoder cannot be starved of output when it was handed no input, so no signal in either loop fires, and the session sits connected — audio, input and the control plane all alive — behind a black surface. That state is what a user just reported as "the stats are all basically 0": fps and Mb/s are counted at AU receipt (`note_received`), so all-zero stats with a drawn overlay means the decode thread started and received nothing. Same bug as the black screen, seen from the HUD. Both loops now watch for it: nothing received 1.5 s into a session ⇒ request a keyframe and log it, re-asking every 2 s while it lasts. Where it can help it does — the host encoding fine while every picture references an IDR this client never saw is precisely a keyframe request away. Where it can't, the log line is the point: "no video received N ms into the session" separates "the host never sent a picture" from "we received AUs and lost them", which no previous black-screen report could distinguish. Not a root cause. The remaining occurrences are still unattributed — this makes the next report diagnosable and recovers the case that is ours to recover. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:30:59 +02:00
enricobuehlerandClaude Opus 5	bb7baef20b	fix(client/android): the menus keep their safe area after a stream ... Returning from a stream left every menu laid out against the wrong safe area: content shoved right, the profile row sliding under the status bar, the tab labels crowding the gesture pill. Dumped on the reporter's phone, the window's real insets were bars=[0,162,0,72] cutout=[0,162,0,0] while the layout was using the landscape immersive set — cutout left=162 (Material3 lays out against systemBars.union(displayCutout)), bars all zero. No rotation and no IME animation could shake it loose. Compose attaches its OnApplyWindowInsets and WindowInsetsAnimation callbacks when the first composable reads an inset and removes them when the last reader goes away (WindowInsetsHolder.increment / decrementAccessors). StreamScreen reads no insets at all, so a stream drops that count to zero for its whole duration. Survivable on its own — but a session that ends while the app is BACKGROUNDED is the common case (leaving the app ends the session), and then the entire window restore runs on a stopped activity. The corrected insets arrive while Compose has no listener attached; when the menus recompose, incrementAccessors re-attaches and asks for a fresh pass, but a stopped window produces no dispatch and on resume nothing has changed any more, so none ever comes. Compose keeps serving the landscape, bars-hidden values for the rest of the process. Hold one inset reader at the root for the activity's whole life, so the listeners survive the stream and every dispatch lands. It subscribes to no inset VALUE, only the holder object, so it costs one DisposableEffect and no recomposition. Verified on the reporter's device by replaying the real teardown sequence (forced landscape + immersive, composition swapped to a screen that reads no insets, torn down while stopped) and reading the layout back through uiautomator: 3 of 4 runs wrong without this, 4 of 4 correct with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:30:59 +02:00
enricobuehlerandClaude Opus 5	91def82219	fix(client/android): the menus keep their safe area after a stream ... Returning from a stream left every menu laid out against the wrong safe area: content shoved right by the landscape side inset, the profile row sliding under the status bar, the tab labels crowding the gesture pill. Compose attaches its OnApplyWindowInsets AND WindowInsetsAnimation callbacks when the first composable reads an inset, and tears both down when the last reader goes away (WindowInsetsHolder.increment / decrementAccessors). The immersive stream reads no insets at all — it is a bare full-screen surface — so entering one dropped the reader count to zero right in the middle of the hide(systemBars()) animation StreamScreen had just started. With the animation callback gone, that animation's onEnd never arrived, so the listener kept runningAnimation = true for the rest of the process, and from then on every onApplyWindowInsets was swallowed (it defers to an onProgress that can no longer come). The values froze at the last animation frame — landscape, bars hidden — and that is what the menus got when they came back. Hold one inset reader at the root for the activity's whole life: the listeners now survive the stream, the landscape lock and the bar animations, and every animation gets its onEnd. It subscribes to no inset VALUE, so it costs nothing per frame. As a backstop, request a fresh insets pass from onConfigurationChanged — the activity declares configChanges=orientation|screenSize, so a rotation re-lays out in place and a dropped dispatch would otherwise go unnoticed until the layout is already wrong on screen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:30:59 +02:00
enricobuehlerandClaude Opus 5	75e4f00e50	Merge branch 'chore/windows-rerender-semantics' into main ... Windows 11 tray theming + per-connect device-name announcement, and the pairing approve button no longer escapes the canvas on portrait phones. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 23:27:36 +02:00
enricobuehlerandClaude Fable 5	43a9cf741b	fix(client/android): the build resolves cargo from CARGO_HOME before guessing ~/.cargo ... The kts resolves cargo by ABSOLUTE path on purpose (a GUI Android Studio launch has no ~/.cargo/bin on PATH), but user.home is the wrong anchor in the CI image, where the shared toolchain lives at CARGO_HOME=/usr/local/cargo — gradle died starting /root/.cargo/bin/cargo. CARGO_HOME/bin is where rustup puts binaries whenever the variable is set, so it wins; the ~/.cargo fallback keeps GUI launches working. Also: android.yml's path filter learns ci/android-ci.Dockerfile — an image change must exercise its consumer instead of needing a manual rerun to prove itself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:47:07 +02:00
enricobuehlerandClaude Fable 5	9b2404a580	feat(core): every connect introduces the device by name ... The wire always had Hello.name and the host always honored it - but the connect path hardcoded None (only the PIN-pairing ceremony sent a name), so every no-PIN "request access" knock surfaced as the fingerprint placeholder "device abcd1234", and approving one without retyping a name persisted that placeholder into the trust store forever. NativeClient::connect now takes the device name. The session workers and the probe connects pass trust::device_name() (the hostname), the C ABI defaults to the same without a signature change (an ex10 variant can make it explicit if an embedder wants a custom label), and Android threads Build.MODEL through nativeConnect - the same convention its pairing dialogs already use for nativePair. The host, in turn, resolves the streaming client's display name (trust store first, so an approval-time rename wins; else the sanitized Hello name) and exposes it as client_name in GET /api/v1/local/summary for the tray's connect toast - a deliberate, documented loosening of that route's "no device names" contract, in the local user's favor: it tells them who is on their machine. A paired-but-idle device's name still never appears, which the mgmt tests now pin explicitly. openapi.json, its docs-site copy, and the SDK bindings regenerate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:32:50 +02:00
enricobuehlerandClaude Fable 5	63224cd31d	feat(client/android): the eighth field carries the OS, and cards wear it ... The JNI discovery record appends `os` as its eighth ␟-field (append-only — the Kotlin parser's arity guard already tolerates both old and new records, now pinned by tests in both directions), sanitized on the Kotlin side by the mirrored chain grammar next to the shared `osIconTokens` walk. `KnownHost` persists it additively (optString — no schema bump, migration passes it through) with `learnOs` beside `learnMac`, learned on the same discovery tick. Compose ships no brand icons, so OsIcons.kt vendors the ten marks as raw SVG path strings built into ImageVectors via PathParser (lazy, cached) — they tint with the Material theme like any Icon. The host card's address line leads with the mark, live advert preferred over the stored chain. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 17:58:33 +02:00
enricobuehlerandClaude Opus 5	e44baf6768	fix(client/android): a decoder fed nothing it can decode must ask for a new anchor ... An Android TV box reported a black screen with a perfectly healthy HUD: AUs arriving at 40 fps, ~312 bytes each. That size is all-P-frames — no IDR anywhere in the window, and nothing asking for one. The stats being readable is the rest of the story: the overlay is a layer over the SurfaceView in the same window, so the panel was fine and the surface simply never received a frame. The decode thread only starts at `surfaceCreated`, so a slow box can be handed the stream mid-GOP. A hardware decoder does not error on references it never had; it emits nothing at all. Under infinite GOP the host sends no further IDR unless asked, and neither Android loop ever asked: every recovery trigger they have keys off a drop, a gap or a decode error, and a decoder that quietly produces nothing trips none of them. The session stayed black for its whole life. The shared gate has this case (`on_no_output`, which pf-client-core and the Apple client both feed) but its per-AU streak counts one-in/one-out decodes, and MediaCodec is pipelined — "this AU produced no output" is not something these loops can observe. A wall-clock silence window is the same signal in the shape Android can measure: fed for 500 ms with nothing coming back arms the freeze and requests a re-anchor keyframe, and the gate's deadline keeps re-asking until one lands. 500 ms so it can never fire on a decoder that is merely slow to spin up. Also log the first presented frame. The periodic tally starts at 300 rendered frames, which is no help whatsoever on a session that renders none — its absence is what separates "never reached glass" from "reached glass and looked wrong". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 17:57:13 +02:00
enricobuehlerandClaude Opus 5	1862010003	fix(client/android): a settings edit belongs to the scope the chips show ... Change a setting on the defaults, switch to a profile, change the same row: the globals moved again and the profile recorded nothing. Switch back, and the next edit went into the profile — which reads as "the default settings can't be changed any more". `update`/`resetField` reached the rows as `::update` — callable references, and two of those compare equal however different the scope they closed over. Compose saw an unchanged callback and skipped the whole detail page on a scope switch that moved no value on screen, which is the ordinary case: a profile inherits the globals until it overrides something. The row went on calling the reference it was first handed, one scope behind for the rest of the session. Resolve the scope from the live state at the edit instead of closing over it, so the write follows the chips whether or not the page recomposed. `key(active?.id)` around the detail page covers the other half — a row's own `remember` is per-scope state too, and "Custom…" picked while editing a profile has no business still being picked over on the defaults. The model tests can't see this: it takes the real Compose runtime to skip a composable. SettingsScopeTest drives the screen itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 17:57:13 +02:00
enricobuehler	8fee1139f6	chore(client/android): adopt AGP 9.3.1 / Gradle 9.5.0, and tell CI about it ... The bump itself came from Android Studio; this makes the rest of the repo agree with it. The toolchain line at the top of the root build file still claimed AGP 9.2.0 and Gradle 9.4.1, and both Android workflows named "AGP 9.2" as the reason they pin JDK 21 — the sort of comment that is trusted precisely because it looks maintained. The Gradle caches also needed telling: they cache the DISTRIBUTION under `~/.gradle/wrapper`, keyed on a hash of `*.gradle.kts` only. This bump moved both files so the key changed anyway, but a wrapper-only bump would have restored a key that can never contain the new distribution. The wrapper properties are in the key now. Verified with the workflows' own commands on the new toolchain: `:app:testDebugUnitTest -PskipRustBuild --stacktrace --rerun-tasks` (the screenshot job, 45 tasks from cold) and `:app:assembleDebug` including the cargo-ndk native build. AGP 9.3.1 resolves no build-tools newer than the 37.0.0 both jobs install, so their sdkmanager lines still cover it.	2026-07-29 12:17:18 +02:00
enricobuehler	93fe9f134e	refactor(client/android): the colour palette reads as one object ... Three things were wrong with it, and they compounded. **The order was arbitrary** — orange, blue, pink, green, amber, violet, cyan, rose jumped back and forth across the wheel, so it looked like a bag of colours rather than a choice. It is sorted by hue now, one clean sweep, with the degrees in the source so it stays that way when a colour is swapped. That is also the order creation hands them out in, so someone making profiles one after another walks the spectrum. **The layout fought the form.** A fixed-size grid centred in the dialog floated free of the left-aligned labels above it; distributed across the full width the swatches stopped looking related to each other; and eight colours wrapped to a short second row that read as the grid running out. Each row now FILLS the width with its swatches sharing it equally, so the palette's edges line up with the name field's and both rows are the same length. The palette gained two hues to make that work: ten divides by five, eight didn't divide by anything useful. **Selection was a heavier circle.** A border drawn on the swatch's own edge reads as a thicker ring, not as "this one". It is a ring OUTSIDE the disc with a gap, plus a check — which also means the selection survives a reader who can't tell two of these hues apart. The ring's space is always reserved, so picking never nudges the grid.	2026-07-29 12:17:18 +02:00
enricobuehler	a3ec30c287	refactor(client/android): manage a profile from its own chip, and pick its colour up front ... Two things about the profile UI were backwards. **The manage menu was parked after the last chip.** A single overflow button at the end of a horizontally-scrolling row, acting on whichever profile happened to be selected — so reaching it meant scrolling past every profile, and nothing on screen tied the button to its target. It now lives ON the chip: the selected profile grows a chevron, tapping it again opens Edit / Duplicate / Delete anchored underneath, and the action is attached to the object it acts on. The wandering ⋮ is gone. **Colour was an afterthought.** A profile was named at creation and coloured later, through a menu item most people would never find — so every profile looked colourless until someone went hunting, and the accent is precisely the signal that has to be right from the first moment (it is all a bound host card's chip and a pinned card's tint have to go on). Name and colour are now decided together, in one dialog that serves both creation and editing, with the next unused colour pre-selected. "Rename…" and "Change colour…" collapse into one "Edit…", which is three menu items instead of four and one dialog instead of two. The chevron rides inside the chip's label rather than the `trailingIcon` slot, for the same reason the accent dot does: those slots reserve an 18dp icon and shrink the chip's padding, which is what made a chip with a dot sit differently from "Default settings" beside it. Driven on glass: created a profile with a colour chosen in the dialog, opened the menu from the selected chip, and edited name and colour together.	2026-07-29 12:17:18 +02:00
enricobuehler	f2874a5324	feat(client/android): a profile gets a colour, and you can change it ... The accent was reserved in the schema and used everywhere it mattered — the scope chip, a bound host card's chip, a pinned card's tint — but nothing ever set one. `newProfile` left it null, and design §5.1's "Change color" was the one item of the scope menu I didn't build. So every profile a user actually created was colourless, and the only one that wasn't was a test profile I had seeded by hand through adb. That inconsistency was the whole visible symptom. Creation now hands out the first unused colour from an eight-entry palette, so profiles are distinguishable from the moment they exist — which is the point of the accent on the surfaces where a profile has no room for its name. The palette avoids the presence green, which means "this host is up" and nothing else. Past eight it wraps rather than handing out nothing: a repeated colour beats an invisible chip, and the picker is right there. "Change colour…" joins Rename / Duplicate / Delete, with "no colour" offered as a real choice rather than only an initial state — a profile made before this existed keeps working, and its chip falls back to the theme's accent. The colour is presentation, not a setting: it is not in the overlay, so it never reaches a resolved connect. Tested, and driven on glass end to end — two profiles created through the dialog, distinct accents on their chips.	2026-07-29 12:17:18 +02:00
enricobuehler	4803260aff	fix(client/android): a settings row's gaps are set, not inherited ... One `spacedBy(4.dp)` was doing three different jobs in a settings row, and got all of them wrong. The caption sat as close to its control as the override marker did, so the row read as one undifferentiated stack — and the marker, being the FIRST child of a card that already pads 16dp, added its own vertical padding on top of that, so a marked row started with visibly double the gap every other row has. Each gap is now stated where it belongs: the marker has no vertical padding of its own (it sits exactly at the card's padding, level with an unmarked row's control) and owns the 6dp down to the field it annotates; the caption owns the 10dp up to it. Tighter above, roomier below — so the marker groups with its control and the caption reads as a separate note rather than part of it. The "Reset" hit area loses most of its vertical padding to make that work; it keeps the horizontal padding and the full-width row, so the target is wide rather than tall. Confirmed on glass, not just in the screenshots.	2026-07-29 12:17:18 +02:00