8

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.

Mitch
  • 1,716
  • 3
  • 25
  • 41

5 Answers5

3

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.

Tyler
  • 21,762
  • 11
  • 61
  • 90
  • 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 Jul 24 '10 at 21:25
  • 1
    It's generally a bad idea in Java too, but it comes up sometimes in Android programming, like `textView = (TextView) findViewById(R.id.textview1)` – Tyler Jul 25 '10 at 20:41
  • I'm an Android programmer and we use casting all the time. Sometimes researching the class origins and info on the Android Developer pages helps to understand what you are casting to/from (if it's not the same class). – Azurespot Jun 23 '14 at 20:28
1

It sounds to me as if you have an error in your android installation somewhere. The LogCat sometimes gets confused and disconnects from the virtual device (talked about here: getting blank screen in logcat ).

But your problem sounds much more severe. I know it's a pain, but consider making a fresh installation of your android development system (including a brand-new Eclipse install).

I have had similar problems, and a fresh install helped quite a bit (especially after a few upgrades--things can get rather confused).

Good luck.

Community
  • 1
  • 1
SMBiggs
  • 11,034
  • 6
  • 68
  • 83
1

This is a total longshot, but is what turned out to be the answer for this Android newbie: are you sure your device is connected?

What happened in my case (that brought me here, thinking my app wasn't reporting crashes to LogCat) is that what I thought I was debugging turned out not to be my phone, but the Android emulator that I happened to have running at the same time. When I realized that this was happening, I quit the emulator, and the logcat stopped.

When I ran logcat again, it turns out it wasn't even finding my phone:

$ ./adb logcat
- waiting for device -

From there, I had to go through some hoops to get my phone to be recognized, such as adb not finding my device / phone (MacOS X) and enabling debugging on the phone. Lastly, I had to set android:debuggable=true.

After killing adb and running logcat again, I was looking at the right logs, and could see the crash exceptions.

Community
  • 1
  • 1
0

Follow the red numbers. You will need to be in debug view

1) Click the event that that threw the exception 2) Navigate tot he variables generated for that event 3) click on the "e" 4) Look at the detailMessage

enter image description here

Troublesum
  • 257
  • 4
  • 10
0

Actually, I am not sure your are experiencing a normal crash. It might be an ANR or some similar phenomenon that locks everything up. That would probably make you see less logs from your application. I think the debugging support for android is quite classy compared to some other environments I've worked with.

Cubed
  • 43
  • 4