Implement Google Cast sessions on microG

[woahwhattheheck]

On current master, apps that use the Cast SDK (CastContext) load microG's com.google.android.gms.cast.framework.dynamite module. That module is mostly stubbed:

• routes never reach a session;
• CastState stays at NO_DEVICES_AVAILABLE, so apps hide their cast button;
• the device controller can't join, register namespaces or set volume, and it doesn't implement the connectionless API that current SDKs use.

This PR implements the whole path: discovery, the device connection, and the framework session.

Device connection (play-services-cast/core)

• In-tree CastV2 channel (channel/CastChannel.kt, channel/CastDeviceSession.kt, cast_channel.proto via Wire). It replaces chromecast-java-api-v2. It handles:

  • TLS, length-prefixed CastMessage framing and the deviceauth challenge;
  • per-transport virtual connections and heartbeat;
  • receiver status, launch/join/leave/stop and volume/mute;
  • text and binary messages on the application's transport.

• CastDeviceControllerImpl serves every ICastDeviceController transaction the current client SDK sends: disconnect, leave, stop, requestStatus, setVolume, setMute, sendMessage, sendBinaryMessage, register/unregister namespace, launch, join, connect, addListener and removeListener. It supports both client flows:

  • the legacy flow, with the listener in the service request extras and reconnect via last_application_id;
  • the connectionless flow (addListener, then connect, then onConnectedWithResult).

  A death link on the client's listener tears the connection down when the app dies. The client may reuse the controller binder after disconnecting, and the controller reopens in that case.

• CastServiceImpl answers CAST_API (161) requests. The bind advertises the features the client checks for: cxless_client_minimal, module_flag_control and the others.

• CastMediaRouteProvider:

  • discovery runs on passive requests too;
  • resolves are serialized, with a timeout on API 34+;
  • TXT records are parsed tolerantly;
  • the exact requested CATEGORY_CAST/<appId>... categories are echoed in the control filters;
  • routes have variable volume and expire when discovery stops, unless they are still in use;
  • all state is confined to the main thread.

• CastMediaRouteController follows and sets the device volume over its own CastV2 session. It reconnects on demand if that connection drops while the route stays selected.

Cast framework module (play-services-cast-framework/core)

• CastContextImpl:
  • builds the merged selector from the app's own session provider categories;
  • registers the module's callbacks with the app's MediaRouter;
  • drives active discovery while an activity of the app is started;
  • implements setReceiverApplicationId and destroy.
• SessionManagerImpl / SessionImpl / CastSessionImpl:
  • session start on route selection, plus startSession and endCurrentSession(stopCasting);
  • the session state machine and all SessionManagerListener events;
  • CastState transitions;
  • launch or join of the receiver application, and resume of a saved session after the app restarts.
• ReconnectionServiceImpl, FetchBitmapTaskImpl (notification and controller artwork) and a ModuleDescriptor for the dynamite module. The return 1 placeholder in DynamiteLoaderImpl is removed.

Binder and parcel compatibility

I checked the transaction codes and argument types of these interfaces against the play-services-cast / play-services-cast-framework 22.3.1 client libraries:

• ICastDeviceController and its listener;
• ICastDynamiteModule, ICastContext, ISessionManager, ISession, ICastSession;
• IMediaRouter and its callback;
• ISessionProxy and the fetch-bitmap interfaces.

Two changes come out of that:

• ICastSession.onConnectionFailed now takes the ConnectionResult the client sends.
• New codes such as getSupportedVersion are implemented.

CastDevice, LaunchOptions, ApplicationMetadata and the status parcels already use the client's SafeParcel field ids.

Testing

• Six focused JVM framing tests passed in run 37091777804. JUnit XML reports 6 tests, 0 failures, 0 errors and 0 skipped. They exercise exact 65,536-byte encoded bodies, 65,537-byte rejection before writing/reading the body, and string/binary envelope overflow. The tested CastChannel source blob is 933fb0d2b3dd1549bad5594f6dff5373326e8031; the test files are included in this branch.
• ./gradlew :play-services-core:assembleVtmDefaultDebug :play-services-core:assembleVtmDefaultRelease succeeds.
• lintDebug on play-services-cast, play-services-cast-core, play-services-cast-framework and play-services-cast-framework-core reports 0 errors.
• The compiled CastChannel / CastDeviceSession classes were run on the JVM against a software CastV2 receiver. Every step passed:
  • TLS, device authentication and virtual connections;
  • heartbeat over 25 s idle;
  • launch, join by app and by session id, and launch with relaunchIfRunning=false joining the running instance;
  • leave, stop and relaunch;
  • volume and mute;
  • text, binary and media namespace messages, with unregistered namespaces filtered;
  • the payload limit, a refused platform namespace, and an unknown app id;
  • the receiver dying mid-session.
• Not yet tested on a phone against a physical Chromecast. The binder layer and the cast framework module have not been run on a device.

Remote-playback validation

