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

[runningcode]

Summary

Refactors the async checkForUpdate() API to return a Future<UpdateStatus> instead of using a callback pattern, and uses SentryExecutorService for background execution instead of spawning new threads.

Changes

• API Change: Replaced callback-based checkForUpdate(UpdateCallback) with Future-based checkForUpdate()
• Thread Management: Now uses SentryExecutorService instead of creating new threads for each call
• Simplified API: Removed UpdateCallback interface entirely
• Consistency: Aligns with existing SDK patterns for async operations
• Resource Management: Leverages the shared thread pool to avoid creating unbounded threads

Benefits

• More flexible API - callers control which thread to consume the result on
• Better resource management through thread pooling
• Cleaner API surface without callback confusion
• Consistent with other SDK components that use SentryExecutorService

#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 d60461b

[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	351.88 ms	417.20 ms	65.32 ms
Size	1.58 MiB	2.11 MiB	539.70 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
23d6b12	354.10 ms	408.38 ms	54.28 ms
9fbb112	361.43 ms	427.57 ms	66.14 ms
1df7eb6	397.04 ms	429.64 ms	32.60 ms
c8125f3	397.65 ms	485.14 ms	87.49 ms
ee747ae	358.21 ms	389.41 ms	31.20 ms
b750b96	408.98 ms	480.32 ms	71.34 ms
f634d01	359.58 ms	433.88 ms	74.30 ms
806307f	357.85 ms	424.64 ms	66.79 ms
ee747ae	374.71 ms	455.18 ms	80.47 ms
ce0a49e	532.00 ms	609.96 ms	77.96 ms

App size

Revision	Plain	With Sentry	Diff
23d6b12	1.58 MiB	2.10 MiB	532.31 KiB
9fbb112	1.58 MiB	2.11 MiB	539.18 KiB
1df7eb6	1.58 MiB	2.10 MiB	532.97 KiB
c8125f3	1.58 MiB	2.10 MiB	532.32 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
b750b96	1.58 MiB	2.10 MiB	533.19 KiB
f634d01	1.58 MiB	2.10 MiB	533.40 KiB
806307f	1.58 MiB	2.10 MiB	533.42 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ce0a49e	1.58 MiB	2.10 MiB	532.94 KiB

Previous results on branch: no/eme-413-async-update-check

Startup times

Revision	Plain	With Sentry	Diff
9ac0631	402.78 ms	476.65 ms	73.87 ms
9212043	373.06 ms	450.63 ms	77.57 ms

App size

Revision	Plain	With Sentry	Diff
9ac0631	1.58 MiB	2.11 MiB	539.70 KiB
9212043	1.58 MiB	2.11 MiB	539.71 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.