Separate Module for debugging-related

[siavashabdoli]

What do we have now?

Many widely-used libraries in the Android/Kotlin ecosystem ship consumer ProGuard/R8 rules that preserve class-file attributes such as RuntimeVisibleAnnotations, InnerClasses, and EnclosingMethod. These rules tend to be applied transitively to all downstream modules.

Because kotlinx.coroutines contains debugging-related metadata (DebugMetadata) that depends on these attributes, the ecosystem-wide practice of keeping these attributes effectively causes coroutine debug metadata to remain visible in production builds—even for modules that do not need any debugging or reflection support.

This leads to sensitive structural information remaining in DEX output even after full obfuscation.

Concrete example after full obfuscation:

@hr.d(
    c = "com.example.security.AttestationDataProvider$getLastRequestSucceeded$$inlined$map$1$2",
    f = "AttestationDataProvider.kt",
    l = {219},
    m = "emit",
    v = 1
)

This exposes method names, file names, and coroutine structure despite obfuscation being applied.

What should be instead?

A mechanism to allow production builds to exclude coroutine debugging-related metadata without requiring developers to override consumer rules coming from unrelated libraries.

This could mean:

• clearer separation between runtime-required coroutine metadata and debugging-oriented metadata,
• providing a way to disable debug metadata entirely at build time,
• ensuring coroutine debug metadata does not depend on attributes commonly kept for unrelated reasons.

This is not a request to remove debugging capabilities—only to avoid exposing metadata in modules where it is never used.

Why?

• Reduces reverse-engineering surface in security-sensitive modules (e.g., attestation, fraud prevention, anti-tamper layers).
• Reduces unnecessary metadata in release builds.
• Avoids relying on new tooling (e.g., AGP 9 ignoreFrom) which many projects cannot adopt due to backward compatibility or CI constraints.
• Keeps debugging support available where explicitly opted into.

Who would benefit?

• Developers building hardened runtime modules.
• Applications that ship into adversarial environments.
• Teams that need different obfuscation policies across modules.
• Developers who do not have deep R8 experience and want secure defaults with less manual ProGuard work.
• Projects targeting older toolchains that cannot update to new AGP features.

Why not?

• Some projects rely on debugging metadata in production.
• Changing defaults may lead to missing metadata for reflection-based tooling if not applied carefully.
• Requires coordination to ensure debugging stays opt‑in rather than silently broken.