What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A clean JavaScript console does not rule out a crash: Android can terminate a React Native app because of a native fault that JavaScript never receives as an exception. To find the cause, capture Android’s crash evidence, inspect the signal and failing thread, then symbolicate the native stack using unstripped libraries from the exact build. The title alone cannot identify the cause; it could be app code, a native module, the runtime, or another native library.
Why did my React Native app crash when JavaScript showed no error?
JavaScript exceptions and native process crashes happen at different layers. React Native DevTools can help investigate React app concerns, but the React Native documentation says it is “designed for debugging React app concerns, and not to replace native tools.” For underlying platform layers, including native modules, it points developers to Android Studio and Xcode debugging tools. On Android, use Android’s logs and native crash data to establish what happened rather than assuming every missing JavaScript stack trace means a native crash.
As an Amazon Associate I earn from qualifying purchases.
A native crash may come from your own C or C++ code, a React Native module, the runtime, or another native library. You need the actual trace and matching build information to narrow it down.
How do I capture an Android native crash?
Reproduce the exit or freeze while collecting Android logs, and preserve the exact app build and its native libraries. The log context around a failure can be as useful as the crash trace itself, particularly when code logged an error immediately before aborting.
#1 Best Overall
- Reproduce the problem on the affected Android version and device or emulator. If it appears device-specific, try a physical Android device as well; a particular phone is not a requirement for this workflow.
- Collect Android crash output. Use
adb logcator Android Studio’s Logcat while reproducing the issue, and retain the crash output or tombstone that Android makes available. Include relevant lines preceding the crash, not only the final frame. - Record the build details. Keep the app version, build configuration, ABI (such as arm64-v8a), React Native version, Android version, and the unstripped native libraries produced for that build. These details help ensure the stack is interpreted against the correct binaries.
- On Android 12 (API 31) or later, consider programmatic collection. Android exposes an app’s native crash tombstone through
ApplicationExitInfo.getTraceInputStream(). This platform facility can support collection of crash traces from user devices; it does not remove the need to retain matching symbols.
Android’s NDK debugging documentation describes native crash and memory-debugging options, while the AOSP native crash guide explains crash output and tombstones.
What is a tombstone?
A tombstone is Android’s diagnostic record for a native crash. Depending on the crash and available data, it can include backtraces for all threads, register state, raw stack and memory dumps, and a memory map. That makes it more informative than a single top-frame message: another thread, a mapped library, or the register state may help explain the failure.
Read the tombstone alongside nearby logcat output. A signal describes the way the process failed, but it does not, by itself, prove which dependency or source line caused it.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →How do I read an Android native crash log?
Start with the signal, the faulting thread, and the frames nearest the failure. Treat these as clues that guide the next investigation, not as a diagnosis by themselves.
- SIGABRT with an
abortframe inlibc.so: AOSP identifies this as an abort pattern. Look immediately before it in logcat for an assertion, fatal message, or other context logged before the process called abort. - A memory-fault signal or a faulting address: Inspect the faulting thread and nearby frames, then consider whether the trace points into app code or a particular native library. A memory fault alone does not establish the underlying bug.
- Frames in a runtime or module: Note the library names and call sequence, but do not conclude that the first named library is necessarily at fault. It may be where a problem surfaced rather than where it originated.
When the trace is incomplete or addresses are not mapped to source lines, collect the full tombstone and logs again if possible, then check whether you have matching symbols before drawing conclusions.
How do I symbolicate a native Android stack trace?
Symbolication replaces native addresses with function names, source files, and line numbers when the corresponding debug symbols are available. Android’s ndk-stack documentation explains how to process a captured log or tombstone with the unstripped libraries that match the crashing build.
- Locate the unstripped libraries for the exact build. For Android Gradle Plugin builds, the NDK documentation identifies the intermediates/cxx build tree as a location to look. Preserve libraries for the relevant ABI and build configuration.
- Run
ndk-stackon the captured output. Point it at the log or tombstone and provide the directory containing the matching unstripped libraries. Follow the options documented for your installed NDK rather than substituting a path or library from a different build. - Compare the symbolicated frames with the original trace. Use the resulting function names and source locations to identify the code path, then investigate that code or the module that owns it.
A symbol file from another app version, ABI, or build configuration can produce misleading results or fail to resolve addresses. If symbolication yields no useful names, first verify that the libraries really correspond to the crashed binary.
See the official Android ndk-stack documentation for its supported usage and symbol matching requirements.
Best Value
What should I investigate after symbolication?
Use the symbolicated trace to move from a crash signature to a specific code path. Check the failing thread’s sequence of calls, the library containing the relevant frame, and any preceding log messages. Then reproduce with a focused change or debugging build so you can test a concrete hypothesis rather than changing unrelated JavaScript code.
If the trace suggests memory corruption, Android’s NDK debugging guidance also covers AddressSanitizer (ASan) and Hardware-assisted AddressSanitizer (HWASan) as memory-debugging options. Their suitability depends on the app, device, and build setup; they are tools for investigating a suspected memory problem, not proof that one exists.
Manual diagnosis or production crash reporting?
These routes complement one another. Manual Android tools are useful when you can reproduce a crash locally; crash reporting can help collect evidence from failures on users’ devices. Neither route makes native symbols or interpretation unnecessary.
| Approach | Best fit | Evidence and limitations |
|---|---|---|
Android logs and tombstones with ndk-stack |
Local reproduction and detailed investigation of a particular build | Android’s native crash workflow can expose thread and process context; useful symbolication requires the matching unstripped libraries. Programmatic tombstone access through ApplicationExitInfo is available on Android 12 (API 31) and later. |
| Crash-reporting SDK | Collecting crash evidence from production users when local reproduction is difficult | Coverage and captured native details depend on the vendor’s product, SDK version, configuration, and available symbols. It adds integration and maintenance work and does not replace examination of the native trace. |
Sentry’s product materials describe native stack traces and source maps for its React Native offering, and its materials describe tombstone capture through ApplicationExitInfo. These are vendor claims, not an independent comparison. Sentry’s dated materials give different minimum SDK versions for tombstone support, so there is no reliable threshold to state here; check its current Android SDK documentation before choosing a version.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