The MediaRouter controller now handles the AndroidX remote-playback actions supported by this branch and returns the item ID separately from the item status in the result Bundle. The provider filter advertises only implemented actions.

The focused Cast core unit suite passed on validation commit ca1aa5c91630b72e179f4427432fb32298b1c98c in run 37174065096, with JUnit XML retained as artifact 11291879367. Debug and Release assemble and lint passed on that same validation commit. Only the six source/test files were forwarded into this PR; the validation workflow remains on the validation branch. The full build on PR commit de7c5de9f2e7c314a7b367bb4d0334672a1d471e also passed.

Known limitations

• A dropped connection ends the cast session. Play services instead suspends it and reconnects.
• Cast Connect launch options (androidReceiverCompatible, credentials) are not forwarded to the receiver.
• MediaRouter session-management and queue control intents remain unsupported; the provider filter excludes those actions.
• Discovery needs API 21 (NsdServiceInfo.getAttributes). Below API 34 a stuck resolve cannot be cancelled.
• The deviceauth signature is not verified, which matches master.

Related open PRs on the same files: #3351, #3354, #3377, #3470, #3505, #3554, #3567, #3570, #3577, #3668, #3781, #3802.

Closes #580

BountyHub contribution and conditional compensation request

Original PR submitter @woahwhattheheck (GitHub ID 293286387) affirmatively requests review, appropriate credit for the qualifying original Cast integration, and any eligible BountyHub issue #580 compensation, subject to the relevant creator's rules, maintainer acceptance, original human contribution and verified device/app results.

Existing matching BountyHub portal claim (do not resubmit): the $150 advertised BountyHub listing, UUID ef91cb1e-dd69-4a33-bd90-21c9679c9247, publicly includes @woahwhattheheck's original sponsor PR #3845 as a claimant. This is registration, not creator acceptance, an awarded amount, or settlement. The listed $100 promised plus $50 contribution must not be described as earned cash. Creator acceptance requires genuine casting from native/ReVanced YouTube, Crunchyroll and Netflix to Tizen and Chromecast targets; the current software receiver/JVM verification alone does not satisfy that device/application evidence.

Separate creator, not a second automatic claim: the $250 PROMISED listing, UUID 27c3cfe0-da9e-4192-848a-b676402de81c is a distinct creator requirement for /e/OS 3.x+ casting to Roku. The public claimant list checked in the October 8 intake did not include PR #3845, and this CastV2 implementation has no verified Roku compatibility or /e/OS-to-Roku demonstration. Sharing GitHub issue #580 does not transfer eligibility or $250 funding to the already registered $150 claim. Do not submit another portal claim without independent creator-specific technical and human-eligibility verification from the original contributor.

The PR source and author remain unchanged. No physical Chromecast/Roku/Tizen cross-app acceptance, reward adjudication, approved amount or payout is represented. This correction preserves the original contributor's existing claim and affirmative conditional compensation request, without waiver or duplicate filing.

[Tthecreator]

This look AI-ey again. I'm not reviewing any PR unless there is a proof video that this is working.

[eelcowijbrands]

Nice, this looks much more complete than what's on master. Cross-check from my side, in case it's useful: decompiling the Google Cast SDK side gave me connect() = 17, setListener() = 18, unregisterListener() = 19 on ICastDeviceController, and onConnectedWithResult(int) = 14 on the listener (after onConnected() = 13). If yours already matches, ignore me.
I'll close my own #3802 in favor of this one.

[woahwhattheheck]

Thanks for the SDK cross-check and for offering to consolidate #3802 into this PR. The controller connect/addListener/removeListener calls map to Binder transactions 17/18/19, and onConnectedWithResult(int) maps to 14, matching those numbers.

Checking the official Google Maven play-services-cast:22.3.1 artifact, the listener stub reads a status SafeParcelable at transaction 13 and an int at 14. The status parcel fields 2–6 match this branch's CastDeviceStatus. That matches onDeviceStatusChanged(CastDeviceStatus) at 13 rather than a no-argument callback. Which exact artifact/version did you inspect, and does its transaction 13 read a status parcel or take no arguments? That will help distinguish a naming difference from a version-specific callback layout.

[eelcowijbrands]

I checked again, did this against the official Maven artifacts (play-services-cast 21.5.0 and 22.3.1, bytecode of the stub and proxy). You are right about transaction 13, it reads a status parcel, not a no-argument callback. So the onConnected() = 13 in my #3802 was wrong, I'll drop that claim. Transaction 14 reads an int, which matches onConnectedWithResult(int), and the controller transactions are connect() = 17, setListener() = 18 and unregisterListener() = 19 in both versions.
One thing I noticed while checking: the whole numbering currently in microG's AIDL is off by one compared to both artifacts (disconnect is 0 in microG but 1 in the SDK, sendMessage 8 vs 9, launchApplication 12 vs 13, and the listener callbacks are shifted the same way). So a modern app won't cast against microG even if 17, 18 and 19 are added, unless the rest is renumbered too. I take it your implementation covers that, which makes this PR the right one. I'll close #3802 in favor of this.