Kayos
69c91fdca6
Fixes the post-vc=16 regression Cobb hit: "videos do not play anymore".
Root cause (from memory/audit-straw-vc16-emulator-2026-05-24.md):
ExoPlayer's DefaultHttpDataSource sends open-ended `Range: bytes=N-`
on first read of a stream. iOS-bound googlevideo URLs return HTTP 403
on any open-ended Range, even with the iOS YT UA. Bounded ranges
(`Range: bytes=N-M`) return 206 normally. ExoPlayer's behaviour is
correct per spec; YT's iOS-channel URLs are quarantined to bounded
reads only — the iOS app does this internally; ExoPlayer doesn't.
Fixes:
1. **net/IosSafeHttpDataSource.kt** (new) — wraps any HttpDataSource so
each open() with unbounded length issues a sequence of bounded 1 MiB
Range requests, rolling forward transparently on read(). Drops in via
IosSafeHttpDataSource.Factory(DefaultHttpDataSource.Factory()).
2. **VideoDetailScreen.kt** (inline player), **PlayerScreen.kt**
(fullscreen), **PlaybackService.kt** (background audio) — wrap the
DataSource factory accordingly.
3. **VideoDetailScreen.kt + PlayerScreen.kt** — add Player.Listener with
onPlayerError so ExoPlayer failures surface in the UI as a visible
error string. The audit's confirmation-bias trap ("pause icon must
mean playback") was caused by failures being invisible.
4. **StrawApp.kt** — call uniffi.strawcore.initLogging() so Rust-side
log::warn!() (in particular the soft-fail messages from the fork's
deobf path) reach `adb logcat -s strawcore`. The init fn already
existed in strawcore/lib.rs; the call was lost during C-6.
Audit findings not fixed in this pass (deferred / cosmetic):
- Finding 3 (TV-client IpBan on Lucy egress) — environmental, not code.
- Finding 5 (eager ExoPlayer init in inline composable) — latent.
- Finding 6 (duplicate strawcore round-trip on inline tap-to-play) —
V-2 work, intersects MediaController unification.
Verification: rebuild + emulator smoke ahead. Should ship as v0.1.0-AC vc=17.
|
||
|---|---|---|
| .. | ||
| src/main | ||
| build.gradle.kts | ||