IEICE TRANS. INF. & SYST., VOL.Exx–??, NO.xx XXXX 200x1LETTER

Semi-automatically Extracting Features from Source Code ofAndroid Applications
Tetsuya KANDA†a) , Yuki MANABE†b) , Nonmembers, Takashi ISHIO†c) , Member,
Makoto MATSUSHITA†d) , Nonmember, and Katsuro INOUE†e) , Fellow

SUMMARY It is not always easy for an Android user to choose themost suitable application for a particular task from the great number ofapplications available. In this paper, we propose a semi-automatic approachto extract feature names from Android applications. The case study verifies
that we can associate common sequences of Android API calls with featurenames.
key words: Android, feature extraction, software categorization, API

1. Introduction
Android is one of the most popular platforms for mobilephones and tablets. A user can search and choose from morethan 600,000 Android applications in Google Play [1]. Because there are so many choices, however, selecting an appropriate application is not a trivial task. For example, inNovember 2012, at least 1,000 applications could be foundwhen searching with the keyword “calculator” on GooglePlay.
A simple but important criterion for selection of an application is the set of features it provides. Investigating thefeatures by trying each application, however, is time consuming. Although documentation is an important source ofinformation, many applications are less than adequate in thisarea.
MUDABlue [2] and LACT [3] are the solutions that enable users to focus on a set of similar applications. These approaches automatically categorize applications with similarfeatures based on characteristics of the source code. Whilethey can extract a set of similar applications, they cannot
show a list of the features provided by the applications in aspecific category.
In this study, we propose a semi-automatic approach toextracting features from Android applications. The promiseof our proposed solution is that a feature can be associatedwith a particular sequence of API calls. API calls are used
to control GUI components, network connections, and hardware devices such as a camera, GPS, or touch screen. AlManuscript received January 1, 2011.
Manuscript revised January 1, 2011.
†Graduate School of Information Science and Technology, Osaka University,
1-5, Yamadaoka, Suita, Osaka, 565-0871, Japana) E-mail: t-kanda@ist.osaka-u.ac.jpb) E-mail: y-manabe@ist.osaka-u.ac.jpc) E-mail: ishio@ist.osaka-u.ac.jpd) E-mail: matusita@ist.osaka-u.ac.jpe) E-mail: inoue@ist.osaka-u.ac.jp
DOI: 10.1587/transinf.E0.D.1

though software developers can use arbitrary sequences of
API calls, we hypothesize that a popular feature of an application is likely to be implemented by the same sequenceof API calls, since similar applications use the same set ofAPIs [4]. In our proposed solution, therefore, we automatically extract common sequences of API calls in two or more
applications, and manually associate each of these with afeature name. We use the associations as a knowledge-base.
We then automatically extract API calls from other target
applications and, using our knowledge-base, output featurenames associated with the API calls.
It should be noted that this paper is a revised versionof our technical report [5]. The technical report describes
the detailed implementation of our method. We compare
extracted features from applications in this paper while wecompared sequence of API calls of applications directly inthe technical report, yet it does not aﬀect the result of thecase study.
The next section describes the technical details of ourapproach. Section 3 shows the results of a case study. InSection 4, we conclude this article with a discussion of future work.
2.

Associating API Calls with Feature Names

The objective of our study is to extract a list of featuresfrom multiple applications and build a knowledge-base. A
user can then more easily compare the features of two ormore applications. Our approach has two phases: build aknowledge-base from a set of applications, and, using theknowledge-base, extract and list the features from anotherset of applications.
Our knowledge-base is defined as a set of associations
hS , f i, where S is a sequence of API calls and f is a feature
name. We build a knowledge-base using the following threesteps.
Step 1 We translate each application into a set of sequences of API calls. As Android applications are written
in Java, we extract a sequence of Android API calls fromeach method of the application. A method call is identified by its name and the receiver type declared in the sourcecode. We recognize an Android API as any method callwhose fully qualified class names start with “android.” or“com.google.android.”. Figure 1 shows an example of a sequence of API calls extracted from a method in an application. API calls in a sequence are sorted by line number. If

Copyright c 200x The Institute of Electronics, Information and Communication Engineers

IEICE TRANS. INF. & SYST., VOL.Exx–??, NO.xx XXXX 200x

2Source CodeAPI CallingSequence

