`DdRumContentProvider` added to manifest despite not using RUM feature about dd-sdk-android HOT 3 OPEN

Hi @lwasyl and thanks for this question.

This is not a bug, but mostly a side effect of using the com.datadoghq:dd-sdk-android-okhttp dependency, which provides OkHttp integration for both RUM and Trace features.

The DdRumContentProvider is mostly a no-op provider that simply measures the timestamp and reason for the. process startup. It's then used by RUM features, but you can safely remove it from your build if you need to.

from dd-sdk-android.

Thank you, it wasn't clear to me that okhttp is a common artifact that bundles integration related to okhttp for all features 👍

In that case I might suggest to expose the RUM dependency as api in the okhttp, since right now removing the attribute is tricky as IDE doesn't see RUM classes. However I see that RUM classes are part of public API of e.g. DatadogInterceptor so exposing them would make sense overall.

Would you consider separating artifacts for okhttp-tracing and okhttp-rum integrations separately? TracingInterceptor doesn't seem to depend on RUM by itself

from dd-sdk-android.

In that case I might suggest to expose the RUM dependency as api in the okhttp, since right now removing the attribute is tricky as IDE doesn't see RUM classes. However I see that RUM classes are part of public API of e.g. DatadogInterceptor so exposing them would make sense overall.

That's a good point, I'll add it to our backlog indeed

Would you consider separating artifacts for okhttp-tracing and okhttp-rum integrations separately? TracingInterceptor doesn't seem to depend on RUM by itself

That's another solution, which goes in a direction that we think is too verbose, especially since the RumInterceptor relis on the TracingInterceptor, so those two are kinda coupled.

from dd-sdk-android.