Systematic Debugging and Root Cause Analysis Questions

Given process sometimes returns null, the debugger session should target both places that can produce that outcome: the explicit return null; branch, and the return finalize(intermediate); branch, since finalize returning null on some input would also make process return null without ever reaching the explicit return null; line.

public String process(Request r) {
    String intermediate = transform(r.getPayload());
    if (intermediate.length() > 0) {
        return finalize(intermediate);
    }
    return null;
}

Breakpoints and checks

1. Set a breakpoint at the start of process, and a conditional breakpoint at the if (or just after transform returns) so it only stops on calls where the eventual return value is null, not every call.
2. Inspect r.getPayload() at the top: is the raw payload itself empty or unexpected?
3. Step into transform and inspect its return value directly: is intermediate genuinely empty, or is transform throwing/silently returning empty on some input path? Also check whether transform can return null: if it ever does, intermediate.length() would throw a NullPointerException rather than return null from process, which is a different symptom worth distinguishing from a plain empty-string result.
4. Watch intermediate.length(): confirm whether the branch is taking the return null path because the input was legitimately empty, or because transform has a bug that produces an empty result for input that should not be empty.
5. Set a second breakpoint at the return finalize(intermediate); line and step into finalize, inspecting its return value before it propagates back. This path is easy to overlook because it isn't the visually obvious return null; line, but finalize returning null for some non-empty intermediate reproduces the exact same symptom from the outside.

Runtime conditions to inspect

There are three live hypotheses, not two: "upstream input was actually empty" (correct-by-design null, via the explicit branch), "transform mishandled a non-empty input and produced an empty result" (a bug in transform, via the explicit branch), and "finalize itself returned null for a non-empty intermediate" (a bug in finalize, via the other branch entirely). The debugger session's job is to look at r.getPayload(), intermediate, and finalize's return value side by side on a failing call to tell which of the three is true, rather than assuming the explicit return null; line is the only source.

Trade-offs and pitfalls

A conditional breakpoint that only triggers on a null-producing call avoids stepping through hundreds of successful calls to find the rare failing one; without it, this kind of intermittent-looking bug becomes tedious to debug interactively. Fixating only on the explicit return null; statement because it's the one line that literally says "null" is the trap here: it's easy to miss that finalize's return value flows straight back out unchecked.

Direct answer

First hypothesis: full-resolution bitmaps are decoded and held for every list item instead of downsampled to display size, and/or not recycled as the user scrolls. Verify with the Memory Profiler: watch the heap while scrolling and confirm it grows roughly per image scrolled, rather than plateauing.

Structured elaboration

• Take a heap dump during memory pressure and filter by android.graphics.Bitmap; instances far bigger than their ImageView confirm the hypothesis.
• Check with LeakCanary whether bitmaps are retained after their ViewHolder is recycled for a different item.
• Reproduce by scrolling a fixed number of images and watching for monotonic growth instead of stabilizing.

Worked example

