Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SurfaceView & Compose issues still persist in API 35 #2158

Open
1 task
bigahega opened this issue Feb 17, 2025 · 3 comments
Open
1 task

SurfaceView & Compose issues still persist in API 35 #2158

bigahega opened this issue Feb 17, 2025 · 3 comments
Assignees
Labels

Comments

@bigahega
Copy link

Version

Media3 main branch

More version details

SurfaceView related bugs in Compose (flickering videos, cropped and/or stretched players) still persist in api 35. As of now there is a workaround setEnableComposeSurfaceSyncWorkaround which works alright in api 34 but not in 35 since the implementation has Util.SDK_INT == 34 checks which makes the workaround a no-op for api 35. Actual fix is yet to come from the Compose team so can you update the api level checks to cover 35 as well?

Devices that reproduce the issue

emulator running android 15 (api 35)

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

Expected result

Actual result

Media

Bug Report

  • You will email the zip file produced by adb bugreport to [email protected] after filing this issue.
@icbaker
Copy link
Collaborator

icbaker commented Feb 17, 2025

It sounds like you're reporting a re-occurrence of #1237 (which is what setEnableComposeSurfaceSyncWorkaround was introduced to resolve on API 34).

This is the original fix submitted by the graphics framework team that intended to resolve #1237 in API 35.

This landed in the android15-release branch.

It was then reverted (the revert did not land on the android15-release branch), and then both the revert and the roll-forward landed in the android15-qpr1-release branch.

So the expectation is that #1237 is fixed on API 35, because either the device will be using code from android15-release with the original fix or android15-qpr1-release (or later) where the roll-forward is present.

I just tried using the repro project from #1237 (comment) on a Pixel 7a running AP4A.250205.002 (Android 15) and wasn't able to reproduce the issue after several attempts. Whereas I reproduced immediately with the same APK on a Pixel Fold running AP2A.240905.003 (Android 14).

Please can you reproduce the issue on a real device running API 35? We have historically seen a lot of surprising UI/video behaviours on emulators, so it would be good to confirm it affects real devices too.

It would be useful to include more info as well, such as a screen recording of what you observe and the result of running adb bugreport after reproducing.

Reproducible in the demo app?

Yes

Can you please give the steps for reproducing in the demo app?

@bigahega
Copy link
Author

https://github.com/user-attachments/assets/b500998c-d144-4a21-b4d5-4e62dc80d3ed
https://github.com/user-attachments/assets/9a5ed3b6-35b7-4107-b144-6de53f4e41f0

In the first video at 00:10, I click on a video which goes into a different screen, at 00:12 I go back and land to the previous screen, top 2 videos start to flicker.

            if (Build.VERSION.SDK_INT == 35) {
                val utilClazz = Class.forName("androidx.media3.common.util.Util")
                val sdkIntField = utilClazz.getField("SDK_INT")
                val accessFlagsField = Field::class.java.getDeclaredField("accessFlags")
                accessFlagsField.isAccessible = true
                accessFlagsField.setInt(
                    sdkIntField,
                    sdkIntField.modifiers and java.lang.reflect.Modifier.FINAL.inv()
                )
                sdkIntField.set(null, 34)
            }

After adding this code above the PlayerView(), nothing gets flickered as can be seen in the second video.

    AndroidView(
        modifier = Modifier.fillMaxSize(),
        factory = { context ->
            // SDK_INT hack is applied here
            PlayerView(context).also {
                if (Build.VERSION.SDK_INT >= 34) {
                    it.setEnableComposeSurfaceSyncWorkaround(true)
                }
                it.useController = false
                it.player = exoPlayer
                it.resizeMode = AspectRatioFrameLayout.RESIZE_MODE_ZOOM
            }
        }
    )

After investigating a bit more upon your message, I saw that on API 35 even after removing the setEnableComposeSurfaceSyncWorkaround flag, the SDK_INT hack alone fixes the flickering, I don't know why.

Right now I do not have any physical device that got the Android 15 update but I'll see if I can find any.

@icbaker
Copy link
Collaborator

icbaker commented Feb 18, 2025

After investigating a bit more upon your message, I saw that on API 35 even after removing the setEnableComposeSurfaceSyncWorkaround flag, the SDK_INT hack alone fixes the flickering, I don't know why.

This does sound surprising (but then the original claim that the workaround is required on API 35 is also surprising, so 🤷)

Instead of using reflection to change media3's Util.SDK_INT (so that it's out of sync with Build.VERSION.SDK_INT, and you also change the behaviour of any other 34/35 API checks), would you consider building the library locally so that you can just change the condition you care about directly in the source code? That should give a better signal about whether changing the check to Util.SDK_INT == 34 || Util.SDK_INT == 35 resolves your problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants