Only perform thread checking in debug builds

[tobrun]

Closes #14287, possible solution alternatively the static lazy initialization can be replaced if we can ask users to provide their BuildConfig.DEBUG value through Mapbox.getInstance.

[LukasPaczos]

Another alternative would be generating the ThreadUtils class during build time (annotation processing step or something similar), depending on config - returning for release and crashing for debug. This would allow us to skip build type checks introduced here. Maybe a library like AutoService could be useful here. What do you think?

[tobrun]

I'm not sure that would work as our users library are always consuming the release binary. For them thread checking will always be disabled. What is proposed in this PR is to check against the debug/release state of the consuming app.

[LukasPaczos]

True, unless we ship a processor in a separate artifact that replaces the default (slow) implementation, and possibly unlocks other code generation features. Interested users could include that artifact in their build scripts. Or does that sound like overkill?

[tobrun]

We will be looking into #14293 (comment) as alternative approach to fixing this issue. Closing this PR for now.

[maxtracking]

Hi @tobrun,

Any idea of ETA for the alternative solution ?

Alex

[tobrun]

No concrete ETA but we are trying to pick this up for upcoming release aimed at end of the month. If we don't hit that, it will be included in the release of next month.

[LukasPaczos]

ship a processor in a separate artifact that replaces the default (slow) implementation

I've done my due research on the topic:

• We are unable to write into or replace a class file during the annotation processing step in a stable manner. There might be some ways of achieving the desired effect, but those are dependent on too many assumptions regarding the local build environment, which we don't want to do.
• There's a way of replacing a class file from the Gradle's perspective. It requires us to bypass the typical maven setup by excluding the aar, downloading the artifact on the side, unpacking the classes jar, replacing the class file and re-including that artifact in the build.

Both of the above sound like a hell to maintain.

The only realistic way of doing a completely clean build-type optimization, without any additional checks, would be not including ThreadUtils class in the Maps SDK's aar at all while simultaneously shipping an annotation processor (or a Gradle plugin) that does the code generation, and forcing end users to depend on it.

I don't think that offered features would benefit users enough to force that dependency now, but it's something we can revisit in the future.

In the meantime, I'm reopening this PR as a way to tackle the original issue.

[LukasPaczos]

🚢