MAPSAND-366 Fix ANR while open and close MapView quickly with textureView set to true, fix potential crash on RenderHandlerThread creation.

[paulrenn67]

Summary of changes

Lazy initialization of handlerThread is not really needed since anyone who creates an instance of RenderHandlerThread is going to render a map, and can cause issues with handler/handlerThread values not being aligned.

Also fixed and renamed started method to avoid potential deadlock due to race condition on some devices when onSurfaceDestroyed is called right after destroy.

Added new tests to check start/stop works as expected.

User impact (optional)

Pull request checklist:

• Briefly describe the changes in this PR.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. If tests were not written, please explain why.
• Optimize code for java consumption (@JvmOverloads, @file:JvmName, etc).
• Add example if relevant.
• Document any changes to public APIs.
• Run make update-api to update generated api files, if there's public API changes, otherwise the verify-api-* CI steps might fail.
• Update CHANGELOG.md or use the label 'skip changelog', otherwise check changelog CI step will fail.
• If this PR is a v10.[version] release branch fix / enhancement, merge it to main firstly and then port to v10.[version] release branch.

Fixes: < Link to related issues that will be fixed by this pull request, if they exist >

PRs must be submitted under the terms of our Contributor License Agreement CLA.

[CLAassistant]

All committers have signed the CLA.

[yunikkk]

Not sure I see how the fix prevents the ANR, could you elaborate? isAlive will just return false if start was not called, right?
However I agree we might not need a separate start since it's used in single place and constructor call is coupled with start

[paulrenn67]

Not sure I see how the fix prevents the ANR, could you elaborate? isAlive will just return false if start was not called, right? However I agree we might not need a separate start since it's used in single place and constructor call is coupled with start

Hi, originally handlerThread was lateinit, so calling the started method would result in a call on an uninitialized object. This fix essentially just ensures that handlerThread is always valid.

[yunikkk]

``

Hi, originally handlerThread was lateinit, so calling the started method would result in a call on an uninitialized object. This fix essentially just ensures that handlerThread is always valid.

Ok, so it would then crash, and this PR is about preventing this crash and not ANR, got it.

[paulrenn67]

``

Hi, originally handlerThread was lateinit, so calling the started method would result in a call on an uninitialized object. This fix essentially just ensures that handlerThread is always valid.

Ok, so it would then crash, and this PR is about preventing this crash and not ANR, got it.

Yes, this should fix another crash that I noticed just with code inspection. I think Kevin's fix is also combined here.

[kiryldz]

@paulrenn67 🎉 on your first PR here!
Several notes:

• please add changelog entry, smth like Fix possible ANR when destroying renderer
• please sign an SLA otherwise PR could not be merged
• rename the PR and update PR description as the scope slightly changed with your fixes

[yunikkk]

Looks good!

[paulrenn67]

@paulrenn67 🎉 on your first PR here! Several notes:

• please add changelog entry, smth like Fix possible ANR when destroying renderer
• please sign an SLA otherwise PR could not be merged
• rename the PR and update PR description as the scope slightly changed with your fixes

@kiryldz hopefully all ok now?