Introduction
Developing custom Android Automotive OS (AAOS) launchers and system applications presents unique challenges, especially when tracking down elusive crashes. Unlike standard Android app development, custom AAOS components are deeply integrated with the system, often interact with low-level services, and run on specialized hardware. This expert guide dives into advanced debugging techniques to diagnose and resolve Java, native, and ANR (Application Not Responding) crashes, ensuring stability and performance for your in-vehicle infotainment systems.
Understanding Crash Types in Android Automotive
Crashes manifest in different forms, each requiring a specific diagnostic approach:
- Java Crashes: These are typically unhandled exceptions (e.g., NullPointerException, IllegalStateException) occurring within the Java/Kotlin code of your app or system service. They result in immediate termination of the affected process.
- Native Crashes (C/C++): These occur in native code libraries, often due to memory corruption (e.g., use-after-free, buffer overflow) or invalid memory access (segmentation fault). They generate a ‘tombstone’ file containing critical debugging information.
- Application Not Responding (ANR): An ANR occurs when an application’s UI thread is blocked for too long (typically 5 seconds for foreground activities, 10-20 seconds for broadcast receivers/services), leading to a frustrated user experience and system prompt to close the app.
Initial Debugging Steps: Logcat Mastery
Logcat is your first line of defense. A deep understanding of its capabilities is crucial for efficient debugging.
Basic Logcat Usage and Filtering
To start, connect your AAOS device via ADB:
adb devicesThen, stream logs:
adb logcatThis will show a continuous stream. To make it useful, filter aggressively:
- By process/package name: If your launcher is
com.example.automotive.launcher:
adb logcat | grep com.example.automotive.launcher- By PID (Process ID): Find the PID of your app using
adb shell ps -A | grep launcher. Then:
adb logcat --pid=<YOUR_LAUNCHER_PID>- By tag: If you consistently use a specific tag, e.g.,
MyLauncherDebug:
adb logcat -s MyLauncherDebug:*- Persistent Log Collection: For intermittent crashes, capture logs to a file:
adb logcat -v threadtime > crash_logs.txtAnalyze the logs leading up to the crash, looking for `FATAL EXCEPTION`, `CRASH`, `signal` messages, or repeating errors.
Diagnosing Java Crashes
When a Java crash occurs, Logcat will display a detailed stack trace. Your primary goal is to identify the method and line number within your codebase that caused the exception.
Analyzing the Stack Trace
Look for lines containing your package name. For instance, in a `NullPointerException`:
FATAL EXCEPTION: main
Process: com.example.automotive.launcher, PID: 12345
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.TextView.setText(java.lang.CharSequence)' on a null object reference
at com.example.automotive.launcher.MyActivity.updateUI(MyActivity.java:123)
at com.example.automotive.launcher.MyActivity.onCreate(MyActivity.java:78)This trace immediately points to `MyActivity.java` at line 123, within the `updateUI` method, indicating a `TextView` was null when `setText` was called.
Remote Debugging with Android Studio
For more interactive debugging, attach Android Studio’s debugger:
- Build and deploy your app in debug mode.
- In Android Studio, navigate to ‘Run’ > ‘Attach Debugger to Android Process’.
- Select your AAOS device and the process of your custom launcher.
- Set breakpoints in your code. When the crash occurs, the debugger should pause at the breakpoint, allowing you to inspect variable states and step through code.
Tackling Native Crashes (C/C++)
Native crashes are often trickier but leave critical evidence in ‘tombstone’ files.
Locating and Analyzing Tombstones
When a native process crashes, a tombstone file is created in `/data/tombstones/`. To retrieve it:
adb shell ls -l /data/tombstones/
adb pull /data/tombstones/tombstone_00A tombstone contains a wealth of information: crash type, registers, stack traces for all threads, and memory maps. The raw stack trace is usually addresses, not function names. To make sense of it, you need to symbolicate it.
Symbolication with `ndk-stack` or `addr2line`
You’ll need your unstripped native libraries (`.so` files) and the `ndk-stack` tool (part of the Android NDK).
# Assuming NDK is installed and on path
# Pull your unstripped .so files from your build output, e.g., project_root/app/build/intermediates/cmake/debug/obj/arm64-v8a/
# Navigate to the directory containing your unstripped .so files
# Then run ndk-stack, feeding it the tombstone content:
cat /path/to/tombstone_00 | ndk-stack -sym /path/to/your/unstripped/libs/This command will translate the hexadecimal addresses into human-readable function names, file names, and line numbers, pinpointing the exact location of the native crash.
Resolving Application Not Responding (ANRs)
ANRs indicate a severe UI blockage. Diagnosing them requires examining `traces.txt`.
Locating ANR Traces
When an ANR occurs, the system logs a trace to `/data/anr/traces.txt` (or a timestamped file like `traces_<PID>_<TIMESTAMP>.txt`).
adb shell ls -l /data/anr/
adb pull /data/anr/traces.txtAnalyzing `traces.txt`
The `traces.txt` file contains a snapshot of all threads in the crashing process at the moment of the ANR. Focus on the main thread (often labeled `main` or `ActivityThread`).
- Look for blocked methods: Identify methods that have been running for an unusually long time, especially those involving I/O, network requests, or complex computations.
- Identify deadlocks: If multiple threads are involved, look for threads waiting on each other for locks.
Example snippet from `traces.txt`:
Android Mobile Specs & Compare Directory
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
Compare Devices Specs →