[FEATURE] No-op library variant for release builds

[musilto7]

Summary

Please provide a no-op variant of the library that can be used in release builds, similar to how Chucker, Pluto, and other debug libraries handle this.

Motivation

Currently to exclude DebugOverlay from release builds we have to use Gradle build variant conditionals:

dependencies {
    debugImplementation(libs.debugoverlay)
}

This approach has drawbacks — any code referencing DebugOverlay must also be wrapped in if (BuildConfig.DEBUG) checks or moved to debug-only source sets, adding boilerplate throughout the codebase.

A no-op variant would allow us to always reference DebugOverlay API without any conditionals, while ensuring zero overhead in release builds.

Proposed solution

Publish a separate no-op artifact, similar to Chucker's approach:

dependencies {
    debugImplementation("com.ms.square.debugoverlay:debugoverlay:x.x.x")
    releaseImplementation("com.ms.square.debugoverlay:debugoverlay-no-op:x.x.x")
}

The no-op variant would contain the same public API surface (DebugOverlay.configure {}, DebugOverlay.addBugReportContributor() etc.) but with empty implementations, so the app compiles and runs without any debug functionality in release.

Current behavior

There is no no-op variant. Developers must use debugImplementation and guard all usages with debug checks.

Expected behavior

A no-op artifact that can be used in release builds, keeping the codebase clean without any conditional debug checks.

Thank you!

[coderabbitai]

🔗 Related PRs

#90 - [refactor] remove the non-androidx startup installer [merged]
#119 - [feat] address a case where a debug overlay shows below dialogs [merged]
#159 - chore(sample): add releaseWithOverlay build type for sample app [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Manabu-GT]

Hi @musilto7 , thanks for the suggestion!

I'd lean toward not adding a no-op artifact for now, as maintaining a parallel no-op surface along with the main library increases my maintenance burden — every new public API, including those in extension modules, would require a matching stub.

The pattern I'd recommend instead is what the sample app does — put DebugOverlay setup in a build-variant source set so there are no if (BuildConfig.DEBUG) checks anywhere in src/main:
https://github.com/Manabu-GT/DebugOverlay-Android/blob/main/sample/src/debugOverlay/kotlin/com/ms/square/debugoverlay/sample/DebugOverlaySetup.kt

Combined with debugImplementation, the release build never sees the library at all — better than a no-op artifact (which would still ship all the public API surfaces, including model classes) at runtime.

Having said that, happy to reconsider if I get more requests like this from users of this library :)

Thanks!