Read and Use the ACR Summary Report

The aggregated crash report (ACR) summary organizes all crash debugging data into a single markdown file. The tool automatically generates the report at the end of every symbolication.

Prerequisites

1. A crash file (.acr) from your Vega app.
2. Vega Studio installed and configured.
3. Read the Debug App Crash Using Vega Studio to familiarize yourself with ACR files and their data.

How to use the summary report

Vega Studio automatically displays the summary report as a new tab once symbolication completes. The report opens in a file preview within Vega Studio.

Once you have the report open:

1. Review the Metadata section to understand the crash context (process, reason, language).
2. Examine the Symbolicated Stacktraces to identify the crash location.
3. Check the System Info to see memory usage and system state at the time of the crash.
4. Cross-reference with your source code to diagnose the issue.

Report structure

The following sections describe the components of the report and what information each contains.

File header

Contains the file path to the ACR file and the path to the related temporary workdir.

Metadata

This section contains relevant metadata from the ACR file:

• PROCESS - The process that crashed.

• CRASH_REASON - The reason for the crash.

• CRASH_LANG - The programming language of the crashed code. Possible values: Native, JavaScript, or unknown. The ACR file reports "Unknown" when the crashing thread ID matches JavaScript thread ID in an ANR case, indicating the crash could originate from native or JavaScript code.

• APP_VERSION - The app version that crashed.

• OS_BUILD_NUMBER - The OS build number from which the ACR file was generated.

• BUILD_VARIANT - The build type from which the ACR file was generated. Possible values: user, userdebug, or user-external.

OS release file

Contains the contents of /etc/os-release collected by the ACR file.

Symbolicated stacktraces

This section contains the decoded stack traces that show the exact location and sequence of function calls leading to the crash.

The crash language determines which stack traces appear in this section:

• JavaScript crashes: Only the JavaScript stack trace displays

• Native crashes: Only the native stack trace displays by default

To view all thread traces, use thread apply all bt in the GDB session.

System info

This section displays system information recorded in the ACR file at the time of the crash, including:

• Top 5 memory-consuming processes from the <meminfo> section

• Pressure info stats from the <pressure_info> section

Native stacktrace - all threads

This section displays the native stack trace for all threads. You can generate this trace by running thread apply all bt in the interactive GDB session.

Example

The example shows the structure of an unrendered summary report:

# Acr-report summary report

Path to ACR file: [/Users/fkvelasq/callie-test.acr](./crashfile)

Path to acr_workdir: /Users/fkvelasq/acr_workdir-c4bcb13c

## Metadata

PROCESS: /usr/bin/eventmgrd
CRASH_REASON: SIGABRT
CRASH_LANG: Native
APP_VERSION: N/A
OS_BUILD_NUMBER: 1001010003820
BUILD_VARIANT: user
PRODUCT_NAME: callie
BUILD_FINGERPRINT: 4.0.137942.0(3072cab629675a74)/38N:user/release-keys
OE_VERSION: 4.0.0

## OS release file

NAME="OS"
OE_VERSION="4.0.0"
OS_MAJOR_VERSION="1"
OS_MINOR_VERSION="1"
RELEASE_ID="10"
OS_VERSION="1.1"
BRANCH_CODE="TV Ship"
BUILD_DESC="OS 1.1 (TV Ship/38)"
BUILD_FINGERPRINT="4.0.137942.0(3072cab629675a74)/38N:user/release-keys"
BUILD_VARIANT="user"
BUILD_TAGS="release-keys"
BUILD_DATE="Fri Jul 25 01:48:20 UTC 2025"
BUILD_TIMESTAMP="1753408100"
VERSION_NUMBER="1001010003820"

## Symbolicated stacktraces

### Native stacktrace

<details open>
<summary> Expand to see native stacktrace </summary>
<pre>
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xb6877d98 in __GI___ioctl (fd=-4, request=3224396289) at ../sysdeps/unix/sysv/linux/ioctl.c:35
#2  0xb67544ba in binder_call_internal (runtime=0xf8a2c8, target=<optimized out>, code=<optimized out>, request=<optimized out>, response=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/binder.c:1057
#3  0xb6754548 in binder_call (runtime=<optimized out>, target=<optimized out>, code=<optimized out>, request=<optimized out>, response=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/binder.c:1082
#4  0xb6754d3c in ipcn_runtime_call (runtime=<optimized out>, remote_handle=<optimized out>, code=<optimized out>, request=<optimized out>, reply=reply@entry=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/ipcn_runtime_binder.c:235
#5  0xb67569a6 in ipcn_call (runtime=0xf8a2c8, target=<optimized out>, code=<optimized out>, request=<optimized out>, reply=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/core/ipcn_call.c:103
#6  0xb1be0418 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Related topics

• Debug App Crash Using Vega Studio
• Fix Crash Analysis Issues
• Measure Performance with Chrome DevTools
• Monitor Network Traffic with Charles Proxy

Last updated: Dec 22, 2025