feat(mobile): style every Google Cast SDK sheet in the app palette

[Ur-imazing]

The Chromecast sheets were the last surface still wearing Google's colours: a neutral-grey ground, an iOS-blue Cancel, a blue volume slider and a blue "Stop casting". react-native-google-cast exposes no styling API and apps/mobile/ios + android are gitignored prebuild output, so the theming ships as two Expo config plugins.

A plugin change moves the fingerprint runtime version, so this needs a new native build — an OTA update cannot deliver it.

What changed

iOS — plugins/withCastUIStyle.js injects a GCKUIStyle block into AppDelegate.swift, covering every surface the SDK can present: chooser, connection controller (plus its nav bar and toolbar), empty state, connecting state, expanded controller, mini controller, track selector, instructions.

Android — plugins/withAndroidCastTheme.js writes mediaRouteTheme and the cast*Style items onto AppTheme, because every cast dialog resolves its theme from the Activity, not from the cast button's ContextThemeWrapper.

Android's cast control is now the SDK's own button (src/lib/cast/NativeCastButton.tsx), in the same Frosted backplate the AirPlay picker already uses. showCastDialog() can only click a native MediaRouteButton that is already attached, and the app mounted none — so Android had a cast glyph that did nothing at all. iOS is unchanged: it presents the dialog from GCKCastContext directly, so it keeps the app-drawn glyph, its cast-connected variant and its state-aware label.

Colours only. Row height, corner radius, the grabber and the type scale live in the SDK's nib and are not reachable. Fonts are deliberately left alone: contentSizeDidChange: re-runs initDefaultFonts, so a custom font is wiped the first time the reader changes text size.

Two Android defects the first pass missed, both found on hardware

The theming above was verified on iOS only. Testing it on a physical Galaxy Tab S8 (Android 16) against two real Chromecasts found two defects that no emulator could have shown — the emulator mangles multicast, so it never discovers a receiver at all.

1. The Android cast button could never appear. Both the old glyph and the new SDK button were gated on castUi.available, which comes from getCastState(). That call was measured answering noDevicesAvailable for minutes while both Chromecasts already sat in the app's own MediaRouter route list; it read notConnected seconds after the chooser was opened. The gate therefore never opened. Android now renders the SDK button unconditionally; iOS keeps its gate, because presentCastDialog needs no attached button and its state is trustworthy.

This was a pre-existing bug, not a regression from this PR — verified at 4337a352d that the old Android glyph was gated the same way. Neither design ever worked on Android 16.

Always-visible is correct rather than a leak: in mediarouter 1.8.0-beta01 MediaRouteButton has no visibility logic at all and setAlwaysVisible(boolean) is a no-op stub (0: return in its bytecode), so the SDK's old auto-hide behaviour is gone.

2. The chooser dialog's ground stayed stock #303030. The theme set android:colorBackground, but an AppCompat dialog paints android:windowBackground — ThemeOverlay.AppCompat.Dark sets both to #303030, so our text colours landed while the ground did not. Overriding windowBackground costs no dialog inset or corner radius, because the stock value is a flat colour rather than abc_dialog_material_background.

Three facts worth knowing before editing this

• The iOS block's begin marker carries a content hash of the emitted Swift. expo prebuild REUSES an existing ios/ rather than recreating it, so a name-only sentinel made an edited block look already-applied and kept building the previous palette.
• The trailing call is apply(), not the header's applyStyle — Swift renames the selector. Only a real compile catches it; the tests pinned the header spelling and stayed green while the build failed.
• deviceChooser does not own the chooser's own title or Cancel button. _styleAttributesForNavigation is captured once in viewDidLoad from connectionController, so both sheets' nav bars come from deviceControl.connectionController.navigation.

Verification

Both platforms were verified by sampling pixel values out of screenshots rather than judging by eye — the stock cast red #D0021B and our #CB333B pass a glance and fail the design system.

iOS (simulator, against a real Chromecast):

