Android boot-up messages for debugging?
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.
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.
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
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!
On my T mobile G2 there is always a lot of action in my Log output that has the tag KINETO these are the two most common things it puts in there:
ERROR/KINETO(9304): KLOG0C3- xmk_QueryOSQueue SDL Queue empty : WAIT_FOREVER
ERROR/KINETO(9304): KLOG0A3- ibs_os_GetMsg: Timeout forever for UKCC qHnd 0x80c34e3c
but there are a lot of others that it does as well. I am wondering what these logs are related to, because they seem to be happening basically all of the time on my device. I did a google search for KINETO and got a bunch of results for Wifi Calling related stuff, which kind of makes sense. My phone came with a Wifi calling app on it. But I never use this app. My suspicion is that I am getting these messages in the log because the wifi calling app does not have access to the internet on my device because of DroidWall. But my question is why does it try so often? and does anyone know if there is a way to stop it from trying so much I am sure this behavior has some negative impact on my battery life.
Kineto is the company that makes the Wifi calling software that is present on some Tmobile phones such as the G2. Unfortunately this software is poorly written. To make matters worse it is only possible to stop or remove the software if you root your phone. (More accurately it isn't your phone - it is tmobile's phone to do with as they please.) Coincidentally I contacted Kineto support yesterday to complain. If more people do that maybe it will get fixed.
It looks to me like they had an existing codebase that they ported to Android hence its poor structure and operation.
Carrier apps like WiFi Calling generally try to run constantly as a background service, and stay connected so that they're instantly available. Beyond that, we can't be any more specific about why it runs all the time (you might get specific details from the carrier, but don't count on it).
If you don't use it and don't want it to drain your battery, remove it! It's probably a system app, which means you need to be rooted to remove it; you can use an app like Titanium Backup to remove it easily.
Another option is to allow it to connect. Presumably it will stop "spinning" and trying to connect if you just allow it to succeed, and use less battery.