Fault Deck QA Harness for Deliberate Streaming Failure Testing

Q: Do I need mitmproxy for this to work?

No. FaultMode and EventLogger work independently without mitmproxy. The mitmproxy script is there if you want HTTP-level segment inspection on top of the player-level telemetry.

Q: What does the case study cover?

It walks through a complete fault-deck session from picking a failure scenario to reading the EventLogger and Stream Probe overlay together and writing up a diagnosis. It's a reference for onboarding team members to the harness.

Stream Probe introduces a fault-deck QA harness in this update, giving developers a way to deliberately trigger ExoPlayer misconfigurations and practice diagnosing real streaming failure states.

TL;DR

Debugging streaming issues is hard when you can't reproduce them on demand. The fault deck lets you intentionally break things in controlled ways, so your team can build muscle memory around reading the telemetry before a real incident hits.

What's New

FaultMode enum: New enum that misconfigures ExoPlayer on purpose. Covers scenarios like bandwidth constraints, bad segment responses, and other failure conditions useful for QA testing.
EventLogger integration: ExoPlayer's built-in EventLogger is now wired in behind a debug intent extra. Pass the flag at launch to get verbose playback events in logcat without touching the source.
Network security config: Added a network security configuration that permits local cleartext HTTP traffic. Needed for routing test sessions through a local fault server or mitmproxy.
Shell capture scripts: Added shell scripts for grabbing logcat output and mitmproxy session data during fault-deck runs. Keeps test evidence consistent across team members.
Case study and design spec: Wrote a comprehensive case study walking through a real fault-deck session from setup to diagnosis, plus a design spec covering the harness architecture.

How to Use

Launch the Android app with the debug intent extra to enable EventLogger:

adb shell am start -n com.your.package/.MainActivity --ez enable_event_logger true

Set a FaultMode in the app to misconfigure ExoPlayer for your chosen failure scenario.
Run the capture script to collect logs:

./scripts/capture_logcat.sh

Use the mitmproxy script if you need HTTP-level segment inspection:

./scripts/capture_mitmproxy.sh

Cross-reference the EventLogger output with Stream Probe's segment overlay to identify the failure pattern.

FAQ

What is FaultMode actually doing under the hood?

FaultMode sets ExoPlayer parameters (like bandwidth estimation overrides or load control settings) to values that force specific bad behaviors. It doesn't mock network responses; it misconfigures the player itself so failures are as close to real conditions as possible.

Do I need mitmproxy for this to work?

No. The shell scripts and network security config support mitmproxy for HTTP-level inspection, but FaultMode and EventLogger work independently without it. mitmproxy is useful when you want to inspect or manipulate the actual segment responses during a test session.

Will this affect production builds?

The EventLogger is gated behind a debug intent extra and FaultMode is intended for QA use only. Neither should be active in a production build, but double-check your build variant configuration before shipping.

What does the case study cover?

It walks through a full fault-deck session: picking a failure scenario, configuring the harness, reading the EventLogger and Stream Probe overlay together, and writing up a diagnosis. It's meant to be a reference for onboarding team members to the tool.