Direct answer
Native crash triage needs two separate assets: the crash evidence from the affected process and the matching unstripped symbols for the exact native build. Android’s NDK documentation describes using ndk-stack to symbolize native traces and explains that Gradle builds produce unstripped libraries in build intermediates for the relevant build type and ABI. A library with the same filename or version label is not enough; mismatched symbols can produce misleading function names or source locations. Preserve build identity—app version, commit or source revision, ABI, native library identifiers, and build variant—beside the symbol archive, and retrieve symbols only for the crash that matches those identities. For an on-device AI app, a native stack should help locate a runtime or bridge stage, not become a reason to collect user content. The repository privacy fact says local inference removes the need to transmit prompts to a remote inference server, but it does not prove that an app makes no other network requests. More importantly for this page, diagnostic logs should not contain prompts, transcripts, images, generated output, authentication values, or absolute paths that reveal personal names. Keep crash reporting and any transfer of diagnostic bundles behind a deliberate product policy and user-visible disclosure. Local inference does not imply that telemetry is automatically safe or nonexistent. Classify the failure before changing model files or promising a fix. Distinguish Java/Kotlin exceptions around a native call, a process crash with a tombstone, an application-not-responding event, a runtime load error, and a task-level failure. Preserve the original unprocessed crash artifact under controlled access; create a redacted working copy for analysis. Match the ABI and build IDs first, symbolize with the corresponding unstripped libraries, then map frames to the stage recorded by the app: initialization, input conversion, inference, stream callback, cancellation, or close. Avoid publishing raw dumps; even stacks can expose file paths, user IDs, or build infrastructure details. Testing should verify the evidence pipeline without fabricating a real model failure. Use a controlled native test fixture or an approved crash reproduction, confirm that the correct symbols resolve expected test frames, and verify that a mismatched archive is rejected by identity checks. Exercise release packaging and symbol upload/retention as a separate operational test. For actual model failures, attach artifact/runtime identity and a privacy-safe stage code, not prompt text. A symbolized stack narrows where execution stopped; it does not alone establish root cause, device incompatibility, or a performance result. Retain only what the team needs to investigate a defined period and access group. Document who can retrieve unstripped symbols and tombstones, how symbol artifacts map to releases, how long raw dumps remain, and how redacted findings are shared. The article offers a debugging workflow, not a claim that Cove currently publishes or collects any particular crash telemetry.
A release build exits during native model initialization
Support receives a crash report from one tested installation. The report identifies an app build and device ABI, but the available stack is unsymbolized. A nearby symbols archive exists, though its build identity has not yet been verified.
Decision
Match crash and symbols by exact native build identity before symbolization, keep raw files access-controlled, and create a redacted analysis artifact that excludes user content.
Expected outcome
The team can locate the failing runtime stage without claiming a root cause from a mismatched stack or exposing private prompts in ordinary support channels.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- App and native build IDs
- Symbol file retention
- Redacted crash fixture
A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.
Implementation workflow
Record and compare the three evidence pieces together: the app and native build identifiers, the retained symbol files, and the redacted crash fixture. Maintaining all of them in a linked form allows the recorded context to be re-examined against later entries and supports consistent symbolication.
- Capture a minimal, classified failure record. Record app build, OS version, ABI, native library/build identifiers, crash class, and the application stage. Preserve the original tombstone or approved trace securely; do not add raw prompt, transcript, media, credential, or personal path fields.
- Match the symbol archive exactly. Resolve the build variant and ABI, then compare native build IDs or other authoritative artifact identities with the unstripped libraries. Reject same-name archives whose identity does not match. Keep symbol artifacts indexed by release rather than by a mutable “latest” folder.
- Symbolize in a controlled environment. Use the official NDK symbolization workflow with the matching unstripped libraries. Confirm known test frames resolve as expected, preserve the original trace, and annotate which frames are runtime, app bridge, or system code without guessing from a single top frame.
- Redact before sharing findings. Remove or mask absolute paths, usernames, account values, local document names, and unrelated process data. Share only the frames, stage, build identity, and reproduction details needed for the investigation; restrict access to raw dumps and symbols.
- Test retention and mismatch handling. Run a controlled fixture to prove correct symbols resolve and wrong-build symbols are refused or visibly flagged. Verify release packaging retains the needed symbols under policy, document retention ownership, and re-test after native dependency or ABI changes.
Acceptance criteria
- Every symbolization action checks ABI and exact native build identity before using an archive.
- Raw crash files and unstripped symbols have a documented access and retention boundary; shared findings are redacted.
- The report separates crash class and execution stage from a proven root cause, compatibility conclusion, or performance claim.
- The diagnostic schema excludes prompts, transcripts, images, generated output, credentials, and unnecessary private paths.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Unsymbolized tombstone | Raw crash evidence with addresses and metadata | Preserve as source evidence; often insufficient for a maintainable call-site diagnosis. |
| Matched symbolized trace | Tombstone plus exact unstripped build/ABI symbols | Maps addresses to functions and possibly source locations; still requires contextual triage. |
| User-content logs attached | Avoid as a default support bundle | May add privacy risk without improving native address symbolization; prefer stage codes and redacted reproduction. |
Failure patterns to prevent
- Logging prompts with native stacks
- Losing symbols for release builds
Avoid two specific pitfalls: writing logs that capture native stacks together with prompts, and allowing release builds to lose their symbols. Limit any release-facing wording strictly to what the recorded evidence supports and do not add claims, hints, or details not covered by the preserved material.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Can I symbolize a crash with any library that has the same name?
No. Symbol addresses belong to a particular binary build and ABI. Use matching unstripped symbols and verify build identity; a nearby version can generate plausible but incorrect locations.
Does a symbolized stack prove the model is incompatible with the device?
No. It provides execution-location evidence for one crash. Root cause needs reproduction and stage-specific analysis; device support claims require separate evidence for the exact artifact, runtime, OS, and hardware.
Should a crash bundle include the prompt that triggered inference?
Not by default. Use synthetic reproduction fixtures where possible and retain redacted stage metadata. Prompts, transcripts, images, and generated output may be private and are not needed to map native addresses to symbols.