fix: [SDK-4160] exclude OkHttp 5.x from otel module transitive dependencies

[fadi-george]

Description

One Line Summary

Exclude OkHttp 5.x transitive dependency from the otel module to prevent runtime crashes in consumers using OkHttp 4.x.

Details

Motivation

The otel module (added in 5.7.0) depends on opentelemetry-exporter-otlp, which transitively pulls in okhttp-jvm:5.2.1 via opentelemetry-exporter-sender-okhttp. OkHttp 5.x is binary-incompatible with OkHttp 4.x — specifically, okhttp3.internal.Util was removed in 5.x.

When a consumer (e.g. a React Native app) also depends on OkHttp 4.x, Gradle's conflict resolution upgrades everything to 5.2.1 (since OkHttp 5.x's module metadata declares okhttp-jvm replaces okhttp). This causes a NoClassDefFoundError: okhttp3/internal/Util crash at runtime when React Native's networking stack (ReactCookieJarContainer → JavaNetCookieJar) handles cookies.

Dependency chain:

com.onesignal:core:5.7.x
  → com.onesignal:otel:5.7.x
    → io.opentelemetry:opentelemetry-exporter-otlp:1.55.0
      → io.opentelemetry:opentelemetry-exporter-sender-okhttp:1.55.0
        → com.squareup.okhttp3:okhttp-jvm:5.2.1  ← breaks OkHttp 4.x consumers

Scope

• Excludes com.squareup.okhttp3 group from opentelemetry-exporter-otlp transitive dependencies
• Explicitly provides com.squareup.okhttp3:okhttp:4.12.0 (latest stable 4.x)
• OpenTelemetry's sender-okhttp uses standard public OkHttp APIs that are compatible with 4.x
• No changes to public API or behavior

Fixes #2575

Testing

Unit testing

All existing otel module unit tests pass (./gradlew :OneSignal:otel:testReleaseUnitTest).

Manual testing

Verified via ./gradlew :OneSignal:otel:dependencies --configuration releaseRuntimeClasspath that okhttp-jvm:5.2.1 no longer appears in the dependency tree and okhttp:4.12.0 is resolved instead.

Tested crash logs

Affected code checklist

• Notifications
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• 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.
• I have reviewed this PR myself, ensuring it meets each checklist item

Made with Cursor

[abdulraqeeb33]

can you please move the version number out in the root project?

[fadi-george]

I think I want to go with RN side fix for now @abdulraqeeb33