社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

A Prototype of Comparison Tool for Android Applications Based onDiﬀerence of API Calling Sequences
Tetsuya KANDA† , Yuki MANABE† , Takashi ISHIO† ,Makoto MATSUSHITA† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University,
1-5, Yamadaoka, Suita, Osaka, 565-0871, Japan
E-mail: †{t-kanda,y-manabe,ishio,matusita,inoue}@ist.osaka-u.ac.jp
Abstract For both users and developers, it is important to select an appropriate application from similar ones.
There are some ways to know the diﬀerences in terms of features in several similar applications, but it is not easy.
In this paper, we present a prototype of a comparison tool which identiﬁes features corresponding to diﬀerences
between API calling sequences extracted from two Android applications. We conducted a case study to evaluate
the prototype tool. The result shows that the proposed tool achieves comparing applications.
Key words Comparing Software, API Calls, Android

1. Introduction

describe all features, or no documents are available from thestart.

Today, people can get many applications from many soft-

If source code of the applications is available, comparing

ware download sites like Android Market [1] and Apple Appthem looks a good way to compare the features of the ap-

Store [2]. Also, they can get a massive amount of source code

plications. UNIX diﬀ [7] is a simple way to compare source

easily from source code repository such as SourceForge.net [3]code. Unix diﬀ shows only lines which have been changed,

and Google Code [4].

and Semantic Diﬀ [8] shows changed lines and its eﬀects on

Among a lot of applications, some applications have sim-

dependence relation between variables. If users want to know

ilar features. For example, about 2,960 applications are hit

diﬀerences between two versions of software, these tools are

by searching with a word “calculator” on Android Market as

useful. However, these text-based comparisons might extractof June 2011. Some tools can categorize them into similar

the whole source code as diﬀ if their design is diﬀerent evenapplication groups [5], [6]. A result of categorization shows

though they use the same programming language. There-

which applications are alike, but the diﬀerences among ap-

fore, it is hard to compare applications in easily understoodplications in a similar group are not clear for users. To selectform by these methods.

the most appropriate application for a user from a group of

In this research, we propose a comparison tool that identi-

similar applications, a tool to compare the features of the

ﬁes the diﬀerences between two applications in terms of theirapplications is necessary.

features. To compare the features of applications, we focused

There are several ways to compare features in similar ap-

on Application Programming Interface(API) calls since soft-

plications: trial use of applications, reading documents, andware developers often combine existing APIs to implement a

comparing source code. However, these methods require afeature [9]. We supposed that a feature of an application is a

lot of eﬀort of users, and it is diﬃcult for users to determine

sequence of API calls; therefore, we can extract the feature-

criteria for comparison. Comparison based on trial use of ap-

level diﬀerence instead of the textual diﬀerence by comparing

plications is also diﬃcult for users who don’t know what fea-

API calls.

tures are provided by each application. Reading documents

In the next section we discuss the background, and in Sec-also have some problem. If documents are not well-formed,

tion 3, we show how we compare API calls. In Section 4,

it is hard to read and compare them. We think that docu-

we describe our prototyping tool and in Section 5, we de-ments are insuﬃcient for the goal because they don’t always

scribe a case study with the tool. In Section 6, we discuss—1—the related work, and ﬁnally we conclude with a discussionof future work.

ƉƉůŝĐĂƚŝŽŶƐ
ǁŝƚŚƐŝŵŝůĂƌƉƉůŝĐĂƚŝŽŶƐ
ƉƉůŝĐĂƚŝŽŶƐ
ĨĞĂƚƵƌĞ

ƉƉůŝĐĂƚŝŽŶyϭƉƉůŝĐĂƚŝŽŶ
yϮ

2. Background2. 1 Platform-dependent

softwaredevelopment

and APIDĂŬŝŶŐĂŬŶŽǁůĞĚŐĞͲďĂƐĞ<ŶŽǁůĞĚŐĞͲďĂƐĞŽŵƉĂƌĞ

WƌŽƉŽƐĂůŵĞƚŚŽĚ

yϭ Ͳ&ĞĂƚƵƌĞ

Platforms such as OS and hardware have characteristic fea-yϮ Ͳ&ĞĂƚƵƌĞ

tures like devices and UI. For example, most software for Mi-ŽŵŵŽŶͲ&ĞĂƚƵƌĞ

crosoft Windows uses the same GUI components, and manyof smartphones have cameras and touch screens. Application

Figure 1 An overview of proposal method

