Reading logcat to diagnose faults after a flash

A device that does not boot gives you very little to work with. A device that boots with something broken gives you a great deal — if you know where to look.

Logcat is Android’s running commentary on itself. When the mic records silence, the camera fails to open, or Wi-Fi never comes up after a flash, the reason is usually stated plainly in there. Most people never read it, and instead reflash and hope.

Getting a log at all

You need USB debugging enabled and adb on your PC. Then:

• adb logcat — live output, scrolling continuously
• adb logcat -d > log.txt — dump the current buffer to a file and exit
• adb logcat -c — clear the buffer, so you can reproduce the fault against a clean log
• adb logcat -b all — include the radio, events and system buffers, not just the default

The single most useful habit: clear, reproduce, dump. Clear the buffer, trigger the fault, then dump. A log that contains only the thing you were testing is far easier to read than an hour of accumulated noise.

Filtering for the thing you care about

Raw logcat is overwhelming. Filtering makes it usable:

• adb logcat *:E — errors and above only. Start here.
• adb logcat | grep -i audio — anything mentioning audio. Swap in camera, wifi, sensor as needed.
• adb logcat -s AudioPolicyManager — one specific tag, when you already know the component

For post-flash faults, the component name is usually your filter. A mic problem lives in the audio HAL and policy manager tags, which is exactly how the mic fault on my tablet was traced to its configuration rather than the ROM as a whole.

What is actually a problem

This is where people go wrong. A healthy Android device produces a constant stream of warnings and errors that mean nothing. Red text is not evidence of anything on its own.

A working method

1. adb logcat -c to clear
2. Reproduce the fault — open the recorder, start the camera, toggle Wi-Fi
3. adb logcat -d > log.txt
4. Open the file and read the end first — that is where the fault you just triggered lives
5. Search for the component name, then for error, fail, denied
6. Search the exact message text. Specific messages often lead straight to the cause.

That last step matters more than it sounds. A precise error string from a HAL is a much better search than a description of the symptom, because it appears in the source of whatever produced it.

Frequently asked questions

Do I need root for logcat?

No. USB debugging is enough for the standard buffers, though root gives access to more.

Can I read logs from a device that will not boot?

Only if it reaches the stage where adb starts, which usually means the boot animation. Earlier than that, no.

The log is enormous. Where do I start?

The end. Clear the buffer first so the end is the fault you just reproduced.

Are SELinux denials the reason my feature is broken?

Sometimes, particularly after copying files in manually with the wrong context. Often they are routine. Check what was being accessed before assuming.

Is there a way to log a boot from the very start?

Not through logcat, which starts when Android does. For earlier stages you are looking at kernel logs or serial output, which most consumer devices do not expose.