ANRs and logs from the previous app run are not connected

[markushi]

It looks like we're using the wrong scope on Android to capture logs.

Here are some logs before an ANR was capture: https://sentry-sdks.sentry.io/explore/logs/?end=2025-08-20T15%3A30%3A43&logsFields=timestamp&logsFields=message&logsSortBys=-timestamp&project=5428559&start=2025-08-20T11%3A00%3A43&utc=true

And here's the ANR event being sent on the next app start:

https://sentry-sdks.sentry.io/issues/6811829844/events/df2116c9c3b940aab283fab7e7930547/?project=5428559&query=is%3Aunresolved%20issue.category%3A%5Berror%2Coutage%5D&referrer=next-event

Debugging reveals the the trace id being persisted doesn't match the trace id being used to capture the log item:

sentry-java/sentry/src/main/java/io/sentry/logger/LoggerApi.java

Lines 119 to 139 in b93e18d

	final @Nullable SentryDate timestamp = params.getTimestamp();
	final @NotNull SentryDate timestampToUse =
	timestamp == null ? options.getDateProvider().now() : timestamp;
	final @NotNull String messageToUse = maybeFormatMessage(message, args);
	final @NotNull IScope combinedScope = scopes.getCombinedScopeView();
	final @NotNull PropagationContext propagationContext = combinedScope.getPropagationContext();
	final @Nullable ISpan span = combinedScope.getSpan();
	if (span == null) {
	TracingUtils.maybeUpdateBaggage(combinedScope, options);
	}
	final @NotNull SentryId traceId =
	span == null ? propagationContext.getTraceId() : span.getSpanContext().getTraceId();
	final @NotNull SpanId spanId =
	span == null ? propagationContext.getSpanId() : span.getSpanContext().getSpanId();
	final SentryLogEvent logEvent =
	new SentryLogEvent(traceId, timestampToUse, messageToUse, level);
	logEvent.setAttributes(createAttributes(params.getAttributes(), message, spanId, args));
	logEvent.setSeverityNumber(level.getSeverityNumber());
	scopes.getClient().captureLog(logEvent, combinedScope);

, so this is probably an issue around using the wrong scope.

[linear]

JAVA-139 ANRs and logs from the previous app run are not connected

[stefanosiano]

It looks like it's correct
What happens in our sample app is that when we click the ANR button we create a transaction (or continue the app start transaction), due to our auto-instrumentation.
This transaction sets the traceId persisted to disk
The logger gets the same traceId from the span/transaction and attaches it to the log
Then the transaction finishes, changing the traceId persisted to disk, due to TWP
Then the app is killed for the ANR, with the TWP traceId

This is the case when I click the ANR button

TraceId in LoggerApi is 09825962a0e24083a5ffe39d483c1c7d and span is io.sentry.SentryTracer@639b787 <- log when clicking the button
Store traceId from spanContext 09825962a0e24083a5ffe39d483c1c7d <- trace of span is stored to disk
Store traceId from scope.propagationContext 653f46ea2aae4c89914fa8b34dd4ddbe <- transaction finished before the anr occurs

This happens if I start a span when i click the ANR and never finish it

TraceId in LoggerApi is a8542ed29d444e4bade9c6c69c0c9f25 and span is io.sentry.Span@9cbca96 <- log when clicking the button
Store traceId from spanContext a8542ed29d444e4bade9c6c69c0c9f25 <- trace of span is stored to disk

So, if the span is running, both logs and ANR (and span) have the same traceId.
If the span finished before the ANR, they will have different traceId.

This is by design, but a followup issue has been created