Observability: adopt AndroidX Tracing 2.0.1 behind a secret-safe MuxTV trace boundary

[MrFr3di]

Objective

Adopt stable AndroidX Tracing 2.0.1 as an evidence boundary for MuxTV so catalog, database and playback latency can be attributed across coroutine/thread hops and correlated with Benchmark/Perfetto without making product logic depend on tracing.

AndroidX stable-channel lists Tracing 2.0.1 as stable on 2026-08-26, superseding the previously planned 2.0.0 target. Owner under #179; measurement authority remains #27 and release/Benchmark acceptance remains #31.

Why now

MuxTV currently pins androidx.tracing 1.3.0 and has no repository-owned Tracing 2.x boundary. The Tracing 2.0 line adds low-overhead in-process tracing, Perfetto annotations/flows, traceCoroutine, category filtering and after-the-fact system-trace merging supported by AndroidX Benchmark 1.5.

2.0.1 is the correct stable baseline for a new 2.x adoption. Do not invent a specific 2.0.1 behavioral fix unless AndroidX publishes one; the value is taking the latest stable patch while introducing the 2.x boundary.

Architecture

Introduce a small MuxTvTrace facade/wrapper with stable names and a no-op/disabled path. Product components may emit bounded trace spans/counters but must not depend on trace availability or results.

Initial high-value taxonomy:

• MuxTv.SourceRefresh
• MuxTv.M3uParse
• MuxTv.CatalogStage
• MuxTv.CatalogActivate
• MuxTv.EpgImport
• MuxTv.Search
• MuxTv.PlayerPrepare
• MuxTv.FirstFrame

Use coroutine-aware tracing only at meaningful suspend boundaries; do not wrap every function/recomposition.

Security / privacy contract

Trace names and metadata must never include source/playback URL/path/query, Authorization/Cookie/custom headers, provider tokens/credentials, channel/programme/title text, arbitrary exception messages or raw external locators.

Metadata is limited to stable enums, numeric durations/counts, booleans, coarse transport/format categories and opaque non-secret correlation IDs only where required.

Runtime policy

• product correctness never depends on tracing;
• production does not persist trace files by default;
• benchmark/debug may install an in-process/Perfetto sink;
• disabled tracing remains cheap and behaviorally inert;
• no generic remote telemetry service.

TDD / acceptance

1. RED pure tests define allowed trace names/categories and reject secret-bearing attributes;
2. wrapper has explicit disabled/no-op behavior;
3. trace infrastructure exceptions never alter product outcome;
4. first slice instruments only selected catalog/search/player boundaries;
5. traceCoroutine is used only where suspend/thread switches matter;
6. exact-head host tests/compile GREEN;
7. Benchmark 1.5 capture later proves target in-process traces can merge with system trace;
8. canonical API26/current API evidence verifies no functional regression;
9. any performance claim cites Deterministic IPTV corpus and performance benchmarks #27/Release hardening, baseline profile and physical TV alpha gate #31 evidence.

Non-goals

• tracing every function/recomposition;
• remote telemetry upload;
• performance claims before measurement;
• changing Room pool, Media3 buffer policy or parser implementation.

Ordering

Prepare after/alongside #191. The dependency bump 1.3.0 -> 2.0.1 must be isolated from combined stack probe #190 when final merge units are cut. #178 must be fixed before DB performance conclusions are trusted.

Official reference

https://developer.android.com/jetpack/androidx/releases/tracing

[MrFr3di]

Execution design and task-level TDD steps are staged on docs/observability-modernization-20260824 in the 2026-08-24 observability spec/plan. #192 is O2. First executable step is dependency/module feasibility plus a RED trace-policy contract; do not force AndroidX Tracing into core:common if the intended isolated JVM adapter boundary does not resolve cleanly.

[MrFr3di]

Runner-free secret-boundary audit prepared at docs/security/2026-08-24-secret-bearing-data-boundary-audit.md. #192 trace attributes should remain an allowlisted typed surface: operation/category/generation/revision/result/duration/counters are suitable; raw source/stream/catch-up URI, headers, tokens, channel/programme titles, private source names and unrestricted exception text are not. Prefer an API shape that makes arbitrary raw metadata difficult rather than relying on every call site to remember redaction.