Run the e2e harness on iOS, Android and in a browser

[ruccho]

Problem

Checking an encoder change on a phone meant building a Unity player, so in practice the mobile and web backends were only ever exercised by hand.

What this does

One pipeline definition and one set of assertions in unienc_testkit; each platform supplies only a way in.

iOS simulator — a Rust test binary is a plain executable, so simctl runs it directly. No app bundle, no provisioning profile, no signing; a runner in .cargo/config.toml is the whole integration. VideoToolbox does encode H.264 in the simulator, so this covers the encoder and not just the build.

Android — MediaCodec and MediaMuxer need a JavaVM but neither an Activity nor a Context, so a JVM is the only thing an adb shell lacks and app_process supplies one. Hence a library loaded by a small Java shim rather than an instrumented test inside an APK: no Gradle project, and the same command works against an emulator and a real device.

Web — the only target where the harness cannot be a cargo test. The encoders are the browser's own and report through callbacks delivered as browser tasks, so the thread has to keep returning to the event loop while libtest wants a test function that runs to completion. unienc_harness_web drives the pipeline the way Unity does instead: a callback per animation frame. ASYNCIFY is not the easier answer it looks like — it unwinds the wasm stack while suspended and the encoder callbacks re-enter wasm during that window.

Two web-specific details: Emscripten is built here without pthreads, so TestRuntime uses a LocalPool, matching the build unienc_c ships for the web; and the muxer downloads its output rather than writing a file, so web::capture_muxed_output intercepts the one JavaScript function it calls and writes the same bytes into the in-memory filesystem, leaving the backend unchanged.

Verification

Passes on an iOS 26 simulator (from a cold start), an Android emulator and headless Chrome, alongside the desktop matrix. CI runs all three.

The browser job took two corrections to become meaningful. It needs a Chrome that can encode H.264: browser-actions/setup-chrome defaults to latest, which is a Chromium snapshot rather than a Google Chrome build, and Chromium ships without the proprietary codecs, so every profile the harness offered was refused. The job therefore asks for the stable channel, which resolves to a Chrome for Testing build.

It also runs on macOS rather than Linux, because of the audio. Chrome reaches WebCodecs' AAC encoder through MojoAudioEncoder, whose IsSupported is gated on the media::kPlatformAudioEncoder feature, and media/base/media_switches.cc enables that by default only on Windows, macOS and Android — the platforms with an OS-level AAC encoder behind it. On Linux the harness's audio configuration is refused outright, so the job could not have covered the backend's audio path, which is the path #178 fixed.

The workflow also stops triggering on both pull_request and an unrestricted push, which ran every job twice for the same commit. It was easy to miss because both runs report the same job names, and it cost little while the workflow was one cargo fmt --check; with the jobs added here it duplicated a simulator boot, an emulator boot and a second macOS runner. push is now restricted to main, which a pull request never heads, so nothing loses coverage. A concurrency group cancels a branch's run once a new push supersedes it, for the same reason: a superseded run holds a runner for a result nobody will read. Runs on the trunk are exempt, because each of those is the only result its merged commit ever gets.

The Android job is red on this PR alone, in the same way #176's Linux job is: the job is added here and the defect it finds is fixed above it. unienc_android_mc holds both of a two-worker executor's workers in its push loops, so the pull tasks never run and the pipeline deadlocks. #181 fixes that, and the top of the stack is green.

What this does not cover

The GPU blit path needs a Unity graphics device; the iOS static library link is not exercised by a simulator binary; and an emulator or simulator uses software or host encoders, so the frame drops and colour shifts specific to real hardware still need a device. docs/device-testing.md records this and how to reach for a real device.

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

🤖 Generated with Claude Code