chore: Release 6.1.7

[onesignal-deploy]

Channels: Current

🛠️ Native Dependency Updates

• Update Android SDK from 5.8.0 to 5.8.1
  • feat: SDK-4417: emit ossdk.features_enabled in Otel per-event payload (#2631)
  • push token on startup when notification permission already granted (#2622)
  • fix: clear unprocessedOpenedNotifs queue after replaying to new listener (#2632)
  • fix: login/logout race causes subsequent calls to target previous user (#2618)

[claude]

LGTM — straightforward release bump (6.1.6 → 6.1.7, native Android 5.8.0 → 5.8.1).

Extended reasoning...

Overview

This PR is a routine release bump: the version string in OneSignalSDK.DotNet.nuspec goes from 6.1.6 to 6.1.7, versions.json records the native Android SDK move from 5.8.0 to 5.8.1, and the two updated AAR binaries (core-release.aar, notifications-release.aar) are dropped into their respective binding projects' Jars folders. No managed C# / Java / Kotlin source is modified, no nuspec dependency versions change, and no build/CI configuration is touched.

Security risks

None introduced by this change. The native SDK upstream changelog covers a per-event Otel attribute, a push-token startup fix, a notification queue fix, and a login/logout race fix — all behavioral fixes/features in the native layer with no auth/crypto/permission surface relevant to the .NET binding.

Level of scrutiny

Low. This is a mechanical version bump that mirrors the well-established pattern from PR #177 (6.1.6) and PR #174 (6.1.5). The only mutable surface is the embedded AAR contents, which are consumed downstream by the same binding generators that have been validated for prior releases on this same major line.

Other factors

The bug hunting system surfaced one pre-existing finding: the bundled core-release.aar references com.onesignal.otel.* types that are declared as a runtime POM dependency on com.onesignal:otel but no otel-release.aar is bundled and the nuspec adds no Xamarin equivalent. The same condition existed in 6.1.5/6.1.6 (native 5.8.0). Native-side catch (Throwable) wrappers around the OTel startup paths and the API 26+ gate prevent a hard crash, so the practical impact is silent feature disablement (crash uploader, ANR detector, OTel logging, the new SDK-4417 features_enabled emission) rather than a runtime crash. The bug submitter explicitly notes this is not a release blocker and recommends a follow-up adding a OneSignalSDK.DotNet.Android.Otel.Binding — that's structural binding work that doesn't belong in a release-bump PR. The inline comment captures the recommended fix path so it doesn't slip through another version cycle.

[claude]

🟣 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.