WIP - Feat: OpenTelemetry crash reporting #2405

jkasten2 · 2025-11-06T17:43:58Z

Description

One Line Summary

Add OpenTelemetry libraries to report crashes to improve SDK reliability.

Details

Motivation

Allows us to quickly identify and fix issues caused by this SDK.

Scope

Only adds OpenTelemetry to track crashes.

Testing

Unit testing

TODO: Need to add unit testing yet.

Manual testing

Tested on an Android 14 Emulator:

Throw RuntimeException from example app and ensure SDK can catch it
Ensured our crash handler saves it to a file, even when it is offline
Ensured the last crash is sent to a remote server when the app is opened again.

Tested has only been done with a known working Otel backend, HoneyComb, until we
have our own backend to receive the payload.

Remaning Tasks

Add unit tests
Turn on only if in remote parameters
uncaughtException
- Add try-catch, so any of our logic can't cause side-effects if something goes wrong
- Shutdown any in progress uploading of crashes
Look into if we can use older libraries so we don't have to use Kotlin 2.2
Crash handling only works with Android 8, due to Otel libraries, look into if it easy to support olde version of Android.

Affected code checklist

Checklist

Overview

I have filled out all REQUIRED sections above
PR does one thing
- If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
Any Public API changes are explained in the PR details and conform to existing APIs

Testing

I have included test coverage for these changes, or explained why they are not needed
All automated tests pass, or I explained why that is not possible
I have personally tested this on my device, or explained why that is not possible

Final pass

Code is as readable as possible.
- Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
I have reviewed this PR myself, ensuring it meets each checklist item
- WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

This change is

Adding disk-buffering to otel logging required bumping to Kotlin 2.2. Adding the code to implement this in a follow up commit.

When the app is started again we send any pending crash reports.

Also refactored crash handle classes into their own namespace. Refactored IOneSignalOpenTelemetry properties into suspend functions, as some values we want to add to all Otel requests were suspend.

Also made all otel types internal and a few other misc cleanup.

We need to start it sooner to catch crashes in things like other IStartableService's.

Models can throw if something goes wrong initializing them.

abdulraqeeb33 · 2025-12-16T17:59:51Z

...K/onesignal/core/src/main/java/com/onesignal/debug/internal/crash/IOneSignalCrashReporter.kt

@@ -0,0 +1,5 @@
+package com.onesignal.debug.internal.crash


can we place all the logging related code in its own module, just in case we go in the direction of KMP, it will be extremely easy to build an artifact out this.

I'll make this a new module, that core depends on. We can switch the module to KMP later.

...SDK/onesignal/core/src/main/java/com/onesignal/debug/internal/crash/OneSignalCrashHandler.kt

abdulraqeeb33 · 2025-12-16T18:10:03Z

.../src/main/java/com/onesignal/debug/internal/logging/otel/config/OtelConfigRemoteOneSignal.kt

+    }
+
+    object HttpRecordBatchExporter {
+        @RequiresApi(Build.VERSION_CODES.O)


The minSdk supported as of now is 21. What would happen when this method gets called on a App that is between 21 and 26 (version_code.0)?

Need to test and most likely need to handle this.

...core/src/main/java/com/onesignal/debug/internal/logging/otel/crash/OneSignalCrashUploader.kt

abdulraqeeb33 · 2025-12-16T18:13:42Z

...ignal/core/src/main/java/com/onesignal/debug/internal/logging/otel/OneSignalOpenTelemetry.kt

+        mapOf(
+            "X-OneSignal-App-Id" to appId,
+            HTTP_SDK_VERSION_HEADER_KEY to HTTP_SDK_VERSION_HEADER_VALUE,
+            "x-honeycomb-team" to "", // TODO: REMOVE


should we remove this?

abdulraqeeb33 · 2025-12-16T18:23:05Z

...rc/main/java/com/onesignal/debug/internal/logging/otel/crash/OneSignalCrashConfigProvider.kt

+import java.io.File
+
+internal class OneSignalCrashConfigProvider(
+    private val _applicationService: IApplicationService


we should be able to pass the the path directly here instead of depending on our SDK class

abdulraqeeb33 · 2025-12-16T18:24:44Z

.../src/main/java/com/onesignal/debug/internal/logging/otel/crash/OneSignalCrashReporterOtel.kt

+                .put("$OS_OTEL_NAMESPACE.exception.thread.name", thread.name)
+                .build()
+
+        _openTelemetry


How are we sure that this is ready with all the relevant fields populated into itself?

abdulraqeeb33 · 2025-12-16T18:26:17Z

...ignal/core/src/main/java/com/onesignal/debug/internal/logging/otel/OneSignalOpenTelemetry.kt

+
+    override suspend fun forceFlush(): CompletableResultCode {
+        val sdkLoggerProvider = getSdk().sdkLoggerProvider
+        return suspendCoroutine {


does this work while the app is being closed down by the OS? Does it have to run on the main thread?

Double check that suspendCoroutine isn't making a new thread.

abdulraqeeb33 · 2025-12-16T18:27:40Z

...ignal/core/src/main/java/com/onesignal/debug/internal/logging/otel/OneSignalOpenTelemetry.kt

+    _osPerEventFields: OneSignalOtelFieldsPerEvent,
+) : OneSignalOpenTelemetryBase(_osTopLevelFields, _osPerEventFields),
+    IOneSignalOpenTelemetryRemote {
+    private val appId: String get() =


can we make this lazy so that it fetches on time and then stores it in the memory?

abdulraqeeb33 · 2025-12-16T18:28:34Z

OneSignalSDK/onesignal/core/build.gradle

        }
    }

+    implementation platform("io.opentelemetry:opentelemetry-bom:1.55.0")


can we create variables for the versions numbers used here instead of hardcoding them here?

jkasten2 added the WIP Work In Progress label Nov 6, 2025

jkasten2 added 10 commits December 8, 2025 18:39

feat: base parts to send otel crash reports

e5b4e4f

feat: disk buffering for Otel

483c8d1

Adding disk-buffering to otel logging required bumping to Kotlin 2.2. Adding the code to implement this in a follow up commit.

feat: Otel crash reports log to disk

3a60cef

When the app is started again we send any pending crash reports.

feat: add top level fields

04a620c

Also refactored crash handle classes into their own namespace. Refactored IOneSignalOpenTelemetry properties into suspend functions, as some values we want to add to all Otel requests were suspend.

feat: add Otel shared per event fields

17dcf00

Also made all otel types internal and a few other misc cleanup.

chore: improved names and lint fixes

052ddfa

feat: Add idempotency key to Otel events

38ba6fb

fix: update HTTP headers sent to otel endpoints

fc0d830

fix: start crash handler sooner

f7ab8a0

We need to start it sooner to catch crashes in things like other IStartableService's.

fix: error handling around models

a61e2bc

Models can throw if something goes wrong initializing them.

jkasten2 force-pushed the otel-crash-reporting branch from 21d4198 to a61e2bc Compare December 8, 2025 23:58

feat: add remote param for remote logging

597b858

abdulraqeeb33 reviewed Dec 16, 2025

View reviewed changes

WIP - Feat: OpenTelemetry crash reporting #2405

Are you sure you want to change the base?

WIP - Feat: OpenTelemetry crash reporting #2405

Uh oh!

Conversation

jkasten2 commented Nov 6, 2025 • edited by niels-s Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

One Line Summary

Details

Motivation

Scope

Testing

Unit testing

Manual testing

Remaning Tasks

Affected code checklist

Checklist

Overview

Testing

Final pass

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jkasten2 commented Nov 6, 2025 •

edited by niels-s

Loading