Uncovering Android Handler Crashes: Reproducing and Preventing PostDelayed Bugs

Background

The author, a test engineer from Tencent SNG, references a previous article about classic random crashes related to thread safety.

Problem Model

Several top‑ranked crashes occurred when users opened a page and immediately returned, causing a crash that was difficult to reproduce.

Developers responded with two typical answers:

Can the crash be reproduced? – "The scenario is known but cannot be reproduced."

There is a null pointer, so add a null‑check.

Inspecting the code revealed a common pattern involving handler.postDelayed. The crash flow was extracted and illustrated with screenshots.

The code posts an anonymous Runnable with a 500 ms delay.

Further investigation showed that the only place where mGLVideoView is set to null is in onDestroy().

Developers often clear references in onDestroy to avoid memory leaks, which matches the observed crash when the UI is opened and instantly closed.

Understanding Android's message mechanism is essential for diagnosing the issue.

Solution Approach

Post‑mortem fixes include adding null‑checks and referencing an article about handler.removeCallbacksAndMessages(null).

Benefits of using a non‑static anonymous inner class Runnable with remove include reduced memory leaks, elimination of null‑pointer crashes, and slight performance gains.

However, these are reactive. The article explores proactive techniques and a patented method for detecting similar problems.

1. After activity onDestroy , monitor handler.post

By hooking or using ActivityLifecycleCallbacks, one can monitor the relationship between the Activity’s onDestroy and the Handler’s post operations, enabling 100 % reproduction of the crash.

Investigation of the Activity source (Android 5.0) shows an internal mHandler used only by runOnUiThread, unrelated to the developer‑created Handler.

2. Controlling Message Timing

The article examines how messages are retrieved from the queue via next(), dispatched with dispatchMessage(), and how the msg.when timestamp determines insertion order.

It explains that sendMessageDelayed adds delayMillis to the system uptime, producing an absolute timestamp for msg.when. By modifying this timestamp (e.g., hooking sendMessageDelayed), one can extend the delay and reliably reproduce the crash.

Final Solution

The chosen approach lengthens the delayMillis for Runnables posted on the main thread, with threshold checks to avoid excessive delays that could cause UI jank.

Only delay Runnables after filtering based on the call stack.

Apply a threshold to prevent overly large delays that would affect UI responsiveness.

The implementation was integrated into the NewMonkey SDK, detecting four Android QQ crashes within one day.

The author acknowledges limited expertise and invites feedback.