Skip to content

chore: Release 6.1.7 #178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
abdulraqeeb33 merged 1 commit into from
May 4, 2026
Merged

chore: Release 6.1.7 #178

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file modified OneSignalSDK.DotNet.Android.Core.Binding/Jars/core-release.aar
View file
Open in desktop
Binary file not shown.
Binary file modified OneSignalSDK.DotNet.Android.Notifications.Binding/Jars/notifications-release.aar
View file
Open in desktop
Binary file not shown.
2 changes: 1 addition & 1 deletion OneSignalSDK.DotNet.nuspec
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<version>6.1.6</version>
<version>6.1.7</version>

Check notice on line 4 in OneSignalSDK.DotNet.nuspec

View check run for this annotation

Claude / Claude Code Review

Missing com.onesignal:otel transitive dependency 

Pre-existing: native core 5.8.1 (and 5.8.0 before it) declares `com.onesignal:otel:5.8.1` as a runtime POM dependency, and the bundled `core-release.aar` directly references `com.onesignal.otel.*` types (e.g. `OtelFactory`, `IOtelLogger`, `IOtelCrashReporter`, `IOtelOpenTelemetryCrash`, `OtelAnrDetector`), but no `otel-release.aar` is bundled and the nuspec adds no Xamarin equivalent. Net effect on .NET/MAUI consumers is that OTel-driven features (crash uploader, ANR detector, OTel logging, the

@claude claude Bot May 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟣 Pre-existing: native core 5.8.1 (and 5.8.0 before it) declares com.onesignal:otel:5.8.1 as a runtime POM dependency, and the bundled core-release.aar directly references com.onesignal.otel.* types (e.g. OtelFactory, IOtelLogger, IOtelCrashReporter, IOtelOpenTelemetryCrash, OtelAnrDetector), but no otel-release.aar is bundled and the nuspec adds no Xamarin equivalent. Net effect on .NET/MAUI consumers is that OTel-driven features (crash uploader, ANR detector, OTel logging, the new SDK-4417 features_enabled per-event payload) are silently disabled on Android 26+ — OtelLifecycleManager and OneSignalCrashUploaderWrapper wrap startup in catch (Throwable), so the NoClassDefFoundError is swallowed rather than crashing the app. PR #176 already mirrored other 5.8.0+ transitive deps (KotlinX.Serialization.Json, Lifecycle.*Ktx, Activity.Ktx); com.onesignal:otel was the missed sibling. Suggest a follow-up adding a OneSignalSDK.DotNet.Android.Otel.Binding that wraps otel-5.8.1.aar (present on Maven Central) and listing it in the nuspec — not a release blocker.

Extended reasoning...

What is wrong

The bundled core-release.aar contains direct bytecode references to com.onesignal.otel.* types but the .NET binding does not ship the corresponding otel-release.aar. Verified empirically:

  • core-5.8.1.pom (Maven Central) declares <groupId>com.onesignal</groupId><artifactId>otel</artifactId><version>5.8.1</version><scope>runtime</scope> — same declaration exists in the 5.8.0 POM.
  • javap on OtelAnrDetector.class extracted from the bundled core-release.aar shows: implements com.onesignal.otel.crash.IOtelAnrDetector, fields of type com.onesignal.otel.IOtelLogger / com.onesignal.otel.IOtelCrashReporter, constructor parameter com.onesignal.otel.IOtelOpenTelemetryCrash, invokevirtual com.onesignal.otel.OtelFactory.createCrashReporter, and invokestatic com.onesignal.otel.crash.OtelCrashHandlerKt.isOneSignalAtFault. OneSignalCrashUploaderWrapper returns com.onesignal.otel.crash.OtelCrashUploader and is registered as an auto-started IStartableService in CoreModule.
  • The bundled AndroidManifest.xml carries tools:overrideLibrary="com.onesignal.otel" — explicit acknowledgement that otel is a separate AAR expected to be merged in.
  • The .NET repo: only four AARs ship (core, location, in-app-messages, notifications). No otel*.aar anywhere; update_native_binaries.sh never fetches it; the nuspec lists no Xamarin.OpenTelemetry.* / com.onesignal.otel equivalent. otel-5.8.1.aar (63,809 bytes) is publicly available at repo1.maven.org/maven2/com/onesignal/otel/5.8.1/.

Why this is pre-existing, not a regression

Same condition existed in 6.1.5 / 6.1.6 (native 5.8.0). PR #176 explicitly audited 5.8.0+ transitive deps and added Xamarin.KotlinX.Serialization.Json, Lifecycle.ViewModel.Ktx, Lifecycle.Runtime.Ktx, and Activity.Ktx, but did not include otel. Whether that omission was deliberate or an oversight is unclear, but the existing inline comments (<!-- Required by FeatureFlagsJsonParser in native core 5.8.0+ -->) follow the same shape one would use for an otel binding.

Real impact: silent feature disablement, not a hard crash

Addressing the refutation: a refuting verifier correctly notes there are gates that prevent the NoClassDefFoundError from reaching users in most paths. Confirming this:

  1. API gate: OtelSdkSupport.isSupported() returns false below API 26; OtelLifecycleManager.initializeFromCachedConfig() returns early with the log 'Device SDK < 26, Otel not supported — skipping all Otel features'. So devices below API 26 are unaffected.
  2. Throwable catches: On API 26+, OtelLifecycleManager.initializeFromCachedConfig/subscribeToConfigStore/startCrashHandler/startAnrDetector/startOtelLogging and OneSignalCrashUploaderWrapper.start each wrap their bodies in catch (Throwable) with log strings like 'OneSignal: Failed to start crash handler:'. Throwable includes NoClassDefFoundError, so the missing classes manifest as a logged error, not a process crash.
  3. Feature flag: OTel emission is also gated by remote config (OtelConfigEvaluator.evaluate), so on most production .NET clients OTel paths never start in the first place.

So the bug submitter's framing of 'runtime crash' overstates impact. The accurate impact is: on Android 26+, every OTel-backed feature is broken silently — crash uploads via OtelCrashUploader, ANR detection via OtelAnrDetector, OTel logging, and the new SDK-4417 ossdk.features_enabled per-event payload all fail to start, are caught, and are logged. The 5.8.0->5.8.1 bump itself does not materially expand the surface area; SDK-4417 only adds an attribute to existing emission paths, all of which live inside the unbundled otel AAR.

Step-by-step proof

  1. App embeds the 6.1.7 NuGet (this PR) on Android 26+.
  2. OneSignal.initWithContext runs DI; CoreModule registers OneSignalCrashUploaderWrapper as IStartableService.
  3. The startable service container calls OneSignalCrashUploaderWrapper.start(). Its return type OtelCrashUploader is in com.onesignal.otel.crash.
  4. The classloader must resolve com.onesignal.otel.crash.OtelCrashUploader to verify the method signature when the method is first invoked → NoClassDefFoundError.
  5. The catch (Throwable) wrapper logs 'OneSignal: Failed to start crash handler:'. The app keeps running. Crash uploads are off for this user.
  6. Later, when remote config flips OTel emission on, OtelLifecycleManager.startOtelLogging and startAnrDetector follow the same path → all three OTel subsystems remain dark for the .NET consumer.

How to fix

Mirror the PR #176 pattern: add a sibling binding project (e.g. OneSignalSDK.DotNet.Android.Otel.Binding) that wraps otel-5.8.1.aar from Maven Central, reference it from OneSignalSDK.DotNet, and add the resulting otel-release.aar plus the binding DLL/PDB to the <files> block in OneSignalSDK.DotNet.nuspec. Update update_native_binaries.sh to fetch the otel artifact alongside the existing four. Ship in a follow-up PR — this is structural work and not appropriate to bundle into a release-bump PR.

Why flagging on this release PR

Pre-existing and out of scope to fix here, but PR #176 already established that the team is paying down the 5.8.0+ transitive-dep gap, and otel was the missed sibling. This release PR is the natural place to log the follow-up so it doesn't slip through another version cycle.

<id>OneSignalSDK.DotNet</id>
<title>OneSignal SDK for .NET and MAUI</title>
<authors>OneSignal</authors>
Expand Down
2 changes: 1 addition & 1 deletion versions.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
{
"android": "5.8.0",
"android": "5.8.1",
"ios": "5.5.1"
}
Loading