CastContext never restores previous CastState after app returns to foreground

[WSteverink]

Version

Media3 main branch

More version details

Summary

CastContext stops updating its CastState after the app returns from the background. When the app is backgrounded, the state changes from DEVICE_AVAILABLE to NO_DEVICES_AVAILABLE as expected, but on resume the state never returns to DEVICE_AVAILABLE and no further state callbacks are triggered. This leaves the app stuck in an incorrect cast-state until restart.

We are updating our UI based on this CastState, which is now partially broken.

Reproduce

To reproduce this, use the latest Media3 main branch and run the demo-session variant.

Within the MainActivity, add:

    override fun onResume() {
        super.onResume()
        val snapshot = CastContext.getSharedInstance(this).castState
        Log.d("[DEBUG]", "onResume: snapshot $snapshot")
    }

And within the MainActivity.onCreate add:

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        CastContext.getSharedInstance(this).addCastStateListener { state ->
            Log.d("[DEBUG]", "addCastStateListener: $state <-----")
        }

Now run the app and make sure that casting devices are available.
Steps:

1. Observe that the listener prints CastState 2 (DEVICES_AVAILABLE).
2. Background the app.
3. Observe that the listener prints CastState 1 (NO_DEVICES_AVAILABLE) — as expected.
4. Return the app to the foreground.
5. Observe that the listener does not print a new state, and the snapshot printed in onResume is still CastState 1 (NO_DEVICES_AVAILABLE).

I might be missing something, but it seems that this listener is not working correctly. Any help is highly appreciated. Keep up the good work, and thanks in advance.

Devices that reproduce the issue

Samsung a51 Android 13
Pixel 7 Android 16

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[AquilesCanta]

Hi @WSteverink, thanks for reporting. Cast devices are not guaranteed to be available all the time, they are only expected to be discovered while the app is scanning, and scanning is guaranteed to be disabled when the app is in the background (for system resource saving reasons). What I'm trying to say is that this, as is, is not necessarily a bug.

One way of checking if there's actually a bug here is checking whether devices are not available as expected when you press the cast button. The rationale is that the cast button (or rather, the dialog that pops when the cast button is pressed) triggers a route scan, and therefor guarantees that cast devices will be discovered (or if they are not discovered, it's indicative of a bug).

So, I have the following questions for you:

• Are you unable to see any routes in the device picker dialog that shows up when you press the cast button? If they show up, then there's no bug, we are just missing a scan request.
• What are you trying to achieve by accessing the routes directly? There might be a better way of doing what you need to do. Or, at least we can trigger a scan in a way that doesn't eat up unnecessary resources because you are scanning pretty much all the time.

[WSteverink]

• Are you unable to see any routes in the device picker dialog that shows up when you press the cast button? If they show up, then there's no bug, we are just missing a scan request.

Nope, when i use the CastButton i do see my devices being discovered.

• What are you trying to achieve by accessing the routes directly? There might be a better way of doing what you need to do. Or, at least we can trigger a scan in a way that doesn't eat up unnecessary resources because you are scanning pretty much all the time.

We have a custom design for the CastButton (at the client’s request). We use the CastState from the listener to create our own CastUiState, which we then use to update the UI, such as enabling or disabling buttons. And we use it to decide whether we want to send metadata changes to the player. This works seamlessly with ExoPlayer, but not with CastPlayer.

For now, we could check whether the CastPlayer is being used to determine if casting is active, and fall back to the default CastButton instead of the custom one, since the default button behaves correctly.

Sample code:

        val listener = CastStateListener { castState ->
                CastUiState(
                    isCasting = listOf(
                        CastState.CONNECTED,
                        CastState.CONNECTING
                    ).contains(castState),
                    hasDevicesAvailable = castState != CastState.NO_DEVICES_AVAILABLE,               
            )
        }