fix: [SDK-4820] ship consumer dontwarn rule for OpenTelemetry to prevent R8 missing-class build failures

[abdulraqeeb33]

Summary

• Root cause: When a third-party SDK in the host app bumps opentelemetry-bom (e.g. Embrace -> 1.62.0), it upgrades OneSignal's transitive OpenTelemetry artifacts to a version where io.opentelemetry.api.internal.ApiUsageLogger has been removed. The transitively-pulled opentelemetry-api-incubator alpha (via ExtendedDefaultTracer) still references that class, so the cross-version skew surfaces as fatal R8 Missing class io.opentelemetry.api.internal.ApiUsageLogger errors in consuming apps even though the code path is never executed.
• Fix: Ship -dontwarn rules in the otel module's consumer-rules.pro. R8 suppresses a "Missing class" diagnostic when the missing class itself matches a -dontwarn, so we match the internal packages directly with -dontwarn io.opentelemetry.**.internal.** — this is referrer-independent and robustly covers ApiUsageLogger regardless of which artifact references it. We keep -dontwarn io.opentelemetry.api.incubator.** alongside it so R8 still surfaces warnings for OneSignal's own actively-used OTel classes (api.logs, sdk, exporter) if a bump ever breaks them. Because consumer rules ship inside the published AAR, this applies to every consuming app automatically — clients don't have to add their own keep/dontwarn rules to build.
• Risk: Low. This only suppresses R8 missing-class warnings for internal/incubator classes that aren't on the executed code path; it doesn't change runtime behavior.

The shipped rules are:

-dontwarn io.opentelemetry.api.incubator.**
-dontwarn io.opentelemetry.**.internal.**

This is the low-risk Option A. A longer-term Option B — aligning OneSignal's OpenTelemetry dependency versions (so the incubator alpha and core artifacts can't drift across versions) — is recommended as a follow-up.

Test plan

• Verify the -dontwarn io.opentelemetry.api.incubator.** and -dontwarn io.opentelemetry.**.internal.** rules ship in the published otel AAR's consumer ProGuard rules.
• Build a minified / R8-enabled app that also pulls a newer opentelemetry-bom (e.g. via Embrace) and confirm there is no Missing class io.opentelemetry.api.internal.ApiUsageLogger error.

Made with Cursor

[github-actions]

📊 Diff Coverage Report

✓ Coverage check passed (no source files changed)

📥 View workflow run

[fadi-george]

Could we narrow -dontwarn io.opentelemetry.**.internal.** to io.opentelemetry.api.internal.ApiUsageLogger or io.opentelemetry.api.internal.**?
The wildcard may suppress missing-class errors for the OTel SDK/exporter internals.

[abdulraqeeb33]

Good call @fadi-george — narrowed in 94d100b. Scoped the rule from io.opentelemetry.**.internal.** down to io.opentelemetry.api.internal.**, which still covers the dangling ApiUsageLogger reference (referrer-independent) but no longer suppresses missing-class errors in the OTel sdk/exporter internals we actually use. Went with the package wildcard rather than the exact ApiUsageLogger class so sibling api.internal classes that could drift the same way on a future BOM bump are covered too. Updated the explanatory comment in consumer-rules.pro accordingly.

[fadi-george]

nit: just update pr description