[andr] Move expensive operations on start to a bg thread

[murki]

Tackling mainly:

• monitorNetworkType() (went from 9.70% to 0.79%)
• writeSdkStartLog() (went from 2.27% to 0%)

This should make start() perform 11.18% faster

Before	After

Session example testing the SDKConfigured log with the right network_type value: https://timeline.bitdrift.dev/session/fda02916-f33f-4365-8262-94d6132b2266?utm_source=sdk&pages=1&utilization=0&h=3450357454420969661

After the change this is the threading structure:

connectivityManager operations called in thread=io.bitdrift.capture.background-thread-worker
updateNetworkType() callback called in thread=io.bitdrift.capture.background-thread-worker
updateNetworkType() callback called in thread=ConnectivityThread
writeSdkStartLog() called in thread=io.bitdrift.capture.background-thread-worker

[Copilot]

Pull Request Overview

This PR offloads two startup operations—network monitoring and SDK start logging—to a background thread using an ExecutorService.

• Introduce an executor parameter in NetworkAttributes and schedule monitorNetworkType() on it.
• Update LoggerImpl to pass its dispatcher’s executor and defer writeSdkStartLog() onto that executor.
• Adjust tests to supply a direct executor for deterministic execution.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
platform/jvm/capture/src/test/kotlin/io/bitdrift/capture/NetworkAttributesTest.kt	Inject MoreExecutors.newDirectExecutorService() into all NetworkAttributes usages for tests
platform/jvm/capture/src/main/kotlin/io/bitdrift/capture/attributes/NetworkAttributes.kt	Added ExecutorService parameter and moved monitorNetworkType() into its execute block
platform/jvm/capture/src/main/kotlin/io/bitdrift/capture/LoggerImpl.kt	Pass executorService into NetworkAttributes and wrap writeSdkStartLog() in executorService.execute

Comments suppressed due to low confidence (1)

platform/jvm/capture/src/main/kotlin/io/bitdrift/capture/LoggerImpl.kt:266

• [nitpick] There are no tests verifying that writeSdkStartLog() is actually scheduled on the executorService. Adding a unit test to confirm it runs off the main thread would help prevent regressions.

        eventListenerDispatcher.executorService.execute {

[Copilot]

Since monitorNetworkType() is deferred to a background thread, invoke() may return an outdated network_type if it runs before this task completes. Consider synchronizing initial execution or documenting this behavior so consumers understand the potential race window.

[murki]

This is fine since as a default value we have "unknown" which might happen for the first log or so if there's a race condition. In my tests above that wasn't the case though

[FranAguilera]

Oh actually missed that we are changing the reported start thread via writeSdkStartLog. We should store the caller thread name and pass it into writeSdkStartLog otherwise will report incorrectly

[FranAguilera]

Regarding thread start name

[github-actions]

📦 APK Size Report

Metric	Size (KB)
Baseline	3433
Current	3433
Difference	0

✅ APK size unchanged.

[github-actions]

📦 APK Size Report

Metric	Size (KB)
Baseline	3433
Current	3393
Difference	-40

✅ APK size decreased by 40 KB.