Android Debugging Tips

views:

167

answers:

+1 Q:

Android Debugging Tips

Often my programs simply crash. I can't see anything in the LogCat or otherwise useful information elsewhere to find out what's gone wrong. The only thing I see is some kind of exception. This is unacceptable and makes Android programming nearly impossible. I'm sure there must be some additional help to debugging, but after weeks of searching, nothing.

Does anyone have hints on how to find a bug in a program that simply crashes?

General question I know, but without an answer, I'm going to have to quit trying to develop apps for Android. I can't spend weeks of searching for every simple mistake.

+7 A:

I can't see anything in the LogCat or otherwise useful information elsewhere to find out what's gone wrong.

Look harder. Every crash generates something in LogCat.

The only thing I see is some kind of exception.

That would be "what's gone wrong". The stack trace will show you the line of code where your bug resides, and the exception will give you information about what has gone wrong.

This is unacceptable and makes Android programming nearly impossible

Tens of thousands of other developers do not have a problem with this. And, since the same thing occurs in Java applications (exceptions and stack traces), millions of developers worldwide have not had a problem with this. Logged exceptions with stack traces are also used in many other languages and are considered a rather commonplace technique in software development.

CommonsWare 2010-07-23 01:51:19

"Every crash generates something in LogCat." -- and if you add more log statements to your code, it will generate even more!

MatrixFrog 2010-07-23 06:18:52

No. Definitely this is not true. I can sometimes run the program and get NOTHING in the LogCat. NOTHING. Othertimes it's very full, but nothing relevant. I'm calling a library routine, the call never returns but crashes and there is NOTHING generated when it crashes. So NO, definitely this is not a true statement.

Mitch 2010-07-24 21:23:22

The exception is very general sounding "Runtime Exception" and there is no extra info besides this title. Maybe there's a place to find out more info besides there was an exception and it happened at runtime, but that's why I'm asking the question. Stating that "tens of thousands" have no problem assumes you have these numbers and keep track, which I doubt, so it comes off as an Ad hominem attack and even if not is irrelevant to the situation. I get a crash in a library call, there's nothing in the log and no additional information. Is there a place where I can find this additional info?

Mitch 2010-07-24 21:59:53

@Mitch: If you are having difficulty interpreting LogCat, open up specific questions on specific problems, and include the actual logs. It is impossible to teach you how to debug software in generic questions. I actually do keep tabs on the number of developers, and "tens of thousands" is a reasonably accurate statement. It is highly relevant, because if others are not experiencing this challenge, then you're doing something wrong, and we can only help if you supply us with specifics, not generalities.

CommonsWare 2010-07-24 23:42:42

Never said I'm having trouble interpreting LogCat. There's nothing there to interpret. NOTHING. I'm looking for additional techniques to resolve problems where there's nothing in LogCat and the exception returned from the library call is general. Maybe there's additional info somewhere else? Maybe there's some other technique to use? I don't know. I can't be any more specific than that. If you don't want to help, that's cool. Don't help me. Go ahead and publish the data you gathered on the success of "tens of thousands" others and then I'll see just exactly how stupid I am.

Mitch 2010-07-25 05:34:09

@Mitch: There really are no other logs of consequence for ordinary Android development. If you are using Eclipse, compile errors will be in the standard Console pane (versus runtime errors in LogCat, and then only if you actually let Eclipse log the messages to LogCat). If you are using Eclipse, try running your application once and causing the crash outside of Eclipse, then use the standalone DDMS to inspect LogCat (or `adb logcat` from the command line if you prefer).

CommonsWare 2010-07-25 19:20:05

@Mitch: With respect to developer counts, there are 70,000 apps on the Market, 35,000 subscribers to the android-developers list, and thousands of subscribers to my books (and thousands more who bought print editions). If nobody could ever get stack traces and such from LogCat, you think it would have been noticed by now. The most likely scenario, based on the hundreds of students I have trained on Android, is that you're misinterpreting Eclipse. If Eclipse intercepts the exception, run past the exception to dump the full information to LogCat. Or, use the technique listed in the last comment.

CommonsWare 2010-07-25 19:24:19

http://www.youtube.com/watch?v=-_2xGIwQfikPlease watch this. Neil is an excellent educator and Richard is well respected author. Understand, I asked a question. Exactly how many people have to not have my problem before my problem goes away? Just because thousands of people read a book you wrote, does not in anyway imply I'm the only one with my problem. "if others are not experiencing this challenge, then you're doing something wrong,". Yes, tens of thousands of posters know their doing something wrong, telling them so is not helpful. Please listen carefully to Neil.

Mitch 2010-07-31 06:26:03

I found some additional information embedded in the exception. I see nothing in LogCat so I can only guess that not all problems inside Android produce a LogCat message. Maybe there's a debug version of Android that's more verbose? Either way, I found info embedded inside the exception and that led me to an answer in someone else's posting. It'd be nice if I had a way to dig that info out of the exception without writing code to extract it from the exception.

Mitch 2010-07-31 06:34:06

@Mitch: the exception and its stack trace get dumped to LogCat, assuming your debugger does not interfere with this process.

CommonsWare 2010-08-01 06:55:15

+2 A:

There's also the actual Eclipse debugger. If you just run the program with the debugger until it crashes, you may not see a particularly helpful stack trace. But if you add a breakpoint or two in the code that comes just before the crash, you can step through carefully and figure out what's going wrong.

Also, although I'm still pretty new to Android development, my experience is that most of the mysterious crashes in my code are essentially ClassCastExceptions. Look carefully for all the places where you're casting something from one class to another, and make sure you're not assuming something is of a type that it's actually not.

MatrixFrog 2010-07-23 06:21:38

I'll keep an eye out for ClassCastException s, but I'm not seeing that right now. I'm generally pretty careful being a C++ programmer where casting is almost universally a bad idea. But I will be careful of this. Thanks.

Mitch 2010-07-24 21:25:04

It's generally a bad idea in Java too, but it comes up sometimes in Android programming, like `textView = (TextView) findViewById(R.id.textview1)`

MatrixFrog 2010-07-25 20:41:08

ansaurus

tags:

views:

answers:

Android Debugging Tips

related questions