Archive symbols with release identity
Keep Unity version, source revision, scripting backend, architecture, version code and artifact hash together with native symbols and applicable managed diagnostics.
The IL2CPP documentation explains native/AOT output and diagnostic considerations. The Android crash guide provides the broader crash-investigation context.
Distinguish diagnostic layers
| Trace layer | Needed evidence |
|---|---|
| Java/Kotlin plugin | Relevant R8 mapping when obfuscated |
| Native engine/plugin | Matching native symbols and architecture |
| IL2CPP managed context | Supported engine/build diagnostic output |
| Game-specific state | Redacted reproduction and build context |
One mapping file cannot explain every layer in a mixed Unity/Android crash.
Verify symbols before an incident
Use a controlled internal test and confirm that your crash-reporting workflow resolves representative frames. Do not wait until a public release fails to discover that CI discarded the symbols.
Ensure the team can retrieve the correct archive without exposing it publicly.
Preserve the original report
Keep raw addresses, module names, build identifiers and thread information. Removing native frames because they look unreadable can destroy the evidence needed for symbolization.
Redact user content and credentials separately from technical identity data.
Diagnose after matching
Once symbols are confirmed, investigate the actual failing operation, ownership or plugin boundary. A plausible function name from mismatched symbols can lead the investigation in the wrong direction.
APKLint's Unity Analyzer can identify native package components and its crash tools can help interpret redacted traces. They cannot recover missing proprietary symbols or prove a native address mapping without the exact release artifacts. Make symbol retention a required release output, not an optional debugging convenience.
Sources and further reading
Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
