Manoel Aranda Neto

I think it's not needed for v1 since this can be added later, it is not a behavior or API surface breakage, unless doing this requires changes in the API...

> Keep the [OtelRumConfig](https://github.com/open-telemetry/opentelemetry-android/blob/d7d5045c8178b0a6069ae93c1cd0b11dc6641fe0/instrumentation/src/main/java/io/opentelemetry/android/config/OtelRumConfig.java#L19) object focused on the initialization process only, preventing it from becoming a sort of cumbersome “god object” to deal with in the future, full of feature...

Yeah, I think the `TrueTime` is the most reliable one - on device, other alternatives depend on clock drifting on the server which we cannot control as a vendor-agnostic lib....

Might be needed for v1, assuming a device has the wrong date and time, and after upgrading the SDK with an NTP server, the telemetry timestamps may seen off (before...

> I'm not sure I'm following this sentence, could you elaborate a bit more on the "do this automatically or not" part? For example, hooking up to an error signal...

> I think this is true to some extent, if we're talking about javadocs then yeah I agree most people don't bother reading it, but there are some places, such...

another alternative just out of the oven https://android-developers.googleblog.com/2025/02/trustedtime-api-introducing-reliable-approach-to-time-keeping-for-apps.html?m=1

@LikeTheSalad I understand your points and I can relate, I had this discussion in the past, multiple times, and I was in favor of all opt-ins most of the time....

Btw it's possible to install dependencies automatically with gradle plugins. For example, people add the OTel Gradle plugin, if okhttp is on the classpath, you could install the otel-okthttp package,...

I think it's not needed for v1 since it is not a behavior or API surface breakage.