any best way to debug exception unless using logcat since the overall code are very big? do u think using break point to view the value if installing apk into actual android phone and running it on the phone via usb cable?
do u think using break point to view the value if installing apk into actual android phone
If this means, 'can you debug using breakpoints on the actual phone?'. The answer is Yes
Here is a tutorial you can follow
The size of the codebase is mostly irrelevant when trying to find the cause of an exception (It might complicate things a little, but in general the procedure is the same as debugging a small application). Debugging is the most efficient way of finding bugs, because you're running directly inside your application and you will not have to speculate about the current state of your application (you can actually look at it).
I suggest that you...
Get familiar with Eclipse debugging
Read the stacktrace
Try to find the exact line in the code where the exception happened (according to the stacktrace)
Set a breakpoint at the exact line or at the beginning of the method
Restart you application and wait until you hit the breakpoint
Inspect the variables using the tools in Eclipse
Hope that helps.
Related
Please note, unlike many other questions having the subject title "application has stopped unexpectedly", I am not asking for troubleshooting a particular problem.
Rather, I am asking for an outline of the best strategy for an Android/Eclipse/Java rookie to tackle this formidable task of digesting huge amounts of information in order to develop (and debug!) a simple Android application.
In my case, I took the sample skeleton app from the SDK, modified it slightly and what did I get the moment I try to run it?
The application
(process.com.example.android.skeletonapp)
has stopped unexpectedly. Please try
again.
OK, so I know that I have to look LogCat. It's full of timestamped lines staring at me... What do I do now? What do I need to look for?
Is there a way to single-step the program, to find the statement that makes the app crash? (I thought Java programs never crash, but apparently I was mistaken)
How do I place a breakpoint?
Can you recommend an Android debug tutorial online, other than this one?
I'm an Eclipse/Android beginner as well, but hopefully my simple debugging process can help...
You set breakpoints in Eclipse by right-clicking next to the line you want to break at and selecting "Toggle Breakpoint". From there you'll want to select "Debug" rather than the standard "Run", which will allow you to step through and so on. Use the filters provided by LogCat (referenced in your tutorial) so you can target the messages you want rather than wading through all the output. That will (hopefully) go a long way in helping you make sense of your errors.
As for other good tutorials, I was searching around for a few myself, but didn't manage to find any gems yet.
Filter your log to just Error and look for FATAL EXCEPTION
If you use the Logcat display inside the 'debug' perspective in Eclipse the lines are colour-coded. It's pretty easy to find what made your app crash because it's usually in red.
The Java (or Dalvik) virtual machine should never crash, but if your program throws an exception and does not catch it the VM will terminate your program, which is the 'crash' you are seeing.
Check whether your app has the needed permissions.I was also getting the same error and I checked the logcat debug log which showed this:
04-15 13:38:25.387: E/AndroidRuntime(694): java.lang.SecurityException: Permission Denial: starting Intent { act=android.intent.action.CALL dat=tel:555-555-5555 cmp=com.android.phone/.OutgoingCallBroadcaster } from ProcessRecord{44068640 694:rahulserver.test/10055} (pid=694, uid=10055) requires android.permission.CALL_PHONE
I then gave the needed permission in my android-manifest which worked for me.
From the Home screen, press the Menu key.
List item
Touch Settings.
Touch Applications.
Touch Manage Applications.
Touch All.
Select the application that is having issues.
Touch Clear data and Clear cache if they are available. This resets the app as if it was new, and may delete personal data stored in the app.
I am new to android application development, I am finding it difficult to debug my program I am always getting some abstract message like "your application stopped working" I need to know exactly. I have read there are many ways to debug. What I need to know is the way which will be easy for beginners like me.
If you are using eclipse (if not you should, is the easiest way to develop/debug for android) take a look at these tutorials, specially the second one (there is a lot more out there if you google a little):
http://www.latenightpc.com/blog/archives/2007/11/21/starting-a-debug-session-for-android-with-adt
the main point you should research about is LogCat and debugger (both covered in the above links)
In eclipse always look at the logCat output in the DDMS or Debug window when the app crashes. Often (buried in the output) is a line telling you exactly what statement (file and line number) caused the crash. Sometimes you need to hit resume (F8) in the Debug window to get the output. Once you get that info you could set a breakpoint at the offending statement and then look at what variable(s) are messed up.
Try the following:
Create a HelloWorld application.
Add a Log statement to the end of onCreate:
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Log.d("HelloWorldActivity.onCreate()", "setContentView() completed");
}
Place a breakpoint on the Log statement.
Run the app in the emulator and note it works and step to see the Logged entry in the LogCat window of Eclipse.
Change the HelloWorldActivity to extend from ListActivity instead of Activity.
public class HelloWorldActivity extends ListActivity {
Run the app in the emulator again and note it fails to reach the Log statement.
My question is NOT why this fails. My question is, how would you go about debugging this failure? All I see in the Eclipse Debug pane is a RuntimeException. I see LogCat has a bunch of messages, but it's huge and I've searched it but can't find anything to indicate what's wrong or where in my code the exception happened. I can't find a way to display the message inside the RuntimeException or a stack trace to know which line of code initiated the exception.
I assume there must be better ways to use the tools to find errors, but I'm new and can't seem to figure out a better way to debug besides wrapping everything I code in a try/catch. I would have expected to find a message in LogCat generated by the throwing of the exception. I would have expected the Debug window to allow you to inspect the exception's contents. I'm not saying that such techniques don't exist, I'm saying I'm having trouble figuring out as a beginner how to debug and asking what techniques do exist and how do I use them?
So, simply put:
How would you find this error if you didn't already know what was causing it?
What techniques would you use to find out the root cause?
How would you go about inspecting the Exception's details?
Generally, how do you find problems in your Android code using Eclipse?
Multiple suggestions and discussion are welcomed. :)
I would have included my LogCat contents, but it's so large that's not reasonable. You should be able to easily reproduce this yourself, so I left it out. It is possible something is in LogCat to help me, but because it's so large with even running a small program, I would need a hint as to what to search for and how to interpret it when hitting an exception thrown from an API call. I see other posts that state something should be in LogCat, which while might be true, I'm not finding anything myself. If you think something should be in LogCat, please run the test yourself and copy the lines into your response that I should be finding.
Thanks.
========
Summary techniques list so far is as follows:
Invasive Techniques:
1. Place a Toast in code locations where you want to see you you've executed.
2. Place try/catch around code where you think there's a possibility of an Exception being thrown.
3. Comment out code and recompile and retest.
Non-Invasive Techniques:
1. Use the debugger. Breakpoints, variable inspection...
2. Monkey stress tester.
3. Download Android source library.
4. Use LogCat filters to see if a "Caused By" is listed.
Unclear if Available:
1. Debug version of Android library that has additional logging, assertions or other additional help.
2. Ability to inspect an Exception in Eclipse through the Debug pane or other techniques.
3. A way to define a more global try/catch exception handler.
4. Ability to debug through the Android library source code.
Not Available:
1. A non-invasive way to view the contents of an Exception or where the Exception happened.
hey,
Ineresting question. Well, first tip, you can filter what logcat tells you. For instance, you make it just show you errors by clickin in the red (e).
It also tells you where the error happened if you run your app in debug mode. It can either point you directly to your code or to android sdk. Knowing what android package caused the error is a big help.
These two just pop into my mind. hope it helps!
I was running into the same issue and found the following by Steve H. that helped out:
What happens is that when the debugger
is attached, the exception logs don't
get posted to LogCat until you
terminate the application from within
the Debug perspective. This happens
because the application doesn't
actually crash until the debugger
detaches. – Steve H Mar 31 at 15:47
------ yup, that did it. Now I see the same exception. AFTER I let the
program run through it's full crash
and exit process. It should display
that info when it halts my program and
brings up the IDE debugger screens.
Not leave me wondering and wasting my
time with more clicking around.
Eclipse has a long way to go it seems
to compete with the likes of Visual
Studio. Let's hope my patience for it
outlasts my project. Thanks for the
feedback. :) – Sebastian Dwornik Mar
31 at 17:35
Link to Question: What's wrong with debugging in Eclipse on Android?
Generally if anything throws an exception then you should probably be catering for that situation anyway, however putting try/catch blocks is a decent way of finding the specific problem.
I've found that if you don't put something in the catch block then you can't evaluate the exception in the watch variables window in eclipse. So i always put a Log call in and set a break point on that line.
public void onCreate(Bundle savedInstanceState) {
try{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}catch(Exception exception)
{
// put break point on line below so you can evaluate exception in debug mode.
Log.e(TAG, "Set content exception "+ exception.getMessage());
// note some exceptions return null on getMessage();
}
Log.d("HelloWorldActivity.onCreate()", "setContentView() completed");
}
So if your stack trace is huge then this will help. Other developers have also found that getting the source code for the sdk means you can view where the error is thrown in the main sdk code. I've not done this though.
Exceptions not caught with try/catch are errors and break the normal flow of the program.
Running in debug mode is just clicking in the bug button. I don't know if there are any "special" debug libraries. But when working with android, all "libraries" are open source so you can pretty much view anything.
The good thing about debug mode is that when an error occurs, your app is frozen right in the limbo when the error occurs. You can set set breakpoints, change your code on the fly while your program is running, which is great (Well, you can't make drastic changes like changing a method name).
The way you treat bugs and errors in android, however, can be a bit different from .NET, since the model in each one is different.
When programming to windows, apps work like small islands. You have a much direct control over the code flow (ie: you can call a modal dialog to freeze codeflow while a user inputs some data) and you can make a totally functional program using just one thread. In android almost everything runs in it's own sync. And your app must be prepared to handle stuff like receiving a phone call in the middle of execution. So, you can apply this model to debugging also: Errors (that happen due to unforsen circumstances) tend to propagate much more than in other development ambient. The way those errors are handled is different too: this is apparent when you realize that your app still runs even after throwing an exception.
Some more useful tips:
You have a very powerful tool called Monkey, a stress tool that generates "pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-
level events".
LogCat indicates you the "cause" of the error. The line usually starts with Caused By. If you're interested in the cause rather than the consequence, you can further filter your error reports looking for "Caused by".
Last but not least, I find the old method of commenting lines and see what happens very useful to figure things out.
hope it helps
I've read the lame documentation, and checked other answers. I'd like my Android app to print some debug statements in the logcat window of Eclispe. If I use the isLoggable method on the various types of debug levels on the Log class, I find that WARN and INFO are returning true.
Log.w, and Log.i do not produce any output. Does anyone know which gotchas I've missed?
And just to vent, why should this be hard? I've published apps for iphone and bberry and while appreciate the use of java, the platform is reeking of too many "genuiuses" being involved. I suppose Activities and Intents are very flexible, but why? I just want to put up some screens, take some input and show some results. The bberry pushscreen and popscreen is a lot less pretentious.
Thanks,
Gerry
The problem with debugging with Android in Eclipse is that from Eclipse's point of view, you're debugging the emulator and not your specific app. The emulator isn't crashing, so there aren't any logs to show. What you need to use is LogCat, Android's debugging plug-in. See this answer for details on how to bring that up.
It is not clear to me what the problem is. I use "Log.d(TAG, "special message");" all the time in Eclipse in Android code running in the emulator. Since you say "Log.w" gives no output, I assume you already know about the need to import android.util.Log. Otherwise you would not have got even that far.
The only other thing I can think of is for you to check your Eclipse Preferences under Window>Preferences>Android>DDMS (DDMS is needed for Logcat). Make sure the timeout is reasonable (mine defaulted to 5000mS). Make sure the base local debugger port is open, too.
I am a little bit new to developing for Android using Eclipse (Coming from a .NET/Visual Studio background).
My biggest problem in developing Android app is "debugging" them. Every time the emulator throws an error, there is no message, no explanation of what caused the error. I basically have to keep doing trial/error until something works.
My question is: Is there a better way to analyze the error messages that emulator shows (basically some stack trace about Dalvik)!
Also, is it possible in Eclipse [when debugging] to move the debugging cursor backwards to re-evaluate a variable or "skip" some lines of code?
Use LogCat view to see error/debugging messages. Regular console is of very limited help. Window->Show View->Other->Android->LogCat There on the top you will see some round buttons that basically can filter log from V (verbose) to E (error). You can't copy/paste from theLogCat window but you can save selected output to text file
Regarding the error messages (I'm assuming these are the messages that show up in LogCat): I've found that analysing the error messages and working your way up the list until you reach code that is yours is the most effective way to work. Frequently (for me at least) the emulator will crash and break somewhere in the OS code (which you probably don't have the source for) but you can follow the LogCat messages back to your code and start to see where the problem is. The crash may appear to happen in the OS code, but the original cause is typically you passing something wrong to the OS.
Regarding going backwards in code: nope, at least not with the my Eclipse Ganymede install
Regarding skipping code: When your in debug mode under the Run menu you can select "Step Over" (skips going into a method) , "Step Return" to exit a method and "Run to Line" in addition to setting Breakpoints by right clicking. This causes the code to run, but you aren't single stepping through it. Otherwise the only way to "skip" lines of code is to comment it out. I believe you can also change the value of variables in the debugger, but I've never tried personally. This may give you the desired effect.
Try closing all unrelated project, switch off eclipse and then do a clean and build for the project in picture.