PlayerSurface shows a white background with audio

[Ilya193]

Version

Media3 main branch

More version details

implementation("androidx.media3:media3-exoplayer:1.9.0")
implementation("androidx.media3:media3-ui:1.9.0")
implementation("androidx.media3:media3-common:1.9.0")
implementation("androidx.media3:media3-ui-compose:1.9.0")

Devices that reproduce the issue

Huawei P40 Lite E

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

Create two screens so you can switch between them. When you first log in, everything works correctly on the screen where the video is displayed. On subsequent logins, the video is not displayed, but the audio plays.

Expected result

Video is displayed, audio plays

Actual result

The video is not displayed, but the audio plays

Media

Reproduce the problem
https://gist.github.com/Ilya193/a107dab71fb4ad275135faa78532b3eb

video_2025-12-31_20-22-44.mp4

Bug Report

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

[oceanjules]

Thank you for your report and trying out the new Compose modules.

I am a bit confused as to how to reproduce it, given that it's hard to see your actions from the screen recording alone. Are you using back navigation stack? Are you using 2 players? (PlayerSurface was built to support player swaps, so if it's a bug, we would want to catch it in tests)

media/libraries/ui_compose/src/test/java/androidx/media3/ui/compose/PlayerSurfaceTest.kt

Line 163 in 7cc1056

fun twoPlayerSurfaces_exchangePlayers_neverAssignsSurfaceSimultaneouslyAndAvoidsUnnecessaryRemoval() {

If possible, could you reproduce it by modifying our demo app and posting the MainActivity that leads to the bug:

media/demos/compose/src/main/java/androidx/media3/demo/compose/MainActivity.kt

Lines 36 to 44 in 7cc1056

	class MainActivity : ComponentActivity() {
	private val sharedViewModel: ComposeDemoViewModel by viewModels()
	override fun onCreate(savedInstanceState: Bundle?) {
	super.onCreate(savedInstanceState)
	enableEdgeToEdge()
	setContent { ComposeDemoApp(modifier = Modifier.fillMaxSize(), viewModel = sharedViewModel) }
	}
	}

[Ilya193]

Thank you for your reply.
The stack is not in use. The active screen is being switched. Only one player is used on the second screen.

Reproduce
https://github.com/Ilya193/JetpackMedia/blob/master/app/src/main/java/ru/ikom/jetpackmedia/MainActivity.kt
https://github.com/Ilya193/JetpackMedia

[oceanjules]

I have 2 improvement points:

1. I am not sure why you are using

setContentView(R.layout.activity_main)
val composeView = findViewById<ComposeView>(R.id.compose_view)

Are you trying to integrate all these new composables in your views? We have PlayerView for it (from androidx.media3.ui). Given that PlayerSurface (and now ContentFrame) are AndroidView wrappers of SurfaceView and TextureView, I think you end up doing too many round trips. You should be able to go straight to

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    enableEdgeToEdge()
    setContent {ExoPlayerExample() }
  }

---

2. Even though this is bad practice, it is slightly better than your current solution of initializing the player in ExoPlayerContent()

media/demos/compose/src/main/java/androidx/media3/demo/compose/layout/MainScreen.kt

Lines 52 to 62 in 7cc1056

	if (Build.VERSION.SDK_INT > 23) {
	// Initialize/release in onStart()/onStop() only because in a multi-window environment multiple
	// apps can be visible at the same time. The apps that are out-of-focus are paused, but video
	// playback should continue.
	LifecycleStartEffect(Unit) {
	player = initializePlayer(context, mediaItems)
	onStopOrDispose {
	player?.apply { release() }
	player = null
	}
	}

Even though you tried to remember it, you will completely destroy and reconstruct ExoPlayerContent() on every click. I believe the player will not be remembered because you are not recomposing the composable, you are removing it from the UI tree all together. A better way would be to initialize the player in some viewModel (which would also help you save playback state on configuration changes like screen rotation). Until then, you might want to lift up player initialization "higher" - i.e. in ExoPlayerExample(), then pass it into ExoPlayerContent(). Attach DisposableEffect to ExoPlayerExample and see if it works.

---

I tried out your activity and I can indeed reproduce your white screen. But it completely disappears when you do the change for point (1). See the attached video as proof.

ContentAB_Swap_PlayerSurfaceRecreated.mp4

[Ilya193]

Am I correct in understanding that ExoPlayer cannot be used if setContentView(layout) is used?

[oceanjules]

You are doing a huge unnecessary round-trip and PlayerSurface was not built to have that many wrappers around it. I cannot tell if there is a bug, but given that no one will ever be abusing the interop solutions like that, it doesn't make sense to investigate why exactly it goes wrong. Especially if it is fixed as soon as you use the recommended approach.

You need to first decide - do you want to have your app in Compose or Views? It's okay to have certain screens in one or the other, but when it comes to Media3 library, we are only supporting native solutions:

• PlayerView.java for views
• ContentFrame.kt/PlayerSurface.kt for Compose

Given that we still do not have a Compose solution that perfectly matches PlayerView (with ads, subtitles and scrubbing), it is understandable that some users will be doing this: AndroidView( factory = { context -> PlayerView(context)}, .... It's a valid solution, but not something we can keep debugging because PlayerView was not built with Compose in mind and any problems will be resulting from androidx.compose.ui.viewinterop.AndroidView, i.e. not Media3 library.

What you are doing is going backwards:

• taking PlayerSurface which is a composable and wrapping it in ComposeView which is a view. This makes no sense because you could already use PlayerView, but okay, this is just 1 level of interop.
• You take that view and set its content with ExoPlayerExample (which is a composable). So you went over to the Compose side again.
• ExoPlayerExample takes PlayerSurface (that's okay: composable -> composable)
• PlayerSurface == AndroidView(SurfaceView), i.e. going over to the views side again because there is no compose-native solution to surfaces, but that's okay.

You have to answer the question - why are you using xml layouts? Compose offers a completely different solution (https://developer.android.com/develop/ui/compose/layouts/basics) when it comes to building the screen into a grid/column/row etc. There is nothing that PlayerSurface provides right now that would give you the benefit over just getting PlayerView into your app and setting useController=false if you don't like the look of old buttons (but even that you can customize with icons).