bootloader - Android debugging-Boot Loops: Is there any way to get a log of information without ADB? Can the emulator even help?

  • 9exceptionThrower9

    Possible Duplicate:
    Android boot-up messages for debugging?

    Related to this post I created: Does the Android emulator generate some sort of log file I can access if it crashes?

    I have been searching and trying to figure out if there is any way at all to get some kind of debugging information or any kind of kernel messages from an Android phone IF it gets stuck at a boot-loop state? That means the phone gets stuck at the "Google" splash-screen, then crashes, then goes to that, then crashes.

    I know the phone has several stages of bootloading, but for me to even figure out why my system image/modified kernel is making the phone crash, I need to at least know where the phone is crashing? Is there any kind of log the Android emulator maybe spits out that shows it going through the stages of booting: i.e. stage 1 bootloader, main stage bootloader, kernel being loaded, initialization process, Zygote, Zygote initializing Dalvic VM, execution of system server, then boot completed (when the ACTION_BOOT_COMPLETE flag/event is raised).

    I've tried modifying "init.rc" to echo commands to a boot log (but it didn't work, though I don't know if the phone makes it to that stage, all I have is a useless splashscreen), I've tried any of the ADB stuff but of course ADB doesn't work if the phone doesn't reach a stable state, the LINUX dmesg command only works to show that the phone plugged in via USB, and the Android developers have chosen not to at least explain to me that only they hold those kinds of developer tools. Can anyone give me some guidance of what I can do to debug the boot process? There has to be some kind of log you can access with the emulator at least.

    EDIT: In other words, how does anyone get any kind of log from their phone/emulator if gets stuck in a "boot-loop"?

    EDIT: Further information = my kernel version I believe I have downloaded for my phone build is Linux kernel release 3.x (stock kernel pulled from the tuna folder and using the "omap" project), for Android Galaxy Nexus (maguro), with the platform being IceCreamSandwich 4.0.3.

  • Answers
  • t0mm13b

    You will know if the kernel has hung, the led light stays on and not go further.

    As for your question, you need to be more clearer and specific as we do not know and since you posted a similar question before. You have not stated, what device is it, what android version is it, what kernel is it, all those are left out and thusly playing a guessing game here.

    • Is it the ramdisk not created correctly?
    • Is it the address used for booting incorrect?
    • Is the ROM built for VMSPLIT 3G and the kernel is built with VMSPLIT 2G or vice versa?
    • What chipset is it? ARMv7 kernel with ROM compiled for ARMv6...
    • Is the kernel actually booting? if yes, how do you know?

    Far too many things here to speculate.


    This bit is related to kernel level debugging.

    The only way you can know if the kernel is indeed booting in the first place is to use a USB to Serial TTY cable with JTAG pinouts on a small circuit board clipped/soldered to the back of the device in question, and having the serial driver compiled into the kernel and treating the console as a tty device, and reading from it via minicom or hyperterminal to see the boot up sequence.

    As for bootloops,

    The cause of boot-loops are down to the ROM itself, the initialization sequence is crashing somewhere. Now be careful :), the kernel in itself, can boot-loop also due to malfunctioning driver, panic's and reboots itself.

    So the question is, which is it?, Is it the kernel that keeps rebooting itself or has it got passed that stage and started loading the ROM? If its at the stage of loading the ROM, then something in the initialization is crashing, when the ROM crashes, it sends a signal to shutdown SurfaceFlinger, AudioFlinger, adb daemon, MedaServices etc.

    What you can do is this - in the init.rc, where you have this:

    service console /system/bin/sh
        user shell

    Change disabled to enabled, the next time, Android will dump you into the console, i.e. no familiar graphical interface.

    Also, look for the lines containing servicemanager, if the adbd daemon is listed there, take it out as what happens is the directive clause critical and onrestart will cause you to not have any adb facility!

  • Related Question

    logging - Where are log files located on Android?
  • Questioner

    Possible Duplicate:
    How can I view and examine the Android log?

    My android (2.1) phone (a HTC Wildfire, if that matters) sometimes reboots without an apparent reason. Not extremely frequently, but too much to simply ignore it.
    I'd say once every couple of days.

    It always happens when I'm not using the phone, I take it out of my pocket and am greeted by the SIM unlock screen, so it's hard to pinpoint the app or service that is causing it.

    I browsed the filesystem a bit but couldn't immediately find anything like /var/log, so I wonder if anyone knows where logfiles are located, if they exist at all?

    Or any other way to easily pinpoint the offending process on my phone?

  • Related Answers
  • Edelcom

    If you want to examine the log outside the environment of your phone, there is the application LogCollector.

    It's free and it allows you to send/upload the log to/with the program of your choice. I just send the log via gmail to my home email account.

    It is always easier to read such log files on your pc screen, compared to reading it with whatever application on your (small) Android screen.

  • Seasoned Advice (cooking)

    How do you know your phone has rebooted? Just because the lockscreen appears doesn't mean it rebooted. Check your battery stats, Settings > About Phone > Batter and look at the up and awake time. If the phone has been up for a long time its unlikely your phone is rebooting on you. Just check this after a time when you think the phone has rebooted.

    I think you are going to have to use logcat to get logs from an Android phone. If your phone is rebooting on you, you could attempt to run logcat, but you would have to have logcat running continuously to capture what is going on and making it reboot. This is not very practical. But look below for info on logcat.

    Instead of using logcat I would try just starting from a fresh install of Android. If you are rooted I would backup, wipe, and install a ROM from scratch. If you are not rooted, I would download the latest version of Android for your phone from HTC and install it. This will wipe your phone, but running from a clean slate should fix the reboot issue.

    Once on your fresh Android install open Market place and install your apps starting with essentials only. DO NOT INSTALL any task killer of any kind. Reboot and see how the phone runs for a few days. If things seem fine then move on and install your other apps a few at a time. Give it a few days and continue on to the next few apps until you find the app that is giving you problems or maybe all you needed was a fresh start.

    Logcat: Install the Android SDK on a computer and then open a terminal shell (cmd.exe in Windows) and run adb logcat. On windows it looks like:

    adb logcat

    Sometimes I have to specify the whole path for that command to work. For me it would be:

    C:\Downloads\evo\android-sdk-windows\tools\adb.exe logcat

    You mileage will vary depending on where you install the SDK...

    After running that command you will only be able to view what the terminal shell can contain or hold in memory. My recommendation would be to increase the buffer size of the terminal shell so that you can capture more information. More advanced shells might be able to output a text file, I would try that too. If you do not have this option just copy and paste everything in the screen to a text file yourself. In cmd you do this by right clicking, mark, highlight what you want, and then go to the text file and paste.

    Also this is not always the best route unless you know what you are looking for because logcat will essentially show output of everything your phone is doing. So there will be a ton of data generated.