-
Notifications
You must be signed in to change notification settings - Fork 314
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 inside Compose AndroidView often shown stretched/cropped on API 34 #1237
Comments
+1 this |
@phcannesson Yes, we found this issue and tried to reproduce it on the device without the last patch but we can't. However, once we updated the phone, the issue appeared. |
We have the same problem. We had already observed this in the QPR but unfortunately did not create an issue. Interestingly, we "only" have the problem if we use the AndroidView (which creates the PlayerView) in an if block, i.e. the composable is not called immediately. |
Please can you test this? It would help us to debug if we know whether it can be reproduced in the demo app.
Is this true for everyone else that has commented on this bug? Is everyone else experiencing this only in Compose contexts, or also in conventional views? This looks like it might be a duplicate of #1123 but it's interesting to hear that the behaviour changes between Android 14 before the March 5th update and after it. |
On our side we're using Compose. |
I have faced exact same issue, except I was using resizeMode with fixed height. |
@icbaker It is not reproducible in the demo app |
Hi @icbaker , I was also not able to reproduce the issue on your demo app on Pixel 7, Android 14, march 5th update, but we have the issue in our compose app using AndroidView. The issue is present in this sample app that uses compose, (press on the "Exo PlayerView" button): This is what it looks like: |
On our side, after some testing, we've detected that it seems to be related to the way the frame layout gets notified of changes in the player. |
I've tried adding a delay to the sample app above (with a boolean mutable state and a LaunchedEffect), but the stretch is still present when It shows. |
I found a "fix", the stretch is gone when using Is it true that |
Thanks for the repro app in #1237 (comment). I ran this on a Pixel 7a running I added an I then flashed my device back to before the March feature release, to I observed the following in logcat right at the start of playback in the problematic case on
The same part of logcat in the working case on
And finally, the problematic case on
There are two key differences between the working and problematic cases:
|
I can confirm that it seems to fix. I've created a public repo to reproduce and play with the configuration : The player with |
While digging in AOSP code, I've noticed this change : It seemed to have been released in Android 14 QPR2. It's a wild guess, but I thought it was worth mentioning. |
Trying the same video in the main ExoPlayer demo app on the same device + build ( This is perhaps obvious, but it adds more weight to the theory that the problem is related to how Full logcat:
|
With QPR2 our QA also started to report the issue, so very likely related. |
We are seeing this now when migrating to compose :( |
This seems a duplicate of #1123 |
Also reproducible on an emulator using |
I have filed an issue internally to ask for assistance from the Window Manager team (who own SurfaceView) and Compose folks: b/334901521 |
Any chance to make the issue public to follow the discussion? Or it (may) contains confidential information? |
I want to report that at our company we face the same issue on some Google Pixel 8 Pro devices. We’ve identified the regression back to the clipping calculation of the We would greatly appreciate if the vendor could keep us updated on the issue if we do not have any chances to follow the discussion on b/334901521. |
Very plausible but that behavior is still flag-disabled (note all the new paths are guarded by Flags.clipSurfaceviews() which is still false and never shipped as true). It's possible a path was missed there, but it's supposed to not be doing anything at the moment. |
I can confirm that the clipping change is not the cause of this issue. |
@jreck This is very interesting, thanks for your investigation. So there seems to be another cause of the issue that was introduced on the 5th, March 2024, that is somehow correlated to hardware acceleration, Jetpack Compose, and Google Pixel phones. |
The issue is that somehow this transaction isn't happening: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/SurfaceView.java;drc=a7ba109ec6c7c1ca82f96651863b3d2c10c6bc34;l=2113 In the repro app the transaction that updates the bounds of the SurfaceView is just getting dropped on the floor, so the compositor still thinks it's the original square dimensions thus the stretching. But it's not clear yet why or why Compose specifically seems to trigger this. We have a platform workaround, though, but no guidance yet on a Compose workaround since the root cause isn't understood yet. |
I've done a bit more testing on different Android versions. This is on Pixel 7a and Pixel Fold (folded). My observations:
I suspect this may be why the issue has become more obvious since the March 2024 release. Before this point it was quickly resolved as soon as something else changed (in this case the controls appearing), but after this the problem persists. |
This workaround is only applied on API 34, because the problem isn't present on API 33 and it is fixed in the platform for API 35 onwards. Issue: #1237 #cherrypick PiperOrigin-RevId: 644729909
I've updated the title of this issue to reflect that this isn't specific to With the support of the graphics team, I've also submitted a workaround (linked above) to |
Previously we assumed that `surfaceSyncGroupV34` was always non-null on API 34, but this isn't true in edit mode. Instead we add an explicit null-check before accessing it. We don't need to null-check it at the other usage site because we are already null-checking `surfaceView` (via `instanceof` check). Issue: #1237 #cherrypick PiperOrigin-RevId: 645008049
Version
Media3 main branch
More version details
1.3.0, 1.2.1, 1.1.1
Devices that reproduce the issue
Pixel running on Android 14 with updated to 5 March 2024 (important)
Devices that do not reproduce the issue
Pixel running on Android 14 without updated to 5 March 2024
Reproducible in the demo app?
Not tested
Reproduction steps
Here is code that could help to reproduce.
Expected result
Media should be visible correctly
Actual result
Media shows with a wrong aspect ratio
Media
Here is how it looks
Bug Report
adb bugreport
to [email protected] after filing this issue.The text was updated successfully, but these errors were encountered: