Is this a new issue with beta 1? Have you reproduced this on earlier dev builds?

Testing master (292e50e) on a pixel4 and I get the same splash screen with the compatibility renderer and with the mobile renderer. In both cases it is wrong, but it doesn't show nothing.

Testing master (292e50e) on a pixel4 and I get the same splash screen with the compatibility renderer and with the mobile renderer. In both cases it is wrong, but it doesn't show nothing.

The splash screen you're seeing is being generated by the Android runtime and has several limitations. As a result of those limitations, we're reverting back to the Godot generated splash screen in #92965.

If you build from that PR, you can see the behavior described in this issue. To make it more noticeable, you should increase the splash screen duration in the project settings.

Is this a new issue with beta 1? Have you reproduced this on earlier dev builds?

The issue was reproducible in earlier dev builds.

If this is a regression, it would be good to pinpoint when it appeared. But if the issue isn't reproducible without #92965 as the splash screen doesn't even work, how do we know it's a regression, as opposed to something that never worked?

If this is a regression, it would be good to pinpoint when it appeared. But if the issue isn't reproducible without #92965 as the splash screen doesn't even work, how do we know it's a regression, as opposed to something that never worked?

The Godot generated splash screen was enabled for the Android editor even before #92965 (the logic that sets show_logo to false didn't apply to tools builds).
And the project manager always uses the compatibility renderer regardless of platform, which is how I noticed the regression.

I had a bit of a debugging session on this. For me it neither works on compatibility nor mobile renderer. I've only looked closely into the compatibility side (edit - it does work on mobile, my mistake).

Here the splash screen is prepared from Main::setup2 where it will end up calling set_boot_image.

The implementation of this can be found in drivers/gles3/rasterizer_gles3.cpp, it nicely loads our image into a texture, gets some screen info (checked this works), and then blits the texture into our main system_fbo. Pretty straight forward.

But then in order to display it, it calls end_viewport, and end_viewport called DisplayServer::get_singleton()->swap_buffers().

On all other systems this triggers a buffer swap displaying the result of the current buffer displaying that.

On android it sets a flag:

void DisplayServerAndroid::swap_buffers() {
	swap_buffers_flag = true;
}

That's it... the buffer is swapped for display, it's not being displayed...

The code on Android only works once the game is running. Once init is done, onDrawFrame gets triggered each frame, calls into GodotLib.step(), which prepares a frame, and returns whether our swap_buffers_flag was set, which triggers the GLSurfaceView to swap the buffers.

This logic is not accessed during setup.

Sadly my knowledge of Android is lacking to know how to fix this.