Problem Statement
sentry-cli v3.3.5 deprecated the --uuid flag on proguard upload (#3176).
The fundamental problem: without --uuid, the UUID must be derived from the mapping file content. But in post-build obfuscation workflows, the mapping file doesn't exist at the time the UUID needs to be embedded in the app. This is a chicken-and-egg problem with no current solution.
Our project is a React Native app (@sentry/react-native 7.7.0, sentry-android-gradle-plugin 6.3.0) that uses GuardSquare's guided workflow (com.guardsquare.plugin). This is their recommended integration for hybrid apps — a guardsquareProtect*Bundle Gradle task processes the AAB after the standard Android build, producing the mapping file only after protection completes.
Today we rely on --uuid to bridge this gap:
# 1. Generate UUID before build
uuid=$(openssl rand -hex 16)
# 2. Embed in AndroidManifest.xml via Gradle property, then run protection
./gradlew guardsquareProtect*Bundle -PsentryUuid="$uuid"
# 3. Upload mapping with same UUID after protection produces it
sentry-cli proguard upload --uuid "$uuid" mapping.txt
We tried dexguardEnabled = true in the Gradle plugin as the only automated alternative for DexGuard users, but it was designed for integrated DexGuard builds (where DexGuard replaces R8 during the standard build). The guided workflow's extension name (guardsquare vs dexguard), task names, and mapping output paths differ from what the plugin expects, so it doesn't detect or wire to the protection step.
Solution Brainstorm
A) Post-build CLI command — e.g. sentry-cli proguard inject-uuid <mapping.txt> <aab> that computes a deterministic UUID from the mapping file and patches sentry-debug-meta.properties inside an already-built artifact. This would solve the chicken-and-egg problem for any post-build obfuscation workflow, not just GuardSquare.
B) Extend dexguardEnabled in the Gradle plugin (getsentry/sentry-android-gradle-plugin) to support com.guardsquare.plugin — detect the guardsquare extension, wire UUID generation after guardsquareProtect* tasks, and search GuardSquare's actual output paths.
C) Keep --uuid as a stable flag — if A and B are out of scope, un-deprecating --uuid would give post-build workflows a supported path.
Problem Statement
sentry-cliv3.3.5 deprecated the--uuidflag onproguard upload(#3176).The fundamental problem: without
--uuid, the UUID must be derived from the mapping file content. But in post-build obfuscation workflows, the mapping file doesn't exist at the time the UUID needs to be embedded in the app. This is a chicken-and-egg problem with no current solution.Our project is a React Native app (
@sentry/react-native7.7.0,sentry-android-gradle-plugin6.3.0) that uses GuardSquare's guided workflow (com.guardsquare.plugin). This is their recommended integration for hybrid apps — aguardsquareProtect*BundleGradle task processes the AAB after the standard Android build, producing the mapping file only after protection completes.Today we rely on
--uuidto bridge this gap:We tried
dexguardEnabled = truein the Gradle plugin as the only automated alternative for DexGuard users, but it was designed for integrated DexGuard builds (where DexGuard replaces R8 during the standard build). The guided workflow's extension name (guardsquarevsdexguard), task names, and mapping output paths differ from what the plugin expects, so it doesn't detect or wire to the protection step.Solution Brainstorm
A) Post-build CLI command — e.g.
sentry-cli proguard inject-uuid <mapping.txt> <aab>that computes a deterministic UUID from the mapping file and patchessentry-debug-meta.propertiesinside an already-built artifact. This would solve the chicken-and-egg problem for any post-build obfuscation workflow, not just GuardSquare.B) Extend
dexguardEnabledin the Gradle plugin (getsentry/sentry-android-gradle-plugin) to supportcom.guardsquare.plugin— detect theguardsquareextension, wire UUID generation afterguardsquareProtect*tasks, and search GuardSquare's actual output paths.C) Keep
--uuidas a stable flag — if A and B are out of scope, un-deprecating--uuidwould give post-build workflows a supported path.