public void onClick(View v) {String s = str.substring(2);Intent intent=new Intent(this,com.example.edit.class); 1
startActivity(intent); 2｝

android.content.Intent.<init> 1
android.app.Activity.startActivity 2Fig. 1tion on a map and that T2 is probably not a map viewer.
It should be noted, as we hypothesized, that 18 of the23 identified API calling sequences are involved in at least
one target application. This result is promising because it indicates that a small knowledge-base could cover the popularfeatures of many applications in the same category.

Extracting sequences of API calls

4. Conclusion
two or more API calls are involved in a single line, they aresorted in alphabetical order. As a result, N applications aretranslated into sets Apps = {A1 , · · · , AN }, where Ai is a set ofsequences of API calls extracted from the i-th application.
Step 2 We extract common sequences of API calls involved in at least two applications as candidates for features.
We compute a set of common sequences as follows:∪C={LCS (s, t)|s ∈ Ai , t ∈ A j }Ai ,A j ∈Apps,i, jwhere LCS (s, t) is the longest common subsequence of twosequences s and t. We exclude sequences that consist ofonly a single API call from C. We denote the resultant set
by CommonAPI.
Step 3 We manually associate each sequence S inCommonAPI with a feature name, f , and store the association hS , f i in a knowledge-base. A feature name canbe associated with a sequence if the sequence controls aparticular device or system component, because application
features are often characterized by devices and components
used by the application.
We use the knowledge-base to translate API calls in atarget application into feature names. If an application involves a sequence S 0 , including a subsequence S , matchingan association hS , f i in the knowledge base, we output f asa feature of the application.

We proposed an approach to extracting features from an Android application using a knowledge-base built from sourcecode of applications. The results of a case study showedthat our approach could extract features from an applicationand list them in terms of devices and components used bythe applications. Although our approach is promising, wewere unable to represent the usage or purpose of the components. We also could not recognize features implemented bygeneral-purpose GUI components. To resolve this problem,
we intend to enhance our approach using information aboutdata names and types used in applications. In addition, wewould like to use our approach to understand the variabilityof software product lines in our future work.
Applications used in the case study

Table 1ID

Application name

LOC

#API calls

KB1
KB2
KB3
KB4
KB5
KB6
T1
T2
T3
T4
T5

OpenGPSTracker
mapsforge
OSMandroid
TripComputer
shareyourdrive
savage-routerMapDroid
cycroidyozi
maps-minus
BigPlanetTw

8122
37326
3150
14487
2761
1041
6387
1278
5348
1785
4139

1099
1407
175
825
346
66
1160
761
159
218
432

3. Case Study
Example of sequence of API calls

Table 2

We conducted a case study to evaluate whether our approach
could extract the features of applications. We collected 11
applications labeled “Map” in Google Code as shown in
Table 1. We built a knowledge-base from six applications(KB1-KB6) and then used it to extract features from the remaining applications (T1-T5).
We extracted 156 common API calling sequences fromthe six applications. The first author of this paper could associate names with 23 out of the 156 sequences. Table 2shows an example of the sequences and their feature names.
The feature names simply describe what components arecontrolled by the API sequences. In this example, “Alert dialog,” “Submenu,” and “Show Toast (pop-up message)” arerelated to the user interface, while “Get Location” and “SetLocation” are related to map features. Using the knowledgebase, we then extracted a list of features for each application(T1-T5). Table 3 shows the features found in the target applications. From these results, without using the applications, we could observe that T1 and T5 can specify a loca-Feature name

Sequence of API calls

Show toast(pop-up message)

android.app.AlertDialog.Builder.<init>
android.app.AlertDialog.Builder.setTitle
android.location.Location.getLatitude
android.location.Location.getLongitude
android.widget.Toast.makeText
android.widget.Toast.show

Set Location

android.location.Location.setLatitude
android.location.Location.setLongitude

Submenu

android.view.Menu.addSubMenu
android.view.SubMenu.setIcon

Alert dialog
Get Location

Table 3

Features identified in five applications

ID

T1

T2

T3

T4

T5

Alert Dialog
Get Location
Show Toast(pop-up message)
Set Location
Submenu

3333333333333333

LETTER3

Acknowledgement
This work was supported by JSPS KAKENHI Grant Number 23680001.
References[1] “Android Apps in Google Play - The year of opportunity.” http://commondatastorage.googleapis.com/io2012/presentations/
live%20to%20website/123.pdf.
[2] S. Kawaguchi, P.K. Garg, M. Matsushita, and K. Inoue, “MUDABlue: An automatic categorization system for open source repositories,” Proc. Asia-Pacific Software Engineering Conference, pp.184–193, Nov. 2004.
[3] K. Tian, M. Revelle, and D. Poshyvanyk, “Using latent Dirichlet allocation for automatic categorization of software,” Proc. International
Working Conference on Mining Software Repositories, pp.163–166,
May 2009.
[4] C. McMillan, M. Linares-Vasquez, D. Poshyvanyk, and M. Grechanik,“Categorizing software applications for maintenance,” Proc. International Conference on Software Maintenance, pp.343–352, Sept. 2011.
[5] T. Kanda, Y. Manabe, T. Ishio, M. Matsushita, and K. Inoue, “A prototype of comparison tool for Android applications based on diﬀerence of API calling sequences,” IEICE Technical Report, SS2010-10,
vol.111, no.107, pp.35–40, Jun 2011.