Allowobfuscation Modifier

What the allowobfuscation modifier changes

The allowobfuscation modifier is a keep-rule option that preserves a class, method, or field in the compiled output while allowing its symbol names to be renamed or otherwise obscured. In practice, it separates API presence from API readability, which is useful when binary compatibility matters more than stable source-level names.

This distinction matters because shrinkers and obfuscators often make independent decisions about removal, renaming, and optimisation. Allowing obfuscation keeps the member available to runtime consumers while still reducing the clarity of the compiled symbols, so the rule can support compatibility without fully exposing implementation details.

How allowobfuscation works in code shrinking rules

Allowobfuscation is not a standalone protection mechanism. It is a modifier applied to a keep rule, so its effect depends on the surrounding rule syntax and the behaviour of the shrinker in use. The core idea is simple: retain the program element, but do not require its original name to remain intact.

That makes it different from a strict keep directive that preserves both existence and name. It is commonly used when reflection, generated code, or external integrations need the member to remain addressable by structure or signature, but human-readable symbol names are not contractually important.

Because the modifier permits renaming, it can still affect debugging, stack traces, documentation, and support workflows. The code remains reachable, but the names seen in bytecode, mappings, or runtime errors may no longer match the original source vocabulary.

When developers use allowobfuscation

Teams use allowobfuscation when an API must survive shrinking but does not need name stability. That is common in libraries, SDKs, and application modules that expose entry points to generated clients, serializers, annotations, or reflective frameworks.

It is also useful where preserving all names would unnecessarily weaken obfuscation. If an interface must remain present for compatibility, but the names themselves do not form part of the public contract, allowing obfuscation can reduce the amount of implementation detail that ships in the final artifact.

The trade-off is that the rule demands careful contract thinking. If downstream code depends on exact class or member names rather than on a broader structural contract, obfuscation can break those consumers even though the member still exists.

What this means for compatibility and reverse engineering

Allowobfuscation is best understood as a compatibility-preserving, name-hiding setting. It helps keep required entry points available while still making the compiled program harder to read and map back to source, which can reduce casual reverse engineering.

That benefit is limited, however, because symbol hiding does not eliminate exposure of the API surface itself. The presence of a class or method can still reveal design intent, and any runtime dependency on that member can still be discovered through inspection or failure analysis.

For that reason, the modifier should be treated as part of build-time hardening, not as a security boundary. It can support intellectual property protection and reduce accidental leakage of meaningful names, but it does not replace access control, authentication, or secure design.

Risk and Threat Considerations

Allowobfuscation can create a sharp distinction between what remains callable and what remains understandable. That is useful for shipping stable binaries, but it also means a preserved API may be easier to probe than to interpret, especially if other hardening controls are weak or the build exposes mappings, debug metadata, or reflective entry points.

Failure mechanism: An attacker or unauthorized integrator can still enumerate preserved classes and methods, then use runtime behaviour, metadata, or exception traces to infer how the code is structured even when names have been obfuscated.

Impact: The result is increased reverse-engineering exposure, more fragile consumer integrations, and a greater chance that internal implementation details or intended extension points are discovered despite the obfuscation step.

Practitioner Guidance

Why practitioners should care: Use allowobfuscation only where the contract depends on presence, not on readable names. If downstream consumers rely on exact names, the rule can introduce hard-to-diagnose breakage that only appears after shrinking and obfuscation are combined.

What to watch for: Review any preserved public API, reflection-heavy code, or generated integration points before applying the modifier. The safest pattern is to confirm which members must remain discoverable by structure, and which ones must remain stable by name, before you relax the keep rule.

Related resources from NHI Mgmt Group

• What is the difference between a transaction modifier and the underlying Mastercard reason code?
• Transaction Modifier