Programming Interface (API) is a set of functions to comDWƉƉůŝĐĂƚŝŽŶƐ

municate with a speciﬁc platform. Each platform provides
APIs to access the features commonly called from a lot ofyϭ

applications, and developers can implement a new feature

yϮ

yϯ

͘͘͘

by calling needed API.
2. 2 API callings and featureǆƚƌĂĐƚ
W/ĐĂůůƐ

Software developers construct an application by combining several features. Developers often make software for a
speciﬁc platform. When the target platform provides a high͘ŵϭ;ͿKDDKE͘ŵϮ;Ϳ
͘ŵϮ;Ϳ
͘ŵϭ;Ϳ

level API, developers implement features by combining several API calls. In such a platform, API calls explain thefeature of the application. While a single API call may di-&ŝůƚĞƌŝŶŐ

&ŝůƚĞƌŝŶŐ

rectly correspond to a single feature, a sequence of API calls
corresponds to a feature in most cases.

͘ŵϭ;Ϳ
͘ŵϮ;Ϳ
ZĞŵŽǀĞ

In this research, we compare API calls in applications toDWϮ͘ŵϮ;Ϳ
͘ŵϭ;Ϳ

compare the features. Tamada et al. proposed to compare
the order and the frequency of API calls to detect some soft-ZĞŐŝƐƚĞƌ

ware theft [10].

<ŶŽǁůĞĚŐĞͲďĂƐĞ

2. 3 Android
Figure 2 Making knowledge-baseAndroid, developed by Open Handset Alliance [11], is aplatform for mobile devices. It includes an operating system,
middleware, and some applications like a web browser. Most

method calls of API classes in a single method.

devices using Android can connect the Internet via mobile

In making a knowledge-base phase, we name API callingphone network or Wi-Fi, and they have touch panels, gravity

sequences which explains characteristic feature and we de-censors, and cameras.

ﬁne them as a knowledge-base. A knowledge-base consists

Android application developers use Android SDK, whichof pairs of API calling sequence and its feature name. A

is based on Apache Harmony (an open source Java imple-

knowledge-base helps to understand what feature is imple-

mentation) excluding GUI classes such as Swing. Instead,mented by the API calling sequence.

Android SDK includes additional APIs to control a camera,

In comparing phase, our method compare two applica-

a GPS device, a touch screen and so on. Android SDK also

tions, application X1 and application X2, and extract fea-

contains Google Maps API by default.

tures that appear commonly(common-feature) and the fea-

3. Proposal method using API calls
In this section, we describe our method to compare twotures thgat appear in only one application(X1-feature, X2feature).
3. 1 The phase making a knowledge-baseAndroid applications. Our method has two phases: making

Figure 2 shows the overview of the making a knowledge-a knowledge-base and comparing two applications. Figure 1

base phase. This phase uses a set of the applications whichshows an overview of the method.

have similar features as the input, and outputs a knowledge-

In this research, we focus on Java applications. We use abase. Common API calling sequences extracted from ap-

