mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 11:48:24 +00:00
Claude
6aebeeb3d9
Obfuscation is now on (Play requires it), so release stack traces arrive
renamed. This makes them readable again — for every channel, not just Play.
What a raw release trace looks like now, and what it really means:
at onh.B(r8-map-id-12c7109...:7)
-> androidx...TextFieldCharSequence.getText(TextFieldCharSequence.kt:58)
-> androidx...TextFieldState.getText(TextFieldState.kt:146)
-> ...home.ShortNotePostViewModel.onMessageChanged(ShortNotePostViewModel.kt:1727)
One frame retraces to three, because R8 inlined the other two. Retrace returns
more than the old un-obfuscated traces did, not less: it expands inlined frames
instead of collapsing them onto one misleading line.
- scripts/retrace.sh <mapping> [trace]: resolves the R8 version from the
mapping's own `compiler_version` header, fetches that exact r8.jar from
Google's Maven, caches it, and retraces. Accepts .txt, .txt.gz and .prt, and
reads the trace from stdin. Nothing to pin, so it survives AGP bumps.
- create-release.yml now publishes amethyst-{googleplay,fdroid}-mapping-
<tag>.txt.gz as GitHub Release assets (~29 MB each, from a ~500 MB mapping),
and fails the release if a mapping is missing. This is the gap that mattered:
AGP embeds the mapping in the .aab, so Play Console deobfuscates by itself
(verified: BUNDLE-METADATA/com.android.tools.build.obfuscation/proguard.map
is present in the built AAB) — but nothing carries it for the F-Droid,
Zapstore, Accrescent and GitHub-APK users, and CI's copy dies with the job.
A mapping cannot be regenerated after the fact.
- Dropped -renamesourcefileattribute. Not for the usual secrecy reason, which
does not apply to an MIT app: it is that R8 rewrites SourceFile to
`r8-map-id-<hash>` on its own once minifying, and the rule only overwrites
that marker with a constant. Built both ways to be sure — with the rule all
24,440 classes report the literal "SourceFile"; without it they report the
marker. The marker is the `pg_map_id` of the mapping that produced the build,
so a pasted trace names the exact file it needs and there is never any doubt
about which release a report came from.
Docs: RELEASE_OPS.md § 7 (per-channel workflow, how to pick the right mapping,
don't prune old mapping assets), BUILDING.md asset count 47 -> 49, and the
android-expert proguard reference.
Verified: retrace round-trips a synthetic trace against the real playRelease
mapping via .txt, .txt.gz and stdin; workflow YAML and both shell snippets
parse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DEoxktEZyTrAS33vVZBiwm