Android - Fix segfault crash when native surface is destroyed on vulkan

[emmauss]

What does the pull request do?

This pr checks for valid native surface on android when creating a vulkan surface.

What is the current behavior?

When android suspends an activity, all surfaces owned by that activity is destroyed. We do not do any checks on the validity if the surfaces when we start drawing and we try to create a khr surface using the handle of a destroyed surface, causing a segfault.

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

[avaloniaui-bot]

You can test this PR using the following package version. 11.3.999-cibuild0054141-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[kekekeks]

What happens to vulkan surface associated with android surface when android one gets destroyed? is it no longer valid?
If it's somehow marked as invalid, do we properly mark the relevant render target as corrupted so it would follow the normal dispose-and-recreate sequence?

[kekekeks]

Also, when it's not possible to create a valid render target for the current state of the native surface, the platform backend is supposed to throw RenderTargetNotReadyException rather than ArgumentException

[kekekeks]

I guess we silently try to re-create the surface/swapchain here:

Avalonia/src/Avalonia.Vulkan/Interop/VulkanDisplay.cs

Lines 229 to 246 in 0525455

	while (true)
	{
	var acquireResult = _context.DeviceApi.AcquireNextImageKHR(
	_context.DeviceHandle,
	_swapchain,
	ulong.MaxValue,
	_semaphorePair.ImageAvailableSemaphore.Handle,
	default, out _nextImage);
	if (acquireResult is VkResult.VK_ERROR_OUT_OF_DATE_KHR or VkResult.VK_SUBOPTIMAL_KHR)
	RecreateSwapchain();
	else if (acquireResult is VkResult.VK_ERROR_SURFACE_LOST_KHR)
	RecreateSurface();
	else
	{
	acquireResult.ThrowOnError("vkAcquireNextImageKHR");
	break;
	}
	}

but aren't throwing any exceptions that are expected by the compositor.

[kekekeks]

This leaks memory, BTW. ANativeWindow_fromSurface increases the reference counter for returned ANativeWindow object.

It's out of the scope of the current PR but should be addressed at some point

[kekekeks]

LGTM for the scope of the PR.

We need some general refactoring for our vulkan render target loss recovery code.

[emmauss]

What happens to vulkan surface associated with android surface when android one gets destroyed? is it no longer valid? If it's somehow marked as invalid, do we properly mark the relevant render target as corrupted so it would follow the normal dispose-and-recreate sequence?

When the android native surface is destroying, accessing the khr surface returns a surface lost vulkan error. We handle that by trying to recreate the vulkan surface, but since there's no valid native surface, it crashes with segfault at 2 points. First point of failure is using ANativeWindow api to access the native window for the destroyed surface, which will cause a segfault. The second point of failure is creating an android khr surface using a null handle.

[emmauss]

Also, when it's not possible to create a valid render target for the current state of the native surface, the platform backend is supposed to throw RenderTargetNotReadyException rather than ArgumentException

The Opengl backend throws its own custom exception, OpenGlException which there's no special catch for it anywhere in code.