term “an API calling sequence” to represent a sequence ofplications are likely to implement the common features of—2—^ŽƵƌĐĞŽĚĞ public void onClick(View v) {String s = str.substring(2);ϭIntent intent=new Intent(this,com.example.edit.class);
startActivity(intent);Ϯ䡙

the applications. Therefore, we can make a knowledge-basethrough naming API calling sequences which appear in two
or more applications commonly (COMMON). In this re-DĞƚŚŽĚĐ

Figure 3 Extracting API calling sequences㻭㻼㻵㻌㼏㼍㼘㼘㼟ƉƉůŝĐĂƚŝŽŶyϮW/ĂůůŝŶŐĂŶĚƌŽŝĚ͘ĐŽŶƚĞŶƚ͘/ŶƚĞŶƚ͘ĂŶĚƌŽŝĚ͘ĐŽŶƚĞŶƚ͘/ŶƚĞŶƚ ϭ^ĞƋƵĞŶĐĞ
ĂŶĚƌŽŝĚ͘ĂƉƉ͘ĐƚŝǀŝƚǇ͘ƐƚĂƌƚĐƚŝǀŝƚǇ ϮƉƉůŝĐĂƚŝŽŶ yϭDĞƚŚŽĚ ĂDĞƚŚŽĚď͘ŵϭ;Ϳ ͘ŵϮ;Ϳ ͘ŵϯ;Ϳ ͘ŵϭ;Ϳ ͘ŵϰ;Ϳ ͘ŵϮ;Ϳ

͘ŵϯ;Ϳ ͘ŵϯ;Ϳ

͘ŵϭ;Ϳ

䕿

䠉

䠉

䠉

䠉

䠉

䠉

䠉

͘ŵϮ;Ϳ

䠉

䕿

䠉

䠉

䠉

䠉

䠉

䠉

KDDKE͘ŵϮ;Ϳ

䠉

䠉

䠉

䠉

䠉

䕿

䠉

䠉

͘ŵϯ;Ϳ

䠉

䠉

䕿

䠉

䠉

䠉

䕿

䠉

͘ŵϭ;Ϳ
͘ŵϮ;Ϳ

͘ŵϮ;Ϳ

䠉

䕿

䠉

䠉

䠉

䠉

䠉

䠉

͘ŵϯ;Ϳ

䠉

䠉

䕿

䠉

䠉

䠉

䕿

䠉

͘ŵϭ;Ϳ

䠉

䠉

䠉

䕿

䠉

䠉

䠉

䠉

͘ŵϰ;Ϳ

䠉

䠉

䠉

䠉

䕿

䠉

䠉

䠉

͘ŵϯ;Ϳ

䠉

䠉

䠉

䠉

䠉

䠉

䠉

䕿

͘ŵϮ;Ϳ

䠉

䠉

䠉

䠉

䠉

䕿

䠉

䠉

search, we made a knowledge-base as following steps;͘ŵϮ;Ϳ
͘ŵϯ;Ϳ
͘ŵϭ;Ϳ
͘ŵϰ;Ϳ

Figure 4 Extractiong COMMON

Step A Collect source code of applications that have a speciﬁc feature, and extract API calling sequences that communicate with Android platform.
Step B Compare API calling sequences and get COMMON.

ƉƉůŝĐĂƚŝŽŶyϭƉƉůŝĐĂƚŝŽŶyϮǆƚƌĂĐƚ
W/ĐĂůůŝŶŐƐ

ǆƚƌĂĐƚ
W/ĐĂůůŝŶŐƐ

Step C Filter COMMON and then give a feature name toeach API calling sequence, then store them in a knowledge-͘ŵϭ;Ϳ
͘ŵϮ;Ϳ
͘ŵϯ;Ϳ
͘ŵϭ;Ϳ
͘ŵϰ;Ϳ

base．
Figure 3 shows an overview of extraction of API calling
sequences in Step B. API calling sequences are extracted ac-

W/ĂůůŝŶŐ^ĞƋƵĞŶĐĞƐ

cording to the following steps. First, we analyze source code͘ŵϭ;Ϳ
͘ŵϮ;Ϳ
͘ŵϮ;Ϳ
͘ŵϯ;Ϳ

ŽŵƉĂƌĞ

of application using MASU [12]. MASU is a plug-in platform
for metrics measurement and it extracts method calls in analysis. Next, we extract method call whose API call is uniqueto Android from the result of analysis. Android SDK con-/&&ͲyϭKDDKE

/&&ͲyϮ

ŚĞĐŬ

ŚĞĐŬ

ŚĞĐŬ

yϭ Ͳ&ĞĂƚƵƌĞ

ŽŵŵŽŶͲ&ĞĂƚƵƌĞ

yϮ Ͳ&ĞĂƚƵƌĞ

<ŶŽǁůĞĚŐĞͲďĂƐĞ

tains libraries from Java, libraries from Apache HttpComponents project, Android original API and so on. In thisresearch, we selected methods whose fully qualiﬁed names
Figure 5 Overview of comparison

start with “android.” or “com.google.android” as Android
API.
The result of API call extraction is a pair of an API call

we conduct a manual ﬁltering. The purpose of ﬁltering is toand a line number. We deﬁne this pair as API calling in-remove API calling sequences that are not explaining speciﬁcformation. Then, sort API calling information in order offeature. Criteria of ﬁltering are:•Control or get information using devices like camera•

Notiﬁcation

control ﬂow statements and the order of methods in a class.

•

Whether using Intent (call for another application)

Save API calling sequence with information of its owner ﬁle,After the ﬁltering, we assign a feature name to each API

line numbers. If multiple API callings appeared in the sameline, sort them in alphabetical order. We don’t care aboutclass, and method at the same time.
To get COMMON, we make a table like Figure 4, and ﬁndout common sequences of API calls which include two or
more API calls. Following information will be extracted as
COMMON.
••

API calling sequence
Appearance information (API calling information ofwhere the API calling sequence starts)
After the COMMON API calling sequences are extracted,

calling sequence. A pair of a feature name and an API calling
sequence is stored into a knowledge-base.
3. 2 The phase comparing two applications
Figre 5 shows the overview of comparison phase.

Ourmethod compares two applications as following steps:
Step 1 We analyze source code of two applications and extract API calling sequences. We extract only method calls of
API classes in the target platform, i.e., Android SDK classes.
Step 2 We compare two API calling sequences and iden-—3—ƉƉůŝĐĂƚŝŽŶ yϭ㻭㻼㻵㻌㼏㼍㼘㼘㼟DĞƚŚŽĚ ĂDĞƚŚŽĚď͘ŵϭ;Ϳ ͘ŵϮ;Ϳ ͘ŵϯ;Ϳ ͘ŵϭ;Ϳ ͘ŵϰ;Ϳ ͘ŵϮ;Ϳ

͘ŵϯ;Ϳ ͘ŵϯ;Ϳ

/&&Ͳyϭ^ĞůĞĐƚƚĂƌŐĞƚĂƉƉůŝĐĂƚŝŽŶƐ

͘ŵϮ;Ϳ

DĞƚŚŽĚĐƉƉůŝĐĂƚŝŽŶ yϮ͘ŵϭ;Ϳ

䕿

䠉

䠉

䠉

䠉

䠉

䠉

䠉

͘ŵϮ;Ϳ

䠉

䕿

䠉

䠉

䠉

䠉

䠉

䠉

͘ŵϮ;Ϳ

䠉

䠉

䠉

䠉

䠉

䕿

䠉

䠉

͘ŵϯ;Ϳ

䠉

䠉

䕿

䠉

䠉

䠉

䕿

䠉

͘ŵϮ;Ϳ

䠉

䕿

䠉

䠉

䠉

䠉

䠉

䠉

/&&ͲyϮ͘ŵϯ;Ϳ

䠉

䠉

䕿

䠉

䠉

䠉

䕿

䠉

͘ŵϭ;Ϳ

䠉

䠉

䠉

䕿

䠉

䠉

䠉

䠉

͘ŵϮ;Ϳ
͘ŵϯ;Ϳ

͘ŵϰ;Ϳ

䠉

䠉

䠉

䠉

䕿

䠉

䠉

䠉

͘ŵϯ;Ϳ

䠉

䠉

䠉

䠉

䠉

䠉

䠉

䕿

͘ŵϮ;Ϳ

䠉

䠉

䠉

䠉

䠉

䕿

䠉

䠉

͘ŵϯ;Ϳ
͘ŵϯ;Ϳ

Figure 7 Startup window͘ŵϯ;Ϳ
͘ŵϮ;Ϳ

ǆƚƌĂĐƚĞĚ
ŽŵŵŽŶͲĨĞĂƚƵƌĞ

ǆƚƌĂĐƚĞĚyϭͲĨĞĂƚƵƌĞ

ǆƚƌĂĐƚĞĚyϮͲĨĞĂƚƵƌĞ

&ĞĂƚƵƌĞŶĂŵĞĂŶĚ
W/ĐĂůůŝŶŐƐĞƋƵĞŶĐĞ

Figure 6 Extracting DIFF

^ĞůĞĐƚŽŶĞ

tify the COMMON sequences. The diﬀerences are regarded
as DIFF-X1 and DIFF-X2.

ƉƉĞĂƌĂŶĐĞŝŶĨŽƌŵĂƚŝŽŶ

Step 3 We translate API calling sequences in COMMON
and DIFFs into features according to a knowledge-base.
Procedure of extracting API callings and identifying COMMON are the same as the ﬁrst phase making a knowledgebase. To get DIFF, mark API calls which extracted as COM-

Figure 8 View for showing result of comparison

MON like Figure 6. After the COMMON sequences are identiﬁed, the rest (unmarked) calling sequences are regarded as
DIFFs. A long API calling sequence containing a COMMON sequence in the middle is divided to two API calling
sequences involved in a DIFF.
We check COMMON and DIFF with a knowledge-base; if
an API calling sequence is found in the knowledge-base, itscorresponding feature name is output. Here is an example.
A COMMON sequence is “ABCDE”. A knowledge-base contains three features: feature X and its API calling sequenceis “BC”, Feature Y and its API calling sequence is “CB”,
Feature Z and its API calling sequence is “AC”. Feature X isfound in the COMMON sequence, but feature Y and Z areused for making knowledge-base. The tool uses existing result of analysis, so check “Force analyze” if the user wants
to do analysis again. Click a label of the project name thenappear a dialog to select a target project. The tool starts
analysis and comparing when “start” button is clicked.
4. 2 Showing result of comparison
Figure 8 is a view for showing result of comparison. The
window has two parts of view and the upper part of thewindow is divided into three parts. X1-feature, Commonfeature, X2-feature are showed in the left, center and rightof the view respectively. One of the buttons is clicked, andthen details are showed in the lower part.

not found by our method.
The source code location of the calling sequence is also
recorded for further analysis.

4. A prototype tool

5. Case study
We performed two case studies to answer following research questions:
RQ1 Is an API calling sequence corresponding to a feature

We have developed a prototype tool implementing the proposed comparison approach.
A user of the tool should prepare a knowledge-base. The
tool analyzes two selected applications and shows featurenames corresponding to COMMON and DIFFs.
4. 1 Selecting targets
On booting up the tool, startup window appears (Figure7). Radio buttons are used for selecting whether the user
want to compare and show the result or only analyze and notof an application?
RQ2 Is our prototype tool able to clarify diﬀerences of two
applications?
RQ1 concerns the validity of a knowledge-base, and RQ2
is related to the comparison phase.
5. 1 Case study 1
To ensure that API calling sequence shows the feature ofapplication, we collect some application and extract API calling sequences. The steps of this case study are as follows:

to show the result of comparison. Analyze only mode can be—4—

Step 1 We extracted API calling sequences from each of
ﬁve applications.
Step 2 We saw feature names corresponding to each API
calling sequences with knowledge-base, and ensure that an
application is distinguished from the other application.
Figure 9 Comparison cycroid and maps-minus

As a target of case study, we used 11 applications labeled“Map” in Google Code as applications with feature “map”.
This case study uses 5 applications to compare and the rest
to make a knowledge-base. Table 1 and Table 2 shows a listof applications and its LOC.
We extracted 156 API calling sequences from 6 applications. We have assigned names to 23 API Calling sequences

Table 1 Application list for making a knowledge-baseand stored into a knowledge-base.

Application name

LOC #API calls

OpenGPSTracker

8122

1099

mapsforge

37326

1407

OSMandroid

3150

175

TripComputer

14487

825

shareyourdrive

2761

346

savage-router

1041

66

ple of diﬀerences of features in 5 applications, and Table 5

total

66797

3918

shows API calling sequences of some features. Some fea-

Table 3 shows the result of Step 1. 80% of features in
the knowledge-base was appeared in the targets. The resultshows that API calling sequences stored in the knowledgebase are involved in many applications.
Table 4 shows a part of the result of Step 2: an exam-tures are common to all ﬁve applications and some features
Table 2 Application list for comparison
ID

Application nameappeared only in few applications. The result also shows

LOC #API callsthat some detected diﬀerences did not correspond to map

App1 MapDroid

6387

1160

App2 cycroid

1278

761

App3 yozi

5348

159

(pop-up message)”. These features are associated with user

App4 maps-minus

1785

218

interface. Table 4 shows the features involved in 5 appli-features; for example, “Alert dialog”, “submenu” and “toast

App5 BigPlanetTw

4139

432

cations; our approach successfully distinguished applications

Total

18937

2730

using API calling sequences.
5. 2 Case study 2

Table 3 The number of features appeared in target applications#applications

0#features

1

5

8

2
3

3

4

0

5 Total6

1

23

The second case study is to investigate the detailed behavior of our tool. We reuse knowledge-base which we madein case study 1. Target applications are App2, cycroid, andTable 4 An example of diﬀerences of features in 5 applications
ID

App1 App2 App3 App4 App5

Alert Dialog✓

Get Latitudeand Longitude✓

Show Toast(pop-up message)✓

Set Latitudeand Longitude

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓
✓

Submenu

App4, maps-minus.
Figure 9 is the window of the tool displaying the result ofcomparing App 2 and App 4. Our prototype tool can showcommon features and features appeared only one or the otherapplication. Output of the tool is same as the result of casestudy 1.
5. 3 Discussion
The result of case study 1 shows that a particular API
calling sequence appears in two or more applications which

Table 5 Example of API calling sequences
Feature nameAPI calling sequences
android.widget.Toast.makeText
Show toast(pop-up message) android.widget.Toast.show

Get latitude and longitude

android.location.Location.setLatitude
android.location.Location.setLongitude
android.app.AlertDialog.Builder.android.app.AlertDialog.Builder
android.app.AlertDialog.Builder.setTitle
android.location.Location.getLatitude
android.location.Location.getLongitude

Submenu

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

Set latitude and longitude
Alert dialog—5—

has a similar feature. It follows from this fact that our idea is(No.21240002) and Grant-in-Aid for Exploratory Researchreasonable; we can detect the diﬀerences of features by using(No.23650015) .

API calling sequences.
The result of case study 2 shows that our tool can compare and distinguish features of two applications. Some features doubly detected because they have some patterns ofsequence (like pattern ABC and pattern ACB, both of them
implements the same feature).
Features found by the tool are considered that the application actually has them, but features which are not reported
are not always considered that the application doesn’t havethem. API calls which are not registered in a knowledge-baseare not found by the tool, so existing features may not be
detected if the knowledge-base contains not enough data.
In the case study, we cannot distinguish domain-speciﬁcfeatures from generic features, since we have used only “map”
applications to make a knowledge-base.

6. Related work
To compare source code of two similar programs, many
tools have developed. Unix diﬀ [7] is a line-based text comparison tool and widely used for comparing source code. Semantic diﬀ analysis [8] uses data ﬂow pairs for showing thesemantic eﬀects of the modiﬁcation. Comparing source codeis eﬀective for knowing diﬀerence of two versions of same
application. However, these methods are not helpful in comparing applications developed individually.
MUDABlue [5] and LACT [6] categorize software automat-

References[1] “Android Market,” http://market.android.com/.
[2] “Apple - iPhone - Learn about apps available on the App
Store,” http://www.apple.com/iphone/apps-for-iphone/.
[3] “SourceForge.net,” http://sourceforge.net/.
[4] “Google Code,” http://code.google.com/.
[5] S. Kawaguchi, P.K. Garg, M. Matsushita, and K. Inoue,“MUDABlue: An automatic categorization system for open
source repositories,” Proc. 11th Asia-Paciﬁc Softw. Eng.
Conf., pp.184–193, Busan, Korea, Nov. 2004.
[6] K. Tian, M. Revelle, and D. Poshyvanyk, “Using latent
dirichlet allocation for automatic categorization of software,” Mining Soft. Repositories, 2009. 6th IEEE Int. Working Conf. on, pp.163 -166, may 2009.
[7] E.W. Myers, “An O(ND) diﬀerence algorithm and its variations,” Algorithmica, vol.1, no.1, pp.251–266, March 1986.
[8] D. Jackson, and D. Ladd, “Semantic diﬀ: a tool for summarizing the eﬀects of modiﬁcations,” Softw. Maintenance,
1994. Proc., Int. Conf. on, pp.243 -252, sep 1994.
[9] T. Xie, and J. Pei, “MAPO: Mining API usages from open
source repositories,” Proc. of the 2006 Int. Workshop on
Mining Software repositories, pp.54–57, Shanghai,China,
2006.
[10] H. Tamada, K. Okamoto, M. Nakamura, A. Monden, andK. Matsumoto, “Design and evaluation of dynamic software
birthmarks based on api calls,” Information Science Technical Report NAIST-IS-TR2007011, ISSN 0919-9527, Graduate School of Information Science, Nara Institute of Scienceand Technology, May 2007.
[11] “Open Handset Alliance,” http://www.openhandsetalliance.
com/.
[12] A. Saito, G. Yamada, T. Miyake, H. Higo, S. Kusumoto,and K. Inoue, “MASU: Metrics assessment plugin-plutform
for software unit of multiple programming languages,” 2009
Int. Workshop on Empirical Softw. Eng. in Pract., 2009.

ically. These tools can classify applications with similar feature in same category, but we want to know detailed diﬀerences between applications in same category.

7. Conclusion
We have developed a prototype tool to compare two Android applications using API calling sequences extracted
from the applications. The tool extracts COMMON and
DIFF API calling sequences, and then translates them into
common features and unique features of the applications.
We performed a case study with Map applications. The
result ensures that API calling sequences are usable for comparing applications.
In the future work, we would like to support developers
to give an appropriate name to a sequence of API calls. In
addition, we would like to judge whether some API calling
sequences explains the same feature or not.

Acknowledgment
This research was supported by Japan Society for the Promotion of Science, Grant-in-Aid for Scientiﬁc Research (A)—6—