Tracking Library Use
"Where is this library being used?"
Have you ever needed to know where a certain library is used? It can be an important task to find proper use patterns or to replace calls to deprecated code. Finding references to a library can be fast, and Atlas can even show details about how callers use the library. This tutorial will explore strategies for finding library use in ConnectBot, an open source Secure Shell client for the Android operating system. The library we are concerned with is the android library, which we find called from within the ConsoleActivity class.
In this tutorial, we will look at strategies for finding all links to larger portions of a library. If you are concerned with tracking only particular methods or fields in a library, the Smart View is a good way to see all of their uses in your workspace. Select the piece of code you wish to follow, and choose the appropriate Smart View script- dataflow for fields, and calls for methods. For more information on investigating the flow of individual values, see Tracking Variables.
We are doing development on the onConfigurationChanged method, and we find references to static fields in the android.content.pm package of the library. Let us investigate all other uses of this package throughout ConnectBot. Accomplishing a complete survey of references is a task made significantly easier with Atlas.
Enter the package into the Connection View Leaves pane to display a reverse call graph of the entire package. Enter the package into the view either by dragging and dropping it into the Leaves pane or by right-clicking the package and selecting Atlas -> Connection View -> Add To Leaves. Be sure that the "graph kind" selected is Call.
The resulting graph shows all calls in ConnectBot that eventually lead to the android.content.pm package. We can see that the package we're concerned with is used by three methods in two classes. Also visible is one method further up the call tree. In many cases, a reverse graph of this kind can include a large number of nodes. We can use the Connection View to focus on only the methods we care about.
To remove specific elements from the graph, right-click on the elements and add them to the Omissions pane. Alternatively, we can specify exactly how far back the call graph should go by adding only relevant call roots to the Roots pane. When provided with both roots and leaves, the view displays only connections between these two sets of elements.
The direct calls to the library are now visible more explicitly. Building a graph between roots and leaves is a powerful way to zoom-in on important code interactions, and this utility is the primary function of the Connection View.
Let's look at the other method in our class that calls android.content.pm first. The graph shows that this method, configureOrientation, has read edges to three screen orientations, "portrait," "landscape," and "unspecified." This gives some insight as to the method's relationship to the library. It is not surprising, from the similar names of this method and our own, that they share references to the library. This could suggest similar functionality or a possible dependency between the two methods. For a closer look, we can access the source code for configureOrientation directly from the graph.
Double-click on any element of an Atlas graph to examine the source code for that element. Double-clicking the method takes us to the method declaration, or double-clicking the edge directly highlights the line where the library is called.
From the code, it's apparent that the three edges between configureOrientation and the library are accessed conditionally depending on the preferred default device rotation. Noticeably, these values are passed as parameters to setRequestedOrientation in a way that mirrors code in our own method. The library's fields are stored here and checked in onConfigurationChanged. Any modifications to library calls in either method would likely require a parallel change in the other method.
Next, we can see that the only other class accessing the library in question has multiple references from one method, doInBackground. We can see that it shares none of its library use with any of the code we have examined so far.
