Android Automatic App Explorer (A3E)
is a android application GUI testing utility that facillates developers
to prodcue similar sequence of interaction with the application a
normal user would do. A3E was designed with certain aspects in mind,
- It will not only work in simulators but also in different
android phones on the market.
- It will be able to carry on exploration without the need
source code, thus enabling testers to work on beta testing, and
developers to conduct different types of analysis.
- It will try to discover all ativiites that can remain
hidden to a normal user and launch exploration in those activities.
We aimed to model the application on the context of a Static Activity
Transition Graph. A typical SATG will show the transitional relation
between activities. Where a directional edge from activity A to
activity B demonstrates a potential transition from A to B. This
relation is further verified by careful taint analysis using SCanDroid
We divided our exploration strategy into two schemes.
Targeted Exploration (TE)
TDF has first hand information
about valid activity transitions. It splits the activities into two
different categories, namely,
- Exported activities: Activities with intent filters, that
launched with special request from in or ouside the application. This
includes activites with parameter exported=true. Some applications can
transfer control to external apps. For example one common feature of
applications is to accept feedback from users through mail. Wheneve the
users approach to send mail the application transfer the control to the
mail compose activity of the default mail client user
mail client. Some times these activities which have this added
responsibility are not traversed during a regular use of the program. A
good example might be the inter application login procedure. In this
procedure an app can use the api of another program to manage user
profiles. For example some apps use twitter profile of the user to
manage the profile. Upon login request it transfers the request to
twitter application. The appication then verifies the user
credentials and sends the response. The particular activity of the
verifier external application may not be revealed during a normal run
of the application, in our case twitter. For this reason these
activities can also used as entrypoints to invoke the appliction.
- Inside activities: Activities which can only be reached by
traversing the application in the usual way.
To address the issues with exportable activities A3E constructs an
Static Activity Transition Graph (SATG) from different entrypoints by a
careful static analysis of the application before the actual run.
Static Activity Transition Graph (SATG)
transition graph shows the relation between activities in a parent
child manner. Every node in the graph is an activity within the
application. It is a directed graph, where an edge from parent to
child means there is a transition from the parent to child. To validate
a particular edge we have carried on taint analysis to verify whether a
given path from a source activity to a sink activity actually exists or
not. This was done by a customized version of SCanDroid. A sample
activity transition graph ifor popular app craiglist is demonstrated in
the following image,
Upon getting the verified SATG A3E can start exploring just like the
usual DFS manner, this time it has got the transition information. So,
it can have to added advantages,
- It can invoke exportable activities and follow the path
SATG, so that it can cover more activities.
- Faster exploration as now we have activity transition
beforeand, so the A3E agent does not need to wait to cover all the
The tradeoff is fewer functional coverage such as, method coverage or
instructional coverage, as exportable activities are actually invoked
without user intervention, so some real time instrction executions are
excluded during the play.
Here is the overview of the targeted exploration.
Depth-First Exploration (DFE)
This is the default behavior of A3E. It
mimics the way
users interact with a system. This is because the normal interaction
behavior imposed by android is close to dept-first exploration. Here
users go from screen to screen and visited screens are pushed into a
stack. So, whenever a user return to a previously visited screen the
latest pushed screen comes out.
Following figure illustrates the Depth-First exploration.