Running the suite across API 33, 34, 35 and 36 emulators failed the same test
on all four, while it passed on a Pixel 10 Pro XL. The assertion was "the
hardware path should have been attempted", and the routing was correct in both
cases: those emulators expose no hardware H.264 encoder, so the router sent the
job straight to FFmpeg and Media3 was never called.
That is the same mistake made earlier with routesAFastMp4JobToMedia3 -- baking
an assumption about the host's encoders into a test. A result that flips with
the machine says nothing about the code.
This test is about the fallback mechanism rather than about routing, so it now
pins DeviceCodecs.PERMISSIVE through the existing seam and the router's choice
becomes deterministic. Routing itself is covered separately, by tests that
derive their expectation from the device.
Verified on emulators for API 33, 34, 35 and 36: 40 instrumented tests each,
0 failures, 2 skipped, with the only skips being the opt-in benchmark. That
also exercises all three foreground-service regimes for the first time -- no
type below 34, dataSync at 34, mediaProcessing from 35 -- which had previously
only ever run at API 37.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
JMR-devandClaude Opus 5
a172cb137f