I want to get a better idea how a program I have operates, and rather than print the code out and try to see which method calls which method, it'd be easier to just run a debugger that steps through every line.
But manually putting a breakpoint on every line seems a bit laborious.
Is there any option to step through every line of the program as it runs(without manually putting in all the breakpoints)?
So that I could then see, ah MainActivity launches and runs onCreate and I could see it running through the code of onCreate how it then goes to a fragment class's onCreateView method.. and so on.. I want to see who is calling who as it happens and step through.
You don't need to add breakpoints on each line. Just add a breakpoint to the entry point of your application and then simply use the step-in and step-out buttons of the debugger to execute the code line by line.
In order to prevent the debugger from stepping through the code that wasn't written by you, go to File > Settings > Debugger > Stepping and then on the right, click the plus icon with the question mark that says Add Pattern to add the following patterns:
android.*
dalvik.*
com.android.*
Related
I have recently found the beautiful tool of debug code which helps a tons to find error and perfect my macro. I am however stuck with a loop that the debug does not want to go over. In other words, I would like to understand:
how I can debug each line of a code,
debug 1->n times (n being a finite number of times) the loop
THEN go past the loop and debug the rest of the code.
I cannot find a way to debug past the loops. Could also someone try to explain me in general the most important things of the debug function?
Edit: Inserted example of code
I Still cannot go past the Nexts: if I press and hold F8, the code runs forever never pasting the loop. I have found a workaround which is to drag the highlighted F8 line code down to the desire location but it is annoying doing so when the code is long; also, if the code breaks I need to redrag it manually each time. I would like a way I could use that allows me to let's say run the debug only from line 40 to 60 not before not after.
Example of the code
Here some tips to Debug in VBA:
With F5 you execute the code until the end of the Sub or Function
With F8 you execute a single line of code.
By clicking on a line or pressing F9, you set a break point.
With these simple tips you can do almost everything with the Debug tool.
If you want to quickly get out of a loop, just set a break point on the immediate line of code after, and then press F5, like this:
You can use F8 to step through your code line by line
You could use BreakPoints which can be inserted by clicking on the line you want to break on i.e. the one after the Loop and press F9
or a very underrated function is Debug.Assert. You can use this to write an expression that it will test against and break on when it evaluates to Falsee.g.
Debug.Assert i < 50
The above will break on any value that is greater than 49.
Don't forget to remove/handle this in your production copy though
In Visual Studi you can do recording in IE as an example. You enter an url, insert some data and finish your recording. After that some code are generated. What if you want to change the recording? How do you resume a recording if something in the user interface changes? Do you have to sart all over start a recording based on the generated code?
You can add new recordings without losing the old. The normal recorder is used. When you save a part of the recording you name the action or assertion method. If the same name as an existing method is used than that method is replaced. However a completely new method can be created.
Assuming that you are using the default UT Map then position the cursor in the c where the new method should be called. Use the context (right-click) menu at that cursor position (I find adding a empty line makes it obvious where the new call will be inserted) and select the command Generate code for Coded UI test => Use Coded UI test builder. The normal Coded UI recorder will start.
If you are using multiple UI Maps then select the UI Map to have the new code and from its context menu select the ""Edit with Coded UI test builder" command. After recording a new method, add a call of it in the required test method.
If the new recording is wanted to replace a small part of an existing method, or to go in the middle, then I recommend using the UI Map editor to split the existing method into two or more pieces and then use the recorder to replace the unwanted part leaving the wanted parts as originally recorded.
A breakpoint can be set within a Coded UI test then, when the test is run in debug mode, execution will stop at the breakpoint. This lets the test be executed as so as to move the application being tested to a specific place within the test. Having reached the desired breakpoint, the test execution (ie the debug session) should be stopped. At this time the application is waiting for further input and the recording actions described above can be used. There are several ways of startng the test in debug mode, including the options on the "Run test" icon and the context menu of the [TestMethod].
I am new to the debugger. When I step over a line of code, I was wondering how to step back. Now I'm realizing that the code can't be executed backwards? Do I have to restart the activity in debug if I want to step back to old lines?
Also, if you don't mind, what is the force-step-into command?
Don't think that is possible. Android works like all other debuggers, which are more or less waterfalls over the code. You can't really step backwards, but thats where breakpoints come in. Place a break point before the line you wanted to step backward on and rerun your app, it'll keep going until it hits that line.
To explain Force-Step-Into I'm going to explain Step-Into/Over first. Step-Over sees the line you want, and steps over it, stopping at the line in the same file after the function call was made. Step Into on the other hand steps into the function call and stops on the first line of that function call, could be in a new file or a new location. In Android, there are a lot of functions that are considered "Black Boxes" where you don't really care what they do since they most probably don't affect the code (Like the Log.d function). Force Step Into allows you to step into those if you'd want to.
Source: https://www.quora.com/How-would-you-explain-in-one-line-about-Step-over-Step-into-Force-Step-into-and-Step-out-of-Android-studio
Notice that you can set conditional breakpoint, i.e. breakpoint will stop execution only if x == 57 (so you don't have to skip manually all 56 breaks). Very useful. Just set breakpoint, click with right button on it and set your condition.
May be Frames can help to check method() calling stack in debugger window
YES, you can!
According to the Android Dev Summit in 2019, now you can step back while debugging with Android Studio!
Check out the live demonstration.
All you need to do is to press the Drop Frame button in your debug view, and then Resume Program. Then you will automatically get back to the last break-point.
Note: the device should run at least Android 10.
I don't think that is possible, like #OmegaNalphA mention, but you can have a look on the stack trace and see the order your code is executed.
StackTraceElement trace = new Exception().getStackTrace();
Log.d("myapp", trace.toString());
Trying to troubleshoot something that of course only happens in IE, but I can't seem to get it to allow me to execute any code in the JS console. Is there some magic keypress that turns that function on?
If it is a single line of code, hitting [Enter] should execute the command.
If you paste in multiple lines of code, your editor will get set to Multi-line mode. In order to execute script you will then have to press [Ctrl]+[Enter]
You could also always click the green arrow to the right of the text field to execute the script.
I am trying to run the following code with break points as follows:
new Thread(new Runnable() {
#Override
public void run() {
System.out.println("Starting"); //breakpoint here
}
}).start();
int i = 10;
i++; //breakpoint here
when this code runs ONLY the i++ breakpoint is hit... If I remove that one, the other thread's breakpoint would be hit correctly. Why is this weird behaviour occuring?
This is documented in http://www.jetbrains.com/idea/webhelp/breakpoints-2.html:
There are certain cases when IntelliJ IDEA will not stop at a breakpoint. Consider the following situation:
Two breakpoints are set at the different methods of a class, and there suspend policy is set to All.
When one of the breakpoints is hit, some step actions are performed.
If at the time of stepping another thread hits the second breakpoint, IntelliJ IDEA will not stop there.
I copied your code example and recreated the situation.
Sure enough, like it says in the documentation, after stopping at the i++ breakpoint, if I hit F8 (step over) the program doesn't stop on the other breakpoint. But if I hit F9 (resume) the program does stop again on the other breakpoint.
I just had this problem and for the sake of others that run into this, here is the reason for this behavior and how to change it.
As Doron pointed out, there is documentation concerning this. However, the IMPORTANT thing to notice is that by default, all threads in the JVM are suspended when a breakpoint is reached.
What you are expecting (and what I was expecting) is that only the thread with the breakpoint is suspended.
This isn't what you want, nor is it what I wanted.
To change this behavior (and provide the desired behavior).
1) Create a breakpoint by left clicking in margin.
2) Press ctrl+shift+F8 (to bring up the breakpoint menu).
3) Select your breakpoint. You will see options for it.
4) Make sure "Suspend" is checked and "Thread" radio option is selected.
5) Click the "Make default" button.
Now, when you run, you'll see that breakpoints in different threads are hit.
Because the other thread is scheduled to run in the background, and when the OS thread scheduler decides to run it, it will run. When you do have a breakpoint in it, it will be hit.
It won't have started necessarily when you just run through the code, so the breakpoint at i++ is hit immediately.