NDK Crash Handling the what, the where, and the how
summary
Native NDK crash handling claims that you must capture a fault in an async‑safe signal handler, unwind the stack yourself, and symbolicate addresses with ELF/DWARF; the team prototypes using libcorkscrew and libbacktrace via a DLopen “envelope”, finds repeated crashes (10 launches → 0–1 reports) and allocator/unwinder races, experiments with an allocator rewrite and fork+ptrace (marginal gains), then moves to Breakpad to write a mini dump and do backend unwinding, which improves reliability substantially and is integrated into the Gradle symbol upload.
AI-written summary · about
chapters (12)
- 0:00Introduction to NDK Crashes
- 1:30Java Exception Handling
- 4:20Native World Crash Signals
- 8:08Signal Handler Constraints
- 12:08Violating Constraints Safely
- 13:21Stack Unwinding Challenges
- 16:58Dynamic Linking and Loading
- 20:13Improving Reliability
- 22:53Using Mini Dumps
- 24:00ELF and Symbolication
- 25:30DWARF Debug Information
- 29:02Automation and Conclusion
related talks
43mAndroid NDK Crash Reports
36mWe gave a Mouse an NDK: Non Android Developers' Experience with NDK
22mEverything you ever wanted to know about error handling in Android
31mWhat's new in Android C++ development
32mGetting Started with the Android NDK
48mThe Android NDK and its new support in Android Studio/gradle-experimental plugin (en)
06mAndroid GDS NDK/C++
05mBest practices using JNI