Let’s learn how to set this up using a simple example: This even works across multiple “cuts” spanning complex asynchronous execution paths. Later on, when you want to see the async call stack of your code, the IDE will cut and concatenate the call stack at these substitution points, creating a single async stacktrace. IntelliJ’s async stacktraces work by recording stack information at specific substitution points inside your code. Once everything is set up, your IDE will produce stacktraces like what’s shown below. At the time it was written, async stacktraces had pretty much the same feature set they have right now, but everything was named a bit differently.Įven with that limited amount of information, it is possible to figure out how async stacktraces work - I spent a couple of minutes (hours) in a trial and error approach to wrap my head around it.

The second resource you will find on this feature is the launch blog post of IntelliJ EAP 2017.1. Of course, we all write sophisticated code, so let’s look at an elaborate example of this: However, for larger scale async code, it might be more complicated to find the execution path. For a click listener, it might be easy to find out by simply navigating to the callback method in code (unless you pass around listeners like crazy). However, you can’t find out where the called OnClickListener was registered on the button just from looking at the frames. You can easily spot the name of the activity ( MainActivity) and the line number inside the callback method. The stacktrace above is the result of a simple button click. Often when debugging asynchronous code, you will look at a line of code and think: “Who called this method?” or “Where was this async call enqueued?” You’ll probably know how this call was enqueued. Just like any other code, your asynchronously executed code will have bugs (unless your name is Chuck Norris) that need to be fixed through debugging. For example, Android apps use a “main thread” for executing user interface code, forcing developers to offload longer-running tasks to background threads in order to keep the UI responsive. When developing software with Java and Kotlin, you will likely use a lot of threading.

Threads android studio debugging