fix(reverse): software-codec fallback when a HW codec rejects start (47233ad7)

[stozo04]

Summary

Fixes Crashlytics 47233ad7 — Non-fatal he: Render worker reported failure, repeating on an LG LM-X540 (Android 10). The real cause was in the breadcrumbs: reverse_preview_failure: IllegalArgumentException: start failed.

"start failed" is MediaCodec.native_start()'s JNI message; a BAD_VALUE native status surfaces it as IllegalArgumentException. On this low-end non-Samsung device the hardware AVC codec rejects start(). The hand-rolled reverse pipeline (which, unlike the Media3 Transformer path, doesn't get setEnableDecoderFallback) only retried Samsung lifecycle churn / "surface released", so this failure escaped on the first attempt with no software fallback — failing both the editor reverse preview and the boomerang save.

What changed

• Detect codec-init failures — isMediaCodecInitializationFailure + shouldRetryReverseWithSoftwareCodec (MediaCodecLifecycle.kt), distinct from benign teardown.
• Recover on any device — VideoReverser retries once on the software encoder AND decoder after an init failure (threaded preferSoftwareDecoder through the pipeline; the platform-default decoder path previously had no fallback). Samsung / zero-frame paths unchanged.
• Diagnosability — BoomerangRenderWorker now reports the real render cause to Crashlytics in its IOException/ExportException/RuntimeException branches; previously the actual exception lived only in on-device logcat and never reached Firebase.

Tests

• MediaCodecLifecycleTest — predicate + retry-decision coverage, incl. the exact start failed signature and a regression guard vs. the old contention path.
• VideoReverserTest.reverse_recoversFromCodecStartFailure_viaSoftwareFallback — on-device fault-injection via a new VideoReverser.attemptHook test seam: injects start failed on attempt 0, asserts the reverse recovers on the software encoder+decoder and produces a valid, playable clip. ✅ Passed on Pixel 6 (tests=1 failures=0 errors=0).
• Unblocked the test source set (pre-existing breakage unrelated to the bug): DeviceMediaHintsTest / SamsungReversePreviewRegressionTest referenced removed *_MS constants; OpenLoopViewModelTest asserted a RAW the render flow now intentionally deletes after a successful save.

Verification (Definition of Done)

• ✅ assembleDebug + assembleRelease — BUILD SUCCESSFUL, exit 0
• ✅ lintDebug 0 errors (13 warnings, none new); lintVitalRelease clean
• ✅ Unit tests: 0 failures
• ✅ Instrumented recovery test: passed on Pixel 6
• ✅ 3-device E2E happy-path sweep (Pixel 6 / 8 / 10 Pro Fold) — record → edit all 4 tabs → reverse → save → share → gallery → playback, 0 crashes / 0 timeouts (docs/e2e/2026-06-21_150054.md)

Honest gap

The fault-injection test exercises the recovery branch on a real device, but the literal LG LM-X540 hardware could not be tested — Firebase Test Lab no longer carries any LG device (only a physical phone would give 100% certainty on that exact chip).

Also included

• Production zero-error rule recorded in DEFINITION_OF_DONE.md + CLAUDE.md (no PR on a red baseline, pre-existing failures included).

Manual QA checklist

• On a physical low-end / older device, save a reverse-containing boomerang and confirm it renders + plays.
• Confirm share-sheet target still receives the file (benign chooser-preview FileProvider permission-denial warnings noted in the E2E report).

Made with Cursor