How to avoid conflicts between LD's Timber logs and our own app's Timber logs?

[erawhctim]

Is your feature request related to a problem? Please describe. Our app uses Timber for logging, and have a custom Tree that sends exceptions from Timber.w() and Timber.e() calls into our error reporting system. Our team noticed some strange errors in our system and eventually realized that these were originating within the LD SDK (Here's one example, ultimately resulting from the Timber usage in LDConfig here).

How should we avoid the discrepancy between LD's own Timber logging Tree and our own?

Describe the solution you'd like There's a few different solutions that come to mind. I'm curious if you all have thoughts on any of them, or if anyone else has run into a similar issue?

• Preferably, LD would use its own logging abstraction and minimize its 3rd party dependencies (but Timber is useful so I see the benefit of using it). LD could also pull in the Timber class files themselves and include them in the SDK (but renamed) to avoid the conflict.
  • We could also do the example same thing on our side, which is equally reasonable.
• We could update our custom Timber Tree to try and ignore logs that originated from Trees that we don't own.

Describe alternatives you've considered Logging within our app via a completely different method (which we're not opposed to).

Additional context N/A

[louis-launchdarkly]

Hello @erawhctim, thank you for reaching out. We are looking into abstracting the logging layer and the task is on our backlog.

Filed Internally as 45759.

[erawhctim]

Great, thanks Louis! Do you have an ballpark estimate on when that work will start/finish/etc? Or is it too soon to know?

[louis-launchdarkly]

Right, it is too soon for us to have an estimate on timing, as this change looks pretty big.

[gwhelanLD]

Hi @erawhctim,

We've started on a logging interface for the SDK to allow configuration and alternative logging backends, but aren't able to give a timeline on completing that work at the moment. One detail that may be helpful for filtering the logs the SDK records with Timber currently is that all log statements are tagged "LaunchDarklySDK" (see here).

Thanks, @gwhelanLD

[erawhctim]

That's exactly what I was looking for - thank you @gwhelanLD!

[eli-darkly]

For anyone following this issue: there was a bug that was causing the SDK not to set a consistent "LaunchDarklySdk" tag, as our previous comment said it did. That's been fixed in version 3.1.7, so now the tag is always "LaunchDarklySdk".

However, we are also pretty close to releasing the new logging API that the previous comment mentioned; that's likely to be in a 3.2.0 release soon. This will allow logging to be 1. still sent to Timber, but with a different tag of your choosing, and/or with a level filter such as "only warnings and errors"; 2. sent directly to the Android logging API without involving Timber, also with a level filter; 3. sent to any other kind of destination you might want, such as an OutputStream that you provide or a full custom implementation of the logging interface; or 4. totally disabled.

[eli-darkly]

We've released version 3.2.0, which retains the current default Timber behavior but makes it possible to specify different behavior or disable logging. Please see this comment and the changelog.