[Android] Add Pre-Init memory buffer by FranAguilera · Pull Request #1208 · bitdriftlabs/capture-sdk

FranAguilera · 2026-09-15T14:01:17Z

Goal

Resolves BIT-9500

Adding a PreInit in memory buffer for the logger calls that occur while the SDK is starting internally.

This is the current flow in prod

And here with the proposal

The implementation does:

PreInitInMemoryLogger is added only when Capture state is LoggerState.Starting so all Capture.Logger.* calls are forwarded there
The instance is removed once we reach the Started/StartFailure state
Timestamps for each log are respected
To guard against potential OOM if starts is stuck, when the in memory cached calls reached a limit of 512 KB the new events will be dropped and an internal log will be emitted

Verification

Steps:

In the gradle-test-app, go to setting and enable, Start with simulated Delay and Start SDK on Background Thread

Restart the app, go to SDK tab and trigger many calls (e.g. Log Many messages) etc

The internal initialization priorly would have miss those logs but now they are added into the buffer and replaying later. See session

CHANGELOG.md's "Unreleased" section has been updated, if applicable.

github-actions · 2026-09-15T14:08:06Z

Android Size Comparison Report (x86_64)

Metric	APK (KB)	SO (KB)
Baseline	3504	1378
Current	3508	1378
Difference	4	0

APK size increased by 4 KB. SO size unchanged.

github-actions · 2026-09-15T14:11:24Z

Android Benchmark Results

Device: PR: Emulator - Android SDK built for x86_64 (API 31) | main: Emulator - Android SDK built for x86_64 (API 31)

Note: Benchmarks run on emulator. Results may vary between runs and may differ from physical devices.

Allocations

Test	PR	main	Δ
clearEntityId	0	0	0.0%
getSdkStatus	1	1	0.0%
logAppLaunchTTI	0	0	0.0%
logHttpNetworkLog50FieldsAndHeadersAndInitialFields	850	850	0.0%
logNotMatched5000Fields	10	10	0.0%
logNotMatchedNoFields	0	0	0.0%
loggerImplCreation	495	491	+0.8%
parseTreeWithOverlay	298	298	0.0%
parseTreeWithoutOverlay	298	298	0.0%
processJvmCrash	2253	2253	0.0%
processNativeCrash	2943	2943	0.0%
setEntityId	0	0	0.0%
startNewSession	0	0	0.0%
trackSpansWithFields	65	65	0.0%
trackSpansWithoutFields	45	45	0.0%
webViewBridgeBridgeReady	52	52	0.0%
webViewBridgeInvalidJson	38	38	0.0%

Timing

Test	PR	main	Δ
clearEntityId	89 ns	85 ns	+5.0%
getSdkStatus	189 ns	176 ns	+7.2%
logAppLaunchTTI	90 ns	83 ns	+9.4%
logHttpNetworkLog50FieldsAndHeadersAndInitialFields	215.76 us	200.58 us	+7.6%
logNotMatched5000Fields	2.40 ms	2.20 ms	+9.0%
logNotMatchedNoFields	724 ns	656 ns	+10.5%
loggerImplCreation	1.17 ms	1.19 ms	-1.6%
parseTreeWithOverlay	110.71 us	105.93 us	+4.5%
parseTreeWithoutOverlay	113.05 us	106.05 us	+6.6%
processJvmCrash	480.15 us	459.87 us	+4.4%
processNativeCrash	422.18 us	403.37 us	+4.7%
setEntityId	310 ns	281 ns	+10.1%
startNewSession	3.17 us	2.11 us	+50.2%
trackSpansWithFields	454.42 us	417.54 us	+8.8%
trackSpansWithoutFields	8.03 us	7.61 us	+5.6%
webViewBridgeBridgeReady	8.25 us	7.85 us	+5.1%
webViewBridgeInvalidJson	147.26 us	148.81 us	-1.0%

FranAguilera · 2026-09-16T15:58:07Z

        @JvmStatic
        val sessionUrl: String?
-            get() = logger()?.sessionUrl
+            get() = logger()?.takeUnless { it is PreInitInMemoryLogger }?.sessionUrl


ignores the pre init buffer value as we are not initialized. Also choose to not break the non-nullable contract on the ILogger api

I think this means that we'll break anyone doing

Capture.start() Capture.sessionUrl()

yeah?

i think most folks may be checking nullability to infer valid session url, so here there is no much change from that logic to keep this to be non-null until sdk is fully started

One thing we could do is to mark those (Capture.Logger.sessionUrl, Capture.Logger.sessionId, etc) as deprecated and direct people from the deprecation note to rely on the existing StartResult callback that returns an object with the non-nullable sessionId,url, etc when there is a successful start

wdyt?

snowp

Mostly makes sense to me, a few points and a few possible inconsistencies I spotted. We should decide whether we are okay with where this approach will get things slightly wrong in some cases or if we need to put in more effort for some of the edge cases

snowp · 2026-09-17T18:39:28Z

