feat: [SDK-4999] emit Kotlin version on remote log resource attrs

[abdulraqeeb33]

Summary

Android host follow-up for OneSignal-KMP-SDK#17 (SDK-4999): supply KotlinVersion.CURRENT so remote logs include ossdk.kotlin_version for dashboard filtering.

Changes

• Submodule — pins OneSignal-KMP-SDK to KMP One Signal Android SDK getTags can't get all tags from server #17 (267b460, ar/sdk-4999).
• OtelPlatformProvider — kotlinVersion = KotlinVersion.CURRENT.toString().
• IOtelPlatformProvider / LoggerPlatformProviderAdapter — add abstract kotlinVersion / swiftVersion / additionalVersionAttributes (adapter forwards to the logger path).
• OtelFieldsTopLevel — mirrors KMP LogFieldsTopLevel (extras first, blank skip, ossdk. prefix normalize) so the legacy otel path stays at parity while both modules coexist.
• Tests — provider returns KotlinVersion.CURRENT; top-level attrs cover emit / blank omit / extras merge / reserved-key protection.
• Docs — mark :otel / IOtelPlatformProvider / OtelFactory as SDK-internal (not for public use).

Compatibility note

Adding the new abstract members on IOtelPlatformProvider is a deliberate source-compatibility break for any external implementor of that interface. :otel is published and OtelFactory accepts the type, but this is an SDK-internal injection seam — the only production implementor is OtelPlatformProvider in :core, and there are no known external consumers. We are not adding default methods or a capability interface for this reason.

Merge order

1. Land OneSignal-KMP-SDK#17 first.
2. Merge this PR (re-pin submodule to the merged KMP SHA / release tag if the tip moves).

Test plan

• Code review vs KMP One Signal Android SDK getTags can't get all tags from server #17 contract
• :OneSignal:core:testDebugUnitTest --tests "*OtelPlatformProviderTest*"
• :OneSignal:otel:testDebugUnitTest --tests "*OtelFieldsTopLevelTest*"
• :OneSignal:core:compileDebugKotlin against pinned submodule
• After KMP merge: re-pin to merged SHA / tagged release via bump workflow when available

Made with Cursor

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff).

Changed Files Coverage

• LoggerPlatformProviderAdapter.kt: 0/3 touched executable lines (0.0%) (4 touched lines in diff)
  • 3 uncovered touched lines in this file
• OtelPlatformProvider.kt: 4/4 touched executable lines (100.0%) (17 touched lines in diff)
• OtelFieldsTopLevel.kt: 13/13 touched executable lines (100.0%) (39 touched lines in diff)

Overall (aggregate gate)

17/20 touched executable lines covered (85.0% — requires ≥ 80%)

Per-file detail (informational; gate is aggregate above):

• LoggerPlatformProviderAdapter.kt: 0.0% (3 uncovered touched lines)

📥 View workflow run

[fadi-george]

Two issues to address before merge:

• java.specification.version is hardcoded to "0.9" on Android, so ossdk.java_version would be misleading. Robolectric returns the host JDK version and masks this behavior.
• Default interface getters preserve source compatibility, but older compiled IOtelPlatformProvider implementations may still throw AbstractMethodError.

Also, please trim attribute keys before removing ossdk. to avoid emitting ossdk.ossdk.*.

[fadi-george]

One compatibility concern remains: making these properties abstract removes source compatibility but does not prevent older compiled implementations from throwing AbstractMethodError.

The KDoc also says the interface and Android implementation share an artifact, but IOtelPlatformProvider is in :otel while OtelPlatformProvider is in :core. Please use an optional capability interface or explicitly treat this as a breaking API change.

[abdulraqeeb33]

Agreed the KDoc was wrong on the same-artifact claim (IOtelPlatformProvider is in :otel, OtelPlatformProvider in :core).

We're deliberately not adding a capability interface or default methods here though: this isn't a public implementor surface. The only production implementor is our own OtelPlatformProvider, and app/wrapper authors never implement IOtelPlatformProvider. AbstractMethodError for "older compiled external implementors" isn't a real consumer risk for this type.

Updated the KDoc to say SDK-internal only and dropped the misleading binary-compat framing.

[fadi-george]

I understand this is intended as SDK-internal, but it is still publicly exposed from the published :otel module, and public OtelFactory methods accept it. KDoc alone does not make it internal.

Adding abstract properties is therefore a source-breaking API change for any external implementor. If we accept that risk because there are no known consumers, please document it as a deliberate compatibility break and update the PR body, which still says defaults preserve compatibility.

[abdulraqeeb33]

@fadi-george Good catch — agreed. Updated to document :otel / IOtelPlatformProvider / OtelFactory as SDK-internal (not for public implementors), explicitly called out the deliberate source-compat break for the new abstract members, and fixed the PR body so it no longer claims defaults preserve compatibility.

[abdulraqeeb33]

I understand this is intended as SDK-internal, but it is still publicly exposed from the published :otel module, and public OtelFactory methods accept it. KDoc alone does not make it internal.

Adding abstract properties is therefore a source-breaking API change for any external implementor. If we accept that risk because there are no known consumers, please document it as a deliberate compatibility break and update the PR body, which still says defaults preserve compatibility.

Discussed with @fadi-george - the otel module is something that will always be consumed internally. We should deter external users to use it as we won't be supporting external usage of this module.