feat(android-distribution): Run checkForUpdate on background thread (EME-413)

[runningcode]

Summary

Implements the async version of checkForUpdate() to run on a background thread instead of blocking the calling thread.

• Removes the TODO comment and implements proper async behavior using a simple Thread
• The callback is invoked on the background thread, allowing callers flexibility to dispatch to main thread if needed
• Adds documentation note explaining the threading behavior

Changes

• Modified DistributionIntegration.checkForUpdate() to spawn a background thread
• Updated KDoc to clarify callback threading behavior

#skip-changelog

Fixes EME-413

🤖 Generated with Claude Code

[linear]

EME-413 Ensure build distribution checkForUpdates method in the Java SDK runs in the background

[github-actions]

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

Generated by 🚫 dangerJS against 8ba2f76

[seer-by-sentry]

Potential bug: The onResult callback is not wrapped in a try-catch block, which could lead to an app crash if the user's implementation throws an exception.

• Description: The onResult.onResult(result) call is executed on a background thread without any exception handling. If the user-provided onResult callback throws an exception, it will be uncaught on that thread, likely causing the entire application to crash. This is inconsistent with other parts of the SDK, such as the handling of OnDiscardCallback, where user-provided callbacks are defensively wrapped in a try-catch block to prevent such failures.

• Suggested fix: Wrap the onResult.onResult(result) call within a try-catch (Throwable e) block. Log any caught exceptions using the provided logger, similar to the pattern used for other user callbacks in the SDK to protect the app from crashing.
  _{severity: 0.75, confidence: 0.95}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[runningcode]

This is a good point but we should just crash here.

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	373.06 ms	450.63 ms	77.57 ms
Size	1.58 MiB	2.11 MiB	539.71 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
23d6b12	354.10 ms	408.38 ms	54.28 ms
96449e8	361.30 ms	423.39 ms	62.09 ms
9fbb112	404.51 ms	475.65 ms	71.14 ms
ee747ae	396.82 ms	441.67 ms	44.86 ms
f634d01	375.06 ms	420.04 ms	44.98 ms
14ff5ee	419.75 ms	495.73 ms	75.98 ms
ee747ae	400.46 ms	423.61 ms	23.15 ms
806307f	357.85 ms	424.64 ms	66.79 ms
b750b96	421.25 ms	444.09 ms	22.84 ms
c8125f3	383.82 ms	441.66 ms	57.84 ms

App size

Revision	Plain	With Sentry	Diff
23d6b12	1.58 MiB	2.10 MiB	532.31 KiB
96449e8	1.58 MiB	2.11 MiB	539.35 KiB
9fbb112	1.58 MiB	2.11 MiB	539.18 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
f634d01	1.58 MiB	2.10 MiB	533.40 KiB
14ff5ee	1.58 MiB	2.10 MiB	535.08 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
806307f	1.58 MiB	2.10 MiB	533.42 KiB
b750b96	1.58 MiB	2.10 MiB	533.20 KiB
c8125f3	1.58 MiB	2.10 MiB	532.32 KiB

[chromy]

I think ideally we should:

• not create a new thread for this
• avoid a call back if we can (people will not read the comment and be confused when this crashes)

Looks like we already have some sort of common executor service which is used in the codebase and returns a future. Doesn't seem like it's Android aware (with Handlers / Loopers) but seems used from Android code.

• sentry-java/sentry/src/main/java/io/sentry/HostnameCache.java

  Line 133 in cf708bd

  final Future<Void> futureTask = executorService.submit(hostRetriever);

• sentry-java/sentry/src/main/java/io/sentry/SentryExecutorService.java

  Line 71 in cf708bd

  public @NotNull <T> Future<T> submit(final @NotNull Callable<T> callable)

• https://developer.android.com/develop/background-work/background-tasks/asynchronous/java-threads#use-handlers

[chromy]

To finish the thought XD : I think we should use that existing thing if at all possible, if not we should create something similar we can use. Spawning a new thread for each call will come back to bite us at some point.