Stack trace
Production Android releases crash during DatadogSdk.initialize while registering RUM or Logs event mappers through the generated JNI bridge.
Native stack sampled independently by Google Play:
signal 11 (SIGSEGV), SEGV_MAPERR, null-address access
libart.so art::InvokeVirtualOrInterfaceWithVarArgs
libart.so art::JNI<false>::CallVoidMethodV
libdartjni.so globalEnv_CallVoidMethod+224
libapp.so stub CallNativeThroughSafepoint
Symbolized Dart stacks from Crashlytics continue from CallNativeThroughSafepoint into one of these paths:
DatadogRumPlugin$Companion._setRumEventMapper.#ffiClosure10
DatadogRumPlugin$Companion.setRumEventMapper
AndroidRumEventMapper
DdRumMethodChannel.enable
DatadogRum.enable
DatadogSdk.initialize
or:
DatadogLogsPlugin$Companion._setLogsEventMapper.#ffiClosure10
DatadogLogsPlugin$Companion.setLogsEventMapper
AndroidLogEventMapper
DdLogsMethodChannel.enable
DatadogLogging.enable
DatadogSdk.initialize
This is related in native shape to #942, but our setup does not use Session Replay. The recovered Dart frames consistently select mapper registration during SDK initialization rather than widget-tree capture.
Reproduction steps
No deterministic local reproduction yet. Production setup is a normal Flutter application initialized once during bootstrap:
final configuration = DatadogConfiguration(
clientToken: clientToken,
env: environment,
service: service,
nativeCrashReportEnabled: true,
loggingConfiguration: DatadogLoggingConfiguration(),
rumConfiguration: DatadogRumConfiguration(
applicationId: applicationId,
traceSampleRate: traceSampleRate,
sessionSamplingRate: sessionSamplingRate,
telemetrySampleRate: telemetrySampleRate,
actionEventMapper: (_) => null,
),
site: DatadogSite.us5,
firstPartyHosts: firstPartyHosts,
);
await DatadogSdk.instance.initialize(
configuration,
TrackingConsent.granted,
);
Session Replay is not enabled and datadog_session_replay is not in the dependency graph.
The failures are concentrated around Android process / Flutter-engine startup. An audio foreground service exists in the same process and was starting near sampled failures, but current evidence establishes timing and process co-residence only; it does not establish that audio code caused the invalid JNI receiver or memory corruption.
Volume
436 fatal events across 392 distinct installations on Android build 3.36.0 (113329), Aug 19–26, 2026. 121 current events preserve libdartjni.so. In a fully symbolized 95-event JNI subset, every event recovered Datadog event-mapper registration during DatadogSdk.initialize: 51 RUM mapper registrations and 43 Logs mapper registrations, with one remaining mapper-family sample. Session percentage is unavailable from the crash export.
Affected SDK versions
datadog_flutter_plugin 3.5.0datadog_tracking_http_client 3.2.0datadog_dio 2.2.0- transitive
jni 0.14.2
Latest working SDK version
Unknown.
Does the crash manifest in the latest SDK version?
Yes. 3.5.0 is the latest pub.dev release as of 2026-08-26.
Flutter Version
3.44.8
Setup Type
Flutter application on Android. Datadog native crash reporting, Logs, and RUM enabled; Session Replay disabled. Release mode, arm64.
Device Information
Observed across multiple installations and devices. A representative event was Samsung SM-S926N, Android 16, arm64. The cohort is not limited to one model.
Other relevant information
- The crash happens before
DatadogSdk.initialize completes.
- Both RUM and Logs generated companion mapper calls appear, so this does not look specific to one configured mapper callback.
- The immediate fault is a null or invalid JNI receiver at
globalEnv_CallVoidMethod; the upstream ownership boundary may involve generated JNI companion-receiver lifetime handling.
- We can provide additional symbolized Crashlytics or Play Console samples if useful.
Stack trace
Production Android releases crash during
DatadogSdk.initializewhile registering RUM or Logs event mappers through the generated JNI bridge.Native stack sampled independently by Google Play:
Symbolized Dart stacks from Crashlytics continue from
CallNativeThroughSafepointinto one of these paths:or:
This is related in native shape to #942, but our setup does not use Session Replay. The recovered Dart frames consistently select mapper registration during SDK initialization rather than widget-tree capture.
Reproduction steps
No deterministic local reproduction yet. Production setup is a normal Flutter application initialized once during bootstrap:
Session Replay is not enabled and
datadog_session_replayis not in the dependency graph.The failures are concentrated around Android process / Flutter-engine startup. An audio foreground service exists in the same process and was starting near sampled failures, but current evidence establishes timing and process co-residence only; it does not establish that audio code caused the invalid JNI receiver or memory corruption.
Volume
436 fatal events across 392 distinct installations on Android build 3.36.0 (113329), Aug 19–26, 2026. 121 current events preserve
libdartjni.so. In a fully symbolized 95-event JNI subset, every event recovered Datadog event-mapper registration duringDatadogSdk.initialize: 51 RUM mapper registrations and 43 Logs mapper registrations, with one remaining mapper-family sample. Session percentage is unavailable from the crash export.Affected SDK versions
datadog_flutter_plugin3.5.0datadog_tracking_http_client3.2.0datadog_dio2.2.0jni0.14.2Latest working SDK version
Unknown.
Does the crash manifest in the latest SDK version?
Yes. 3.5.0 is the latest pub.dev release as of 2026-08-26.
Flutter Version
3.44.8
Setup Type
Flutter application on Android. Datadog native crash reporting, Logs, and RUM enabled; Session Replay disabled. Release mode, arm64.
Device Information
Observed across multiple installations and devices. A representative event was Samsung SM-S926N, Android 16, arm64. The cohort is not limited to one model.
Other relevant information
DatadogSdk.initializecompletes.globalEnv_CallVoidMethod; the upstream ownership boundary may involve generated JNI companion-receiver lifetime handling.