Create a durable build identity
Record application ID, version code, variant, source revision and relevant toolchain versions. A marketing version such as 2.1 can cover multiple internal builds or architectures. Your symbol store must resolve the mapping for the exact artifact that generated the report, including hotfix rebuilds.
Choose a private retention location independent of the temporary CI runner. Keep the mapping close to the release metadata while separating it from public app downloads. Assign an owner to retention policy: automated cleanup should not erase the ability to diagnose an application version you still support.
Pair mapping upload with release evidence
Capture the mapping from the actual optimization job, not from a developer rebuild performed later. Even the same source can produce a different output when build inputs change. Store a digest and release association so accidental replacement is visible.
If you use a crash service, upload through its supported workflow and verify the build association. A successful HTTP response confirms receipt, but may not establish that the correct application and version were selected. Keep enough local evidence to repeat diagnosis without relying on an ambiguous dashboard label.
Run a known retrace exercise
Use a stack trace from a controlled owned fixture, or another authorized report whose expected frames are known. Apply the exact mapping and inspect application frames for useful names and locations. Compare against an intentionally wrong mapping so your validation can detect a misleading partial result.
The basic command below uses Android command-line retrace. Resolve the tool from the SDK installation used by your workflow and check its help for available options. Save a sanitized example of the successful diagnostic result with the release checklist.
retrace /private/build-42/mapping.txt /private/build-42/stacktrace.txtAudit the public artifact separately
Check the downloadable package, adjacent storage objects and support bundles for accidental mapping publication. Hiding a file link in a release page does not make an object private. Confirm the storage access policy and keep diagnostics out of unrestricted CI artifact links.
CloneGuard can flag known debug companions in supported release screening, but file-name pattern checks cannot establish every diagnostic service permission. Combine the local result with a storage review and your retrace exercise. Native crash symbols may require an additional workflow separate from Java or Kotlin mappings.
If the correct mapping is missing, record that diagnostic gap honestly. Do not use an unrelated mapping to produce attractive function names in a report. A smaller optimized release is not an operational improvement if maintainers cannot investigate its failures.
Practical checklist
- Index mapping files by exact build identity.
- Store them before CI cleanup.
- Retrace an authorized known report.
- Review public bucket and artifact permissions.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.