A 4000x3000 ARGB_8888 (Android's default bitmap format, 4 bytes per pixel: one byte each for alpha, red, green, and blue) photo uses:

$4000 \times 3000 \times 4 = 48{,}000{,}000 \text{ bytes} \approx 45.78 \text{ MiB}$

Holding 20 at once is $20 \times 45.78 \approx 915.5$ MiB, well past a typical 192-512 MiB per-app heap. A 200x150 thumbnail instead uses $200 \times 150 \times 4 = 120{,}000$ bytes (~117 KiB), about 400 times smaller.

Trade-offs and pitfalls

Size inSampleSize (a decoder option that tells Android to shrink the image while decoding, e.g. inSampleSize=4 decodes at 1/4 the width and height, instead of decoding at full resolution and downscaling afterward) from the actual ImageView dimensions, not a fixed guess. A bitmap cache needs bounded LRU eviction; an unbounded one just delays the same OOM.

What the interviewer probes next

How you'd size an LRU cache relative to ActivityManager.getMemoryClass(), and why a library like Glide is usually preferable to hand-rolling this.

Direct answer

The timing is the tell: a freeze starting exactly at the tap and lasting about as long as a network round-trip means something async is actually blocking the main thread, even without Android's explicit main-thread-network exception. Confirm by aligning a system trace's frame gap against the network call's logged timestamps.

Structured elaboration

• Older Android throws NetworkOnMainThreadException for direct blocking calls, but calling .get()/Tasks.await() on an otherwise-async API blocks silently instead.
• Capture Perfetto/systrace during the tap; look for a gap in Choreographer#doFrame (the callback Android's rendering system fires once per rendered frame; a gap here means no frame was drawn during that stretch, i.e. the UI visibly froze) starting at the tap.
• Cross-reference that gap's timestamps against the network call's sent and received timestamps; near-exact alignment confirms the network call as the blocker.
• Add a StrictMode network-detection policy in debug builds to catch a reintroduction.

Worked example

A 2.3-second main-thread gap starting at onClick, matching a request sent at that instant with a response 2.3 seconds later, is checkable evidence the network call itself is blocking.

Trade-offs and pitfalls

Moving the call off-thread fixes the freeze, but the UI update after the response still needs to happen back on the main thread.

What the interviewer probes next

Why NetworkOnMainThreadException doesn't catch every case, and how you'd structure the code to make this hard to reintroduce.

Direct answer

Without the hardware, use the crash tool's device and OS breakdown to find what affected models share, and check whether the crashing path touches anything vendor-specific. Then rent the exact configuration through a device farm for a real repro.

Structured elaboration

• Segment by model, OS version, and manufacturer; concentration on a few models points at an OEM/chipset quirk, an even spread points at a genuine OS-version bug.
• Check for OEM-specific behavior: camera HAL variants (HAL, Hardware Abstraction Layer: the vendor's own driver code sitting between the OS and the camera hardware, exactly where OEM-specific bugs tend to hide), stricter background throttling, manufacturer UI overlays intercepting touch.
• Pull session breadcrumbs from the crash tool to reconstruct the exact action sequence, then reproduce it on a rented device via Firebase Test Lab or AWS Device Farm.
• If still stuck, ship targeted logging behind a flag to a small slice of the affected population for the next release.

Worked example

If 40% of all crashes are one exception, and 90% of those concentrate on 3 models on the same OS build, that's a strong signal to check for OEM-gated code, since a true device-agnostic bug would spread proportionally across the whole install base instead.

Trade-offs and pitfalls

Device farm sessions cost time; reserve them for concentrated, high-impact crashes. Flag-gated logging is safer than a blanket rollout but delays root-causing by a release cycle, usually worth it at 40% share.

What the interviewer probes next

When a crash is worth a device farm session versus accepted as an OEM-side limitation.

Direct answer

Android flags an ANR when the main thread ignores input for about 5 seconds. Capture a Perfetto/systrace around the freeze and look for one long block on the main thread track, or pull the stack Play Console or Crashlytics already captured for users you can't reproduce on.

Structured elaboration

• Reproduce under Android Studio's Profiler if possible, or pull the ANR trace from Play Console's Android vitals for wild reports.
• Look for a synchronous disk write (SharedPreferences.commit()), a synchronous network call, or a slow onDraw occupying the main thread for the full gap.
• Cross-reference affected devices/OS versions; concentration on low-end hardware suggests CPU-bound work that's just too slow there.
• Add StrictMode disk and network detectors in debug builds to catch this before it ships.

Worked example

The ANR threshold is 5,000 ms:

$6{,}200 \text{ ms (blocked)} > 5{,}000 \text{ ms (threshold)}$

A single commit() blocking 6,200 ms is sufficient on its own to trigger the ANR.

Trade-offs and pitfalls

Swapping to apply() fixes the freeze but slightly weakens the durability guarantee, a queued write instead of a confirmed one, usually the right trade for responsiveness.

What the interviewer probes next

How StrictMode would have caught this, and how you'd choose between apply(), a coroutine, or WorkManager.