Open NasH5169 opened 11 months ago
Hello,
I confirm this bug real device Samsung S21 Ultra as well.
Thanks.
Reproduced the problem on S22
For me, on S23+, it happens when I go to a memory-demanding app before returning to my app. Also, rotating the phone reloads the app and that fixes the problem (until the next time).
Perhaps it is a good opportunity to support Jetpack Composables?
...Also, rotating the phone reloads the app and that fixes the problem (until the next time).
This does not work on my side.
Is anyone seeing a difference in behaviour between using SurfaceView and TextureView?
I only have a sample size of 1 on this, but aside from reduced performance I haven't seen this rendering freeze if I enable TextureView.
Tried it on a Samsung Galaxy Tab S9.
How to enable TextureView? Could you please give us some details in order to test on our devices? Thank you.
Edit: This setting?
@Override protected void preControlCreated() { mapSettings.useSurfaceView = false; }
The GlobeController
/MapController
constructor takes in a GlobeController.Settings
/MapController.Settings
object, respectively. So I just pass one in with surfaceView
set to false.
val controller = GlobeController(context, GlobeController.Settings().apply { useSurfaceView = false })
We noticed reduced performances with this setting applied yes but it doesn't fix this issue.
You still see the drawing freeze?
Absolutely, the map works normally until you move the application to the background and then back to the foreground. When the app comes foreground the map is freeze.
Are you sure to have Android 14 on your tablet?
Yeah, it's Android 14 with One UI 6.0. I was only able to try it out on the one device.
Yeah, it's Android 14 with One UI 6.0. I was only able to try it out on the one device.
And you are reproducing the issue with SurfaceView (default mode)?
Yes, I was able to reproduce it with the steps outlined here.
Perhaps it could be about the system being more aggressive with resource management, considering @JtxGit remarks regarding needing to move to a memory-intensive app before seeing the issue.
Yes, I was able to reproduce it with the steps outlined here.
Perhaps it could be about the system being more aggressive with resource management, considering @JtxGit remarks regarding needing to move to a memory-intensive app before seeing the issue.
Ok thank you very much for this confirmation. Unfortunately, I was able (for now) to test the basic application on Android 14 but not with Google Pixel models. With an Android 14 emulator, no issue. Only with Samsung Android 14.
I should add that it seems it's only the drawing that's frozen. The map is still panning and zooming around.
If you can keep the instance open, but, say, load and display another fragment on top, then remove it, the map visually updates to the newest state. It doesn't draw as normal, it's still frozen in that sense, but it updates when it is visible again.
I don't know your app's flow or if you can otherwise try this out. I don't know what could be happening, but it seems like relevant information.
The map can still receive user interaction like click / pan / zoom, it can be seen in logcat, but visually, the map is frozen. My app is quiet complex so to reduce complexity I have achieve the simple basic map tutorial available on the mousebird whirlyglobe website. I believe that recreating the map fragment when the application comes back from background to foreground could be a solution but it is not a elegant solution as the activity and the fragment already exit. Perhaps, @TimSylvester or @sjg-wdw could help us.
Unfortunately, my device has not updated to 14.
It sounds like it might be an issue with the OpenGL context. You might try different renderer options under Settings / Renderer in the emulator. Any GL-related output in the logs could be helpful, you can set a breakpoint in CheckGLError
to avoid missing any.
Hello,
I am quite confused with the last answers on this topic. What are the next steps?
To make it clear, this issue is not related to any custom app flow nor switching/moving to a "more intensive" app.
I tested the bare bone Hello World project on a Samsung S21 Ultra and clicking on the home button and coming back to the app will freeze the map 100% of the time (without having any other app running nor switch to another app).
We know that one of the biggest differences between a bare bone Android 14 OS and a Samsung custom Android 14 is the OneUI layer. It seems that there are several issue with rendering related to the latest OneUI 6.0 shipped with Samsung Android 14, could it be a clue?
@TimSylvester
Unfortunately, my device has not updated to 14.
Fine, but are you planning to update it and/or try to find a samsung device on which you can debug and help moving forward on this issue?
@TimSylvester
It sounds like it might be an issue with the OpenGL context. You might try different renderer options under Settings / Renderer in the emulator. Any GL-related output in the logs could be helpful, you can set a breakpoint in
CheckGLError
to avoid missing any.
Not sure to understand how this can help. It was said that there is no issue with simulator and to my knowledge we cannot load any simulator with Samsung OS.
Thanks everyone and happy new year.
@Adraesh
A little research seems to indicate that my device will never get Android 14, unfortunately, and I don't have any specific plans to replace it.
If setting the simulator to Native OpenGL instead of SwiftShader, for example, causes it to happen there then I may be able to debug it. But if it's specific to OneUI, you're right that is probably a dead-end.
If there are errors logged, or other clues, I might theoretically be able to do something without needing to reproduce it locally.
I created a small test app (using your Android tutorial code and the latest dev aar file) and get the same behaviour (as with my app, SweMaps) on my S23+.
Going away from the app by pressing Home, and then immediately returning mostly does not freeze the screen, but going to (for example Google Maps) first before returning to the app, does consistently freeze the screen.
This does not happen on a Pixel 6a with Android 14 nor my Pixel 4a with Android 13. Only on my Samsung S23+ with Android 14.
The log mentions things like "2024-01-07 10:23:31.223 12546-12546 SurfaceView@870f244 se.eko_tek.wgtest D updateSurface: surface is not valid". Not sure what exactly that means, since I have unfortunately no knowledge about the deeper workings of SurfaceViews..
I attach the log file in case it is useful.
WGTest20240107a.txt
Perhaps, related to this:
Interesting. I don't think "surface is not valid" is coming from WhirlyGlobe.
From the comments above it sounds like forcing a repaint would not be enough, as interacting with the map should be doing that already. If the backing texture is indeed changing format as one comment indicates, a workaround like the one shown there would probably require re-creating the map control when resumed on an affected device.
Hi all,
Coming back on this issue because Samsung will not fix this issue and I have more and more users who are using Samsung and Android 14. I could recreate all the activity on coming back from background but I prefer recreate only the mapfragment, if I am run this code:
` MapFragment newMapFragment = new MapFragment(); FragmentManager fragmentManager = getSupportFragmentManager(); FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
fragmentTransaction.replace(R.id.fragment, newMapFragment);
fragmentTransaction.commit();
`
I get the following error:
java.lang.ClassCastException: android.opengl.GLSurfaceView cannot be cast to android.view.ViewGroup
Any idea?
Thanks guys
Hello,
There seems to be a problem with Android 14 on real devices, particularly Samsung S21/22/23. The application is very simple and shows a map as in the tutorial on your website.
The scenario:
A problem with the fragment? I don't know where to look... Any ideas?
Thank you very much.