I am flashing a modified version of AOSP and the device boot loops. The problem is that "logcat" on the phone never runs, meaning that the problem has occurred earlier.

So, is there a way that I can access any log files that have been generated since the devices had initiated boot? I just want to know the root of the error that I caused.

The modifications that I do are in the runtime in particular, and I am flashing to the device the following AOSP-generated images:

fastboot flash cache cache.img
fastboot flash system system.img
fastboot flash userdata userdata.img
fastboot flash boot boot.img

I am using a Nexus 6, on Android Marshmallow (most stock code from 6.0.1_r31..r33), and the boot image is permissive with verity disabled.

1 Answer 1


You can redirect kernel logs during boot time using a USB serial port.

Wikidot (archived) has an informative article on it

If the phone doesn't even boot up to a stable state where the ADB commands can be used, one might be interested in redirecting the kernel messages to some places where they can be seen. This is to leverage the "console=" command for the kernel.

For different devices, there may be different ports where the messages can be redirected to. If the serial port on the device is enabled, one can use use the serial port. On MSM chips, there is a UART port which may be used. For this, one can use "console=ttyMSM2,115200n8" and the availability of the port can be checked in "/dev" if one wants to use it.

Currently, there is a possibility to use the USB serial ports too. One may want to check if they work on the device. The USB serial port is a software serial port emulated through the USB interface. It often has the names "ttyUSB*" or "ttyHSUSB*". On Android devices, if one sees "ttyUSB*", those may be ports provided by the USB gadget drivers (/kernel/drivers/usb/gadget), which could be used as the console (add console=ttyUSB0,9600n8). If one sees "ttyHSUSB*", they may be a bit different. These may be provided by MSM platform USB drivers, and some might not support the "console" yet. For curious readers, in order to be used as a console, a device driver has to register itself as a console provider by calling register_console in kernel/printk.c, and it has to provide some callbacks for printk to write kernel messages. So the device driver developer would have to explicitly support this for the device driver to be used as a console.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .