[QA] Offload System.loadLibrary call to background thread

[markushi]

📜 Description

Perform System.loadLibrary() on a background thread.

💡 Motivation and Context

Calling System.loadLibrary() causes StrictMode violations, as it performs disk reads, but any JNI calls like initSentryNative needs the libraries to be loaded beforehand.

Initializing the whole NDK off the main thread would be an option, but it has two main disadvantages:

• there's no guarantee that the NDK is initialized after SentryAndroid.init(), thus we could miss early startup crashes
• all NDK communication (setUser, setTag) needs to be done on a background thread as well

So the trick is to perform System.loadLibrary() as early as possible on a background thread, but still perform NDK init synchronous on the main thread. In my testing this works well, as the SDK init in-between takes longer than the .loadLibrary() calls, making the loadLibraryLatch.await(2000, TimeUnit.MILLISECONDS) return immediatelly.

💚 How did you test it?

Just manually, haven't found a better way yet.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 5c35128

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	396.45 ms	443.06 ms	46.61 ms
Size	1.70 MiB	2.35 MiB	667.99 KiB

Previous results on branch: feat/async-ndk-loadlib

Startup times

Revision	Plain	With Sentry	Diff
f813acb	422.98 ms	461.52 ms	38.54 ms

App size

Revision	Plain	With Sentry	Diff
f813acb	1.70 MiB	2.35 MiB	667.56 KiB

[markushi]

Comparing the performance metrics with other PRs, we can see a nice 35-45% improvement of the startup time 🚀

[kahest]

@markushi sounds very promising 👍 any creative ways to test this end-to-end? basically (how) can we guarantee this doesn't break any part of startup/initialization?

[kahest]

for reference: this is related to/fixes (partially) #3585 and #3654

[stefanosiano]

Looks good!
Not sure how/if we can test it, but "logically" it works

[romtsn]

I think we wanted to make it part of the next major (8.x.x) - do we still wanna do that?

Aside, this looks good, and I think eventually we could offload the native init to the background thread as well, because we wanted to move setTag, setBreadcrumbs to background anyway.