+     * Attaches the real logger to a span created before one existed yet (i.e. while the SDK was
+     * still starting), emitting its deferred start log and letting a subsequent end() call work.
+     */
+    internal fun attachLogger(logger: IInternalLogger) {


Would we want some kind of defensive programming here to avoid duplicate emission? Like a deferred flag or something that tells us whether we need to do this? The coordination here seems pretty loose

snowp · 2026-09-17T18:44:58Z

        @JvmStatic
        val sessionUrl: String?
-            get() = logger()?.sessionUrl
+            get() = logger()?.takeUnless { it is PreInitInMemoryLogger }?.sessionUrl


I think this means that we'll break anyone doing

Capture.start() Capture.sessionUrl()

yeah?

snowp · 2026-09-17T18:45:44Z

-            logger()?.also {
-                it.createTemporaryDeviceCode {
-                    mainThreadHandler.run { completion(it) }
+            logger()?.takeUnless { it is PreInitInMemoryLogger }?.also { logger ->


should we just have something like initalizedLogger() to avoid this predicate check in multiple places?

good call, will add it

snowp · 2026-09-17T18:48:32Z

+            val flushToNativeDuration =
+                measureTime {
+                    preInitInMemoryLogger.flushToNative(loggerImpl)
+                }
            default.set(LoggerState.Started(loggerImpl))


I think this is technically racy as we could get inbound logs after flushToNative ends and default.set is called? I think we'd need a lock or other work to make this better if we care about this narrow log drop chance

snowp · 2026-09-17T18:49:52Z


            startResult.invokeCatchingOrThrowOnDebug(CaptureResult.Success(loggerImpl))
        } catch (throwable: Throwable) {
+            preInitInMemoryLogger.clear()


Is this necessary? won't it be deallocated as part of updating default? Seems fine but not sure if we need it

If something can retain a handle to it then I imagine we'd want to make it drop inbounds as well if we wanted to avoid it doing all the log insertion and accounting

good point, will clean up

snowp · 2026-09-17T18:52:23Z

+    override fun setFeatureFlagExposure(
+        name: String,
+        variant: String,
+    ) = add(BufferedCall.StringFeatureFlagExposure(name, variant))


technically this ought to also capture the timestamp but maybe not worth the complexity to add

snowp · 2026-09-17T18:59:25Z

+        ) : BufferedCall {
+            override val sizeBytes = sized(request.toString())
+
+            override fun replay(logger: IInternalLogger) = logger.log(request)


wouldn't this also need a timestamp override? or is that captured in the request info? same for the other convenience functions

FranAguilera · 2026-09-18T15:23:10Z

Moving to draft until all feedback is addressed

FranAguilera force-pushed the franjam/add-pre-init-jvm-buffer branch 5 times, most recently from 6fbb1e0 to 6ca9807 Compare September 16, 2026 15:40

FranAguilera marked this pull request as ready for review September 16, 2026 15:52

FranAguilera requested a balanced review from Copilot September 16, 2026 15:54

Copilot started reviewing on behalf of FranAguilera September 16, 2026 15:56 View session

FranAguilera commented Sep 16, 2026

View reviewed changes

FranAguilera force-pushed the franjam/add-pre-init-jvm-buffer branch from 6ca9807 to 5d746a5 Compare September 16, 2026 15:58

This comment was marked as outdated.

Sign in to view

FranAguilera force-pushed the franjam/add-pre-init-jvm-buffer branch 3 times, most recently from 109ba17 to 769d6d2 Compare September 17, 2026 13:31

FranAguilera closed this Sep 17, 2026

FranAguilera reopened this Sep 17, 2026

github-actions Bot locked and limited conversation to collaborators Sep 17, 2026

FranAguilera requested a balanced review from Copilot September 17, 2026 13:47

Copilot started reviewing on behalf of FranAguilera September 17, 2026 13:48 View session

FranAguilera force-pushed the franjam/add-pre-init-jvm-buffer branch 4 times, most recently from 1a47142 to 8d95674 Compare September 17, 2026 14:27

[Android] Add Pre-Init memory buffer

fc5ac26

FranAguilera force-pushed the franjam/add-pre-init-jvm-buffer branch from 5503734 to fc5ac26 Compare September 17, 2026 14:37

FranAguilera requested a review from snowp September 17, 2026 15:33

bitdriftlabs unlocked this conversation Sep 17, 2026

snowp reviewed Sep 17, 2026

View reviewed changes

First round = Deprecation notice + extracting initializedLogger()

9258c20

FranAguilera marked this pull request as draft September 18, 2026 15:22

Conversation

FranAguilera commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Goal

Verification

Uh oh!

github-actions Bot commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Android Size Comparison Report (x86_64)

Uh oh!

github-actions Bot commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Android Benchmark Results

Allocations

Timing

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

Uh oh!

snowp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FranAguilera commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

FranAguilera commented Sep 15, 2026 •

edited

Loading

github-actions Bot commented Sep 15, 2026 •

edited

Loading

github-actions Bot commented Sep 15, 2026 •

edited

Loading