Hey there! I’ve dealt with exactly this tricky scenario in Android development before—you set up a custom UncaughtExceptionHandler thinking it’ll catch every crash, but then there’s that edge case where the app restarts, Application.onCreate runs again, and your handler never logs anything. Let’s break down the crash types that slip through the cracks, and why your code isn’t catching them:

1. Native层（C/C++）崩溃 #

Java’s UncaughtExceptionHandler only handles exceptions thrown in the Java/Kotlin runtime. If your app uses native code (like third-party SDKs with JNI bindings, or your own C/C++ logic) that crashes, the system will terminate the process immediately—your Java-level handler won’t get any chance to run. When the system restarts your app (depending on device settings), you’ll see Application.onCreate re-execute, but there’s no Java exception to catch here.

2. ANR导致的进程终止/restart #

When your app hits an ANR (Application Not Responding) because the main thread is blocked for too long, the system may either show an ANR dialog or directly kill the process. If the process is killed before your UncaughtExceptionHandler can finish executing (or if the ANR isn’t triggered via a Java exception), your handler won’t log the issue. After the process restarts, it’ll look like a crash, but there’s no uncaught Java exception to handle.

3. System-initiated process restart (not a crash) #

Sometimes what feels like a crash is actually the system restarting your process for non-exception reasons:

• Low memory: The system kills background apps to free up RAM, then restarts them when the user returns.
• Permission changes: Modifying certain high-risk permissions (like storage or location) can trigger a mandatory process restart.
• Configuration change failures: In rare cases, misconfigured activity handling during configuration changes might lead to a process restart instead of regular recreation.

In these cases, there’s no uncaught exception at all—so your UncaughtExceptionHandler has nothing to catch. The app just restarts, making it seem like a crash without logs.

4. Main thread termination before your handler runs #

If the exception is severe enough that the main thread is terminated immediately after throwing the exception (before your handler’s code can execute), your log statements and exception handling won’t run. For example, if the exception corrupts the app’s core state, the system might kill the process faster than your handler can write logs or send reports.

Looking at your code #

Your handler logic looks correct on paper, but if any of the above scenarios happen:

• The LogUtil.e call might never execute because the process is killed before the log is written.
• If the crash is native or system-initiated, handleException(ex) will never even be called—since there’s no Java Throwable to pass in.

Fixes & Workarounds #

• Catch native crashes: Use tools like Google Breakpad, or Firebase Crashlytics (which supports native crash reporting out of the box) to capture native-level crashes.
• Monitor ANRs: Set up a file observer to watch the /data/anr/traces.txt file, or use libraries like ANR-WatchDog to detect ANRs in your app and log them before the system kills the process.
• Detect process restarts: Add logic in Application.onCreate to check if this is a fresh start or a restart after a process kill. For example, store a timestamp in SharedPreferences on app start—if the current time is significantly later than the stored timestamp, it’s likely a restart after a crash/kill.
• Initialize your handler early: Make sure you set your custom UncaughtExceptionHandler as the first thing in Application.onCreate, before any other initialization code runs. This avoids cases where an exception is thrown before your handler is set up.

内容的提问来源于stack exchange，提问作者leon chen