Element	Measured
sheet ground	#1c1917	exact
titles, row labels	#f5f5f4	exact
row glyphs	#a8a29e	exact
transport glyph	#f5f5f4	exact
iOS system blue #0a84ff anywhere	0 px	gone
stock cast red #d0021b anywhere	0 px	gone

The sheets also held dark at luminance 25/255 with the system appearance set to light, which closes the userInterfaceStyle: "automatic" hazard — an unstyled sheet follows the system, not the app.

Android (Galaxy Tab S8, Android 16, two real Chromecasts, shipped config with no probes):

Element	Measured
dialog ground	#1c1917	441,041 pixels matched
title, both route labels	#f5f5f4	exact
stock #303030 / #424242 / #d0021b	0 px	gone
SDK <CastButton> mounts	content-desc="Cast", clickable=true	uiautomator dump

The cast and AirPlay buttons were also confirmed present on a physical iPhone.

156 suites / 2334 tests, tsc, eslint and prettier clean. Clean prebuild both platforms; iOS BUILD SUCCEEDED; Android assembleDebug green.

Reviewed

Tier-2 /ce-code-review ran twice: once before the first push, and again scoped to the Android fix commit.

The first pass raised 13 findings after reconciliation, 11 through a validation gate; seven were applied in 88d3796b9 and four dropped as false or preference-only. Findings it caught that were shipping green: gutting forgeApplyCastBase passed every test while every cast surface reverted to Google's palette; volumeSliderMaximumTrackTintColor had no test at all; neither plugin's exported entry point ran under jest; and Android theme item values were largely unasserted (aapt2 checks that a @color reference resolves, never that it is the right one).

The second pass raised no code findings. Correctness traced every consumer of the availability signal and confirmed the fix is complete rather than half-applied; testing independently re-ran the falsification (reverting the gate fix turns exactly 1 test red, the theme fix exactly 2). It did find four overstated claims, corrected in af267a415 — most importantly that the getCastState() cause had been asserted without a counterfactual. The measurement stands; the mechanism does not, and the docs now say so.

Neither review pass carries cross-model corroboration. The independent cross-model reviewer failed to authenticate in its execution context both times, and on the second pass the adversarial lens was abandoned before completing — so this change has had no adversarial review at all. That is the largest gap in its verification.

Not verified

• The DYNAMIC Android chooser. Only the classic chooser was measured. Theme.MediaRouter points mediaRouteBodyTextAppearance / mediaRouteHeaderTextAppearance at TextAppearance.MediaRouter.Dynamic.*, which hardcode android:textColor to #FFFFFF and #BDC1C6 — a text appearance's own textColor beats the theme-level textColorPrimary this plugin sets, so on that variant those two items do nothing. Which variant appears depends on whether the receiver advertises dynamic groups; two ordinary Chromecasts produce the classic one.
• Android light mode. It rests on an argument, not a measurement: values-night/ carries no cast resources, so the explicit hex should win in either mode.
• The iOS volume slider — the receiver reached reports no volume control, so that row never drew.
• Whether the SDK button's state-aware label survives a live session.
• Render performance of the now-unconditional Android button. The repo asks for page-load evidence on rendering changes; this adds one native view and has none.

There is no kill switch — a config-plugin change moves the fingerprint runtime version, so a wrong palette cannot be reverted by an EAS Update on either platform. Only a new store build.

Follow-up not in this PR

• No CI step compiles the emitted Swift or builds the Android app. apps/mobile CI is ubuntu-only and its build script is a no-op echo, so jest string-pinning is the only automated gate on generated native code — which is exactly how the applyStyle error reached a build, and how the wrong background attribute reached a device. A macOS job running expo prebuild --clean plus a Debug xcodebuild would close the iOS half; nothing currently would have caught the Android half. That is recurring runner cost and a deliberate omission.
• The getCastState() cause is still open. The discriminating experiment is a button attached but never tapped.
• apps/tv has no Chromecast implementation, so neither fix needs porting today. When cast lands there, both defects will need re-deriving — TV and mobile lib predicates are known to drift silently.

🤖 Generated with Claude Code