Network usage profiling for applications on the Android smart phone $(function(){PrimeFaces.cw("Tooltip","widget_formSmash_items_resultList_4_j_idt799_0_j_idt801",{id:"formSmash:items:resultList:4:j_idt799:0:j_idt801",widgetVar:"widget_formSmash_items_resultList_4_j_idt799_0_j_idt801",showEffect:"fade",hideEffect:"fade",target:"formSmash:items:resultList:4:j_idt799:0:fullText"});});

Network usage profiling for applications on the Android smart phone $(function(){PrimeFaces.cw("Tooltip","widget_formSmash_items_resultList_4_j_idt799_0_j_idt801",{id:"formSmash:items:resultList:4:j_idt799:0:j_idt801",widgetVar:"widget_formSmash_items_resultList_4_j_idt799_0_j_idt801",showEffect:"fade",hideEffect:"fade",target:"formSmash:items:resultList:4:j_idt799:0:fullText"});});
Institutionen för datavetenskap
Department of Computer and Information Science
Final Thesis
Network usage profiling for applications on the
Android smart phone
by
Jakob Egnell
LIU-IDA/LITH-EX-G—12/004—SE
2012-03-23
Linköpings universitet
SE-581 83 Linköping, Sweden
Linköpings universitet
581 83 Linköping
Linköpings universitet
Institutionen för datavetenskap
Final Thesis
Network usage profiling for applications on
the Android smart phone
by
Jakob Egnell
LIU-IDA/LITH-EX-G—12/004—SE
2012-03-23
Supervisor: Jordi Cucurull Juan , IDA, Linköpings Universitet
Examiner: Jordi Cucurull Juan, IDA, Linköpings Universitet
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
In English
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
© Jakob Egnell
Abstract
Android, a platform for smartphones and mobile devices, is becoming more and more present in the
market. Nevertheless, the battery runtime of smartphones is short and strongly influenced by the
network usage. Some proposals exist to reduce the energy consumption associated to the network
usage and increase the smartphone runtime. But for adjusting them for a real improvement it is
required to study the network utilisation triggered by the smartphone applications. With this
analysis the applications communication patterns can be obtained and used to predict the network
usage and the amount of data expected.
In order to gather network statistics of the running applications, a logger application is implemented
for the Android platform to log network statistics of running applications. The statistics are analysed
on a PC computer to obtain the applications' communication patterns. A number of applications are
selected, sorted by the rankings of downloads and type. A detailed analysis of the network usage is
presented. This analysis identifies some of their patterns, some application characteristics and
groups of applications from the determined network usage. The network usages for applications
with similar functionalities are compared and lessons learnt from the analysis are discussed. Finally,
some improvements for our logger application and analysis are discussed.
i
1. Introduction ........................................................................................................................................ 1
1.1 Background and motivation .......................................................................................................... 1
1.2 Purpose ......................................................................................................................................... 1
1.3 Method ......................................................................................................................................... 1
1.4 Structure ....................................................................................................................................... 2
1.5 Time plan....................................................................................................................................... 2
2. Background ......................................................................................................................................... 4
3. The network logger application .......................................................................................................... 6
3.1 Possibilities considered ................................................................................................................. 6
3.2 Application design......................................................................................................................... 7
3.2.1 Application structure ............................................................................................................. 7
3.2.2 Application parameters ......................................................................................................... 8
3.2.3 File format. ............................................................................................................................. 8
3.3 User interface................................................................................................................................ 8
3.4 Testing ......................................................................................................................................... 10
3.4.1 Possibilities considered ........................................................................................................ 10
3.4.2 Challenges ............................................................................................................................ 10
3.4.3 Methodology and result....................................................................................................... 10
4. Logging and visualisation of data ...................................................................................................... 12
4.1 Data logging ................................................................................................................................ 12
4.1.1 Network interface ................................................................................................................ 12
4.1.2 Parameters ........................................................................................................................... 12
4.1.3 Application states................................................................................................................. 13
4.2 Data Analysis ............................................................................................................................... 14
4.2.1 Possibilities considered ........................................................................................................ 14
4.2.2 Procedure ............................................................................................................................. 14
5. Application patterns.......................................................................................................................... 16
5.1 Application selection................................................................................................................... 16
5.2 Application patterns.................................................................................................................... 17
5.2.1 Skype .................................................................................................................................... 17
5.2.2 Google Maps ........................................................................................................................ 19
5.2.3 Spotify .................................................................................................................................. 20
5.2.4 Facebook messenger ........................................................................................................... 23
5.2.5 Global stock market ............................................................................................................. 24
ii
5.2.6 The Weather Channel .......................................................................................................... 25
5.2.7 Tv.nu..................................................................................................................................... 26
5.2.8 Background .......................................................................................................................... 27
5.3 Application pattern grouping ...................................................................................................... 28
5.4 Discussion.................................................................................................................................... 28
5.4.1 Lessons learnt ...................................................................................................................... 28
5.4.2 Complication ........................................................................................................................ 29
6. Conclusions ....................................................................................................................................... 30
7. References ........................................................................................................................................ 31
iii
1. Introduction
1.1 Background and motivation
Data transfers over 3G are more energy efficient when performed in burst than continuously over
time (Asplund et al [1]). With smart selection of what and when the data is transmitted it is possible
to reduce the energy used for the same amount of data. To take advantage of this property, Asplund
et al [1] propose the implementation of a middleware, placed on the user device, to control the
output data flow of the applications. But to tune the middleware and optimise the energy
consumed, a study of the network usage of many applications would be required. This data can then
be used to determine when the application will use the network interface and the amount of data
that is expected to be transferred.
1.2 Purpose
The purpose of this thesis is to analyse the communication patterns of popular applications on a
smart phone. A communication pattern is a representation of the most important characteristics of
the network usage for an application. A possible pattern can be represented as a graph with the
quantity of information transmitted. This is illustrated in Figure 1.1.
Figure 1.1: An example of how a pattern can look like
In order to study the communication patterns it is required to log and visualise the network usage.
The report also shows how the communication patterns were obtained and how the applications
can be grouped together. The grouping of the applications depends on how similar its
communication patterns are.
1.3 Method
The data transmitted by applications was obtained with an application specifically created for this
purpose. This application was implemented on the Android smart phone. The reason to use Android
was that it is a widespread platform and it is more and more present in the market [9]. The
1
application logs data about the network usage for a specific application. This data is stored in the
comma separated value (CSV) format, which is compatible with many existing applications. Then the
data was visualised and analysed using Microsoft Office Excel. Excel was chosen because it already
provided tools to visualise data in graphs.
1.4 Structure
The report is organised in six chapters. Chapter 2 contain the background for this thesis. It explains
what Android is and all the other important parts. Chapter 3 describes the application that was
developed to log the network traffic. Here it first describes the possibilities considered for this
application. Then it describes how the application works and its implementation. Chapter 4
describes how the analysis was performed and how our application was used to log data. Chapter 5
describes the result of the analysis of the applications. First it describes the different network
patterns found. Then how the different applications can be grouped. Lastly it describes some lessons
learnt and some unforeseen issues. Chapter 6 contains the conclusions for the thesis.
1.5 Time plan
Before the thesis was started a time plan was created. This contained all the different parts of the
work. Some changes were also made to this plan in the working process. The final time plan is
showed in table 1.1. The writing of the final report was also delayed for about one week. The reason
for this was that we wanted to analyse more applications. This turned out to be a good thing
because the analysis of applications became better. The thesis was also delayed because of some
unexpected result, while writing the report, that took longer time than expected to correct.
2
Table 1.1: The final time plan for the thesis
3
2. Background
The main contribution of this thesis is the analysis of the network usage of Smartphone applications.
As previously explained, an Android-based Smartphone has been used to gather the data required
for the analysis. Android is a framework that includes an operating system, middleware and key
applications. This is illustrated in Figure 2.1 redrawn from the Android Developer web site [2].
Figure 2.1: The major components of the Android operating system
The operating system is based on a Linux kernel. The kernel acts as an abstract layer between the
hardware and the rest of the software. The middleware consist of three parts: a set of C/C++
libraries, the Android runtime and an application framework. The C/C++ libraries are used by various
parts of the Android system. They can also be used by developers through the Android application
framework. The Android runtime provides most of the functionality available in the core libraries of
the Java programming language. It also contains a Dalvik virtual machine that is written to run
multiple virtual machines efficiently on an Android device. This is used so that every application can
run on its own process and its own instance of the virtual machine.
For developing applications on Android the Standard Development Kit (SDK) is used [3]. This
provides the necessary tools and the APIs for developing applications. The main programming
language used in Android is Java, although it is also possible to use C or C++ for optimising some
specific parts of the applications. In this case, the Android Native Development Kit (NDK) is used.
For security reasons Android runs each application isolated from each other. It also restricts the
access to different resources of the system. To do this a User ID is given to each [10] application in
the Android system. This is assigned to the application when it is installed. The User ID can be used
4
to identify an installed application. In addition, every installed application also needs to declare all
system resources required, otherwise their usage is denied. A feature can be the network, the phone
camera, the external memory and more.
Every Android application is composed of different application components [3]. There are four types
of components Activities, Services, Content providers and Broadcast receivers. An Activity is used for
representing a user interface on the phone screen. Every Activity represents a single screen. The
Service takes care of running operations in the background and has no user interface. Broadcast
receivers are used to respond to system-wide broadcast announcements. Content providers are
used to manage shared sets of data for an application. The Activity, Service and content provider
components are used in this thesis. To manage and communicate these components a message
called Intent is used. The Intent binds two components to each other and contains an action to
perform. It can also contain references to data.
The purpose of this thesis is to capture application network usage statistics. Android provides the
TrafficStats class for this purpose [4]. This class gives access to network statistics, which can be about
an application or the whole phone. TrafficStats can get data about the number of packets and bytes
transferred by an application. This data is an absolute value with the total amount of bytes and/or
packets since the phone is started. But data about packets requires Android version 3.1.
Furthermore, TrafficStats can also provide more specific data about the network usage.
5
3. The network logger application
This chapter presents the application developed to log the network usage of the smartphone
applications. First of all, the alternatives for solving this problem are introduced and the advantages
and disadvantages of them are presented. Then the application design is shown and its operation
explained. In addition, the user interface for the application is shown. And, finally the functional
tests performed to the application are discussed.
3.1 Possibilities considered
For logging the network usage three solutions have been considered. The first one is the existing
application Shark [5]. The second solution is the existing application SystemSens [7]. The third one is
to specifically create an application for logging the network statistics.



Shark: This application logs all packets transferred over the network. The packets are saved,
together with a timestamp, to the secondary storage. There are two advantages with this
solution. It is faster than developing our own application. And, it logs the maximum amount
of information possible, hence future logging requirements are always covered.
Nevertheless, this solution requires the phone to be rooted. A rooted phone allows the user
to attain privileged control over it. This allows the user to overcome limitations the
manufacturer has enforced, but it voids any warranty on it. Another disadvantage is that it is
not easy to distinguish what application transferred each packet. This would be very difficult
to implement and could possibly be needed to do partly manually every time.
SystemSens: This application logs most of the data about the phone and its installed
applications. It logs the memory usage, CPU usage, network usage and other statistics of
each application running in the phone. This data is periodically transmitted to a server, and
can be accessed via a web page on the server. The data is then displayed in graphs. The
advantage of this solution is that it has everything needed to do an analysis of an
application. It logs data about an application and it also visualises the data. Nevertheless, the
code for it is very large and complex. The server also needs to be installed and this could
possibly result in some problems and additional resources. In addition, the application does
not allow to select at what frequency it will log the data. Another disadvantage is that it
captures more information than the required (battery, storage, etc.).
Specifically created application: With this approach the application can implement the
exactly required functionality. So it would not be more advanced than needed and consume
unnecessary resources. This approach is easier because it allows to change and extend the
application if needed later. The disadvantage with this solution is that it takes time to be
implemented and tested. This could make the application less advanced than needed and
affect the quality of the result.
The third solution presented, create a specific application, has been selected. This allows to have a
lightweight application, that only provides the required functionality.
6
3.2 Application design
In this section the application design is explained. First the structure of the application is introduced.
Then the different parameters in the application are discussed. And, finally the alternatives
considered for the format in which the logged data is stored are discussed.
3.2.1 Application structure
The application is basically divided in two components. One Android activity and one Android service
[3]. Figure 3.1 illustrates the structure and components of the application.
Figure 3.1: The general structure of the applications components and the relations between them.


Activity component: This creates and sets up the user interface of the application. It controls
all the functionality for the different windows of the application. This activity also controls
the service component by sending Intent objects. These objects contain actions the service
have to perform. It also contains the necessary information for the different actions.
Service component: This acts as an interface between the activity component and the
logging mechanisms. It can either stop or start the logging process.
o Logging Thread: The thread loops until it is told to stop. In this loop the network
statistics are logged. This data is then saved in the same loop. After this the thread
sleeps until the next data is to be logged. This is repeated infinitely until the service
component tells it to stop.
o Data Saver: This saves the logged data to a file. The file format is dependent on this
component. So more file formats can be provided by replacing this component.
o Network data logger: This component gets the network statistics. It requires a User
ID that identifies the application monitored, and gets the data from the TrafficStats
class.
7
3.2.2 Application parameters
For logging the network statistics a number of parameters must be selected by the user. These
parameters are needed by the service to correctly log the network statistics.



File name: The name of the file that the logged statistics are saved to.
User ID: This is used to identify the application for which the network usage is logged.
Frequency: This determines how often the data is logged.
3.2.3 File format.
The data is saved according to a specific file format. This is important so that the data can be saved
in an efficient way and opened correctly. Two alternatives have been considered for the file format.
One is to create our own format. The other one is to use the comma separated value (CSV) format.
The first option has been discarded, since only our application could open the file. So it is better to
have a well-known file format.
Hence, the CSV format has been chosen since it can be opened by other applications. This format
stores the data to the file as characters separated by commas and rows. So every data sample is
saved on a different row (see Figure 3.2).
Figure 3.2: Four example rows in one of the data logging files
The order of the data is first the time the data was logged (Time), the number of bytes received
(bytes_rx) and transmitted (bytes_tx)by the application, the number of packets received (packets_rx)
and transmitted(packets_tx) by the application, the total number of bytes received (total_bytes_rx)
and transmitted (total_bytes_rx) by the phone. The time is saved in milliseconds and starts at zero
and is increased by the frequency value every row.
3.3 User interface
The user interface is composed of a main window and a control window. The main window lets the
user start the logging of data for an application and change parameters for the data logging. The
control window lets the user control and monitor the data logging process once it has started.
The main window (see Figure 3.3) contains the controls to select the application to monitor, to
choose the time to log, to choose the frequency and to choose the file name. An application can be
selected in two ways. The first one is to select it in the spinner (see Figure 3.4). The second one is to
search for it in the second field with the User ID of the application. Every time an application is
selected a file name is auto generated for it in the last field.
8
Figure 3.3: First window of our application
Figure 3.4: The spinner for selecting an application
The auto generated name consists of a combination of the last part of the package name for the
selected process and the date. When the start button is pressed the application starts the data
logging and shows the control window.
The control window (see Figure 3.5) shows the file name for the current data logging, the name of
the application being logged, the countdown timer for when the logging ends, and a control to stop
the logging. The countdown timer value can also be changed by inserting a new number into the text
field beneath the timer. When the end button is pressed the application returns to the main
window.
Figure 3.5: Second window of our application
9
3.4 Testing
This section is about the functional testing of our application. First it presents the methodologies
considered and explains why one is chosen. Next it presents some challenges with the testing. Finally
it explains how the tests have been performed and presents the results.
3.4.1 Possibilities considered
Three alternatives have been considered for the test of the application.



Implement a testing application: An application that transfers a fixed size of bytes at a
certain time and this is compared with the data captured by the logging application. While
this alternative allows for a fast test of the application, it requires investing some additional
time on development. In addition, even if the amount of data transferred by the application
has a fixed size, the operating system can still add more data to transfer it.
Shark for Root: This application can be used to log data at the same time as our data logger.
Then the data can be compared manually. With this alternative the testing can be started
right away. The Shark application has also been around for some time so the results
produced by it should be correct. The disadvantage with this alternative is that the actual
testing will take longer time. The reason for this is that Shark captures all the packets
transferred. So it can take longer time to correlate the data.
SystemSens: With this application the testing could be really fast, but it would take a long
time to start the testing. The reason for this is that the application has two parts and both
needs to be installed and setup. This application also logs data with the Trafficstats class. So
if this way is incorrect it would not been shown in the tests.
Shark is the alternative selected, because the testing can be started immediately and that the data
obtained by Shark is most likely to be correct.
3.4.2 Challenges
There have been three challenges using Shark.



Synchronisation of applications: This challenge is to start Shark and our application at the
same time. This is not completely solved. But the time difference between starting them has
been lowered to around 3 seconds. So when comparing the data this time difference had to
be remembered.
Filter packets: This challenge is that Shark logs packets that are not meant for this phone.
Because of this it is needed to filter the data with the IP of the phone. The IP had been given
when we signed in to the Wi-Fi network. But to be sure that this is correct we also used the
web site www.whatsmyip.org on the phone.
Ports used: It is needed to know which ports the application is using to identify it in the
Shark data. This is solved by looking at our applications data and finding the first transferred
packet. Then this is looked for in the Shark data to see what port is used to transfer it. If the
port is changed or if the application use more ports this is repeated.
3.4.3 Methodology and result
We tested two applications, Google search and the Weather Channel. The reason for choosing these
two applications is that they mostly only transfer data when the user interacts with them. So
10
because of this the applications are used at controlled intervals to make the testing easier. The
methodology is divided into 3 steps.
1) Get data: Both applications are started and are kept running for about 5 minutes.
2) Load data: The Shark data is visualised with the program Wireshark [6] for desktop
computers that can display the Shark logged data. And, the data from our application is
loaded with Microsoft Office Excel 2007.
3) Compare data: First filter the data in Wireshark with the phone's IP. Then compared the data
manually by checking the correlation of bytes transferred.
Figure 3.6: The Google Maps test result. Where each data point illustrated in the diagram represents 20ms of data.
Figure 3.7: The Weather Channel test result.
11
4. Logging and visualisation of data
This chapter explains how applications are analysed and what possibilities have been considered for
the analysis. First it discusses the different decisions made and how some parameters have been
chosen for the data logging. Then it discusses the possibilities considered for the analysis and how an
analysis is performed.
4.1 Data logging
This section presents the different parameters and decisions taken for the data logging. First the
tests performed for deciding the network interface and the reason for selecting one are explained.
Then the tests performed for deciding the logging parameters and the selections are explained.
Finally the different states of the monitored applications are discussed. All the tests in this section
are performed with Skype.
4.1.1 Network interface
When doing the data loggings a Wi-Fi connection is used instead of 3G. It is easier and cheaper to
access a Wi-Fi connection than a 3G connection. But it has been tested to make sure that the
applications used the network in the same way in both Wi-Fi and 3G. This is required to check that
both interfaces behaved equally, otherwise the data obtained would have been useless. This has
been performed by doing multiple data loggings with Wi-Fi and 3G.
The first test was Skype doing a voice call. No big differences were observed, but when the call is
ongoing it is more unstable with 3G. The second test was when Skype was idle. In this case the
patterns were also similar or the same in 3G and Wi-Fi. The occurrences of the patterns are not the
same in these tests. But the occurrences of the patterns in the different tests of either 3G or Wi-Fi
are also not the same. Because of this and that the voice call test is similar it has been decided to use
Wi-Fi.
4.1.2 Parameters
Two parameters can be adjusted: the time period between data samplings and the data logging
length. These parameters are adjusted to give good data from the logging.

Time period between data samplings: Five different tests have been performed to calibrate
the time period to get good, not too large, data. The parameter has been tested in the range
of 1 to 100 milliseconds. The five tests have been performed under the period 100, 50, 20,
10 and 5 milliseconds. In the 100 and 50 millisecond test there are mostly single spikes with
some periods of inactivity (see Figure 4.1). But there are some instances of multiple spikes
being transferred after each other. In the 20 and 10 millisecond tests the data looked more
divided into multiple spikes. But at this period it takes more time to visualise the data. An
example of another spike that is more divided is illustrated in Figure 4.2. In the 5 millisecond
test the data started to take a long time to visualise. So it has been decided to go with 20
milliseconds for the period between data samplings. The reason for this is that the precision
is enough. Also because we did not want too large data and the tests are only 10 minutes
long.
12

Length of the data logging: This parameter is different for every application and is decided
by doing a test for the application when it is analysed. First a 10 to 20 minute long logging is
performed. Then if this does not give enough data to completely identify the found possible
patterns the length is increased. This is repeated until the data is enough to identify all
patterns.
Figure 4.1: Example of the test with 50 milliseconds as frequency.
Figure 4.2: Example of a divided spike with 20 milliseconds as frequency.
4.1.3 Application states
An application does not use the network in the same way all the time. Because of this different
states are identified for every application. These states mostly depend on how the application is
used by the user. The most common states are standby states and active states. In the standby state
the application is not used. In the active state the application is used by the user in some way. This
can be sending text messages, doing a voice call or just browsing the application. But these examples
can also be divided into sub states.
Figure 4.3: The format of the file name explained with an example.
13
Because an application can be in different states the data files generated reflect them. The file
names consisted of three parts: The application name, the date of the data logging and the state
with some extra data. The extra data is special information about how the application has been used
and it is very application specific. An example of this is illustrated in Figure 4.3.
4.2 Data Analysis
This section talks about the analysis of the logged data. First the possibilities considered for the
analysis are discussed. Finally the methodology for the analysis is explained.
4.2.1 Possibilities considered
For the visualisation of data three possibilities have been considered.



SystemSens: Using this would mean that data would be transferred from our application to
the SystemSens server. SystemSens has a very good visualisation engine and it allows the
selection of the application and time interval to visualise. Nevertheless, the server is very
complex. So it can take time to install and learn how to transfer the logged data to the
server.
Creating our own application: This would do exactly what is needed and if more functionality
is needed later it could easily be added. Nevertheless, it would take a considerable amount
of time to create the application.
Microsoft Office Excel: Excel can open the file type used by the data logger, i.e. CSV. With
Excel the analysis can be started right away because Excel does not need any preliminary
setup, as it is required by SystemSens. It can also visualise the data with different diagram
types. Nevertheless, it has a maximum for how many rows it can handle.
Excel has been selected because of time restrictions and because of its wide functionality, although
the limitation in the maximum number of rows may increase the analysis time.
4.2.2 Procedure
The analysis of an application is divided into three steps.
1) Correctness of the data: This is a safety precaution to see that the data is correct. First the
whole data is visualised by creating multiple diagrams. The amount of bytes transferred by
the phone is then compared with the amount of bytes transferred by the application which
must be smaller than for the phone.
2) Search for general patterns: The whole data is inspected for a general pattern (see Figure
4.4). If it is found new diagrams are created that visualise the pattern or only parts of it.
Then these new diagrams are compared. This is done by comparing the time and amount of
bytes for the different spikes. It is also compared if the spikes are transmitted or received.
This pattern is then saved down with example diagrams and some text.
3) Search for specific patterns: The data is examined more precisely by creating zoomed
diagrams. This is done until a possible pattern is found. Then diagrams zoomed in on the
pattern are created (see Figure 4.5) and compared. The comparison is the same as for
general patterns but more precise. If a pattern is found the maximum and minimum time of
it being repeating is calculated. These patterns are saved like the general patterns with some
extra tables with precise information.
14
The same pattern can be found in both the search for general and specific patterns.
Figure 4.4: An example of a general pattern.
Figure 4.5: An example of a specific pattern.
15
5. Application patterns
This chapter presents the results obtained from the analysis of the applications. The selection
process of applications is explained, the result from the analysis is shown and the applications are
grouped after the analysis result.
5.1 Application selection
There are many different applications and this thesis cannot cope with all of them. So this section
explains how the different applications have been selected. It also talks about classifying applications
into categories, defining states for application and prioritisation of the applications.
1) Discovery: The applications have been selected in two ways. On one hand, some of the
applications were selected due to their extreme popularity, such as Spotify, Skype, Facebook
Messenger and Google Maps. The rest of the applications were obtained from the rankings
of the Android Market in our region. The applications were selected from the top hundred
most common free applications. When a possible application was found the detailed
description was studied to see if it used the network. Then the sub categories for the top
free applications were looked through. Two criterias were considered to select an
application: the network is used for the main functionality of the application and the
application is free. In addition to the Android Market, other web indexes have been checked
but the applications listed were similar. So this turned out to be a good way of seeing that
the selected applications are good.
2) Classification: Most applications were classified according to their functionality and network
type of use (see Table 5.1). Six application categories were defined: streaming,
communication, search engines, monitors, web sites and games.
3) Application states: Each application can be in different states depending on the functionality
or action that is providing or performing at each time.
4) Prioritisation: Because of time restrictions it was not possible to analyse all the applications,
hence they were classified into three different priority levels depending on four factors:
popularity, importance, diversity, comparable. Importance is determined by our estimation.
Diversity is wanted so that one application is selected from every classification category.
Comparable applications are also needed so some applications are selected from the same
categories.
Table 5.1: The different categories and all the considered applications organised into them.
16
The final applications selected for analysis are Skype, Google Map, Spotify, Facebook Messenger,
Global Stock Market, The Weather Channel and Tv.nu
5.2 Application patterns
In this section the analysis of each application selected is presented. First, the application is
described and the identified states introduced. Then, a detailed analysis of the network usage
patterns found is done. Each data point illustrated in the diagrams in this section represents 20ms of
data.
5.2.1 Skype
This is an application for communicating by text messages, voice calls and video calls. This can be
done with one person or multiple persons at the same time. To use Skype a user account is needed
and to be able to communicate with people they have to be in the account address list. The
application states identified for Skype are standby, transmission of text, reception of text, audio call
and video call. All these states except the video call state have been analysed.
5.2.1.1 Standby
In this state the application is waiting for incoming communications or user interaction. The analysis
of this state has been performed with one hour of usage traces. In the analysis of this data there are
many different non periodic data transfers lower than 150 bytes over tens of milliseconds. One
pattern has been identified. It starts by transmitting 300 to 500 bytes. After 150 to 250 milliseconds
later 4 bytes are received. The time between these transfers varies between 60 seconds and 10
minutes. In this state the average data transmitted are 36 B/s and the average data received are 40
B/s. But there are periods that are around 60 seconds long where nothing is transferred.
5.2.1.2 Voice call
This is the state in which the application is doing a voice call. For this a 30 minute long data logging
has been performed. During this period many calls are performed and one pattern has been found.
This pattern is divided into three parts (see Figure 5.1).
Figure 5.1: The different parts of a voice call.
17

Starting call: The starting call part has a beginning sub part and a transfer sub part (see
Figure 5.2). When starting a call 600 ± 100 bytes are transmitted (1). Then 700 to 1100 bytes
are received (2) depending on the time the user at the receiver's side takes to answer the
call. If a call is received the first transfer is received and the second is transmitted. Other
smaller chunks of data are also periodically transmitted and received after this. If the call is
not answered directly around 100 bytes are received every second (3). When the call is
answered the transfer of the call starts around 50 milliseconds later (4). This starts with a
lower rate of transfer and goes up to 4 kB/s in both directions. But this transfer rate also
depends on the quality and bandwidth of the network connection.
Figure 5.2: The Start part of a Skype voice call.


Call in progress: In this part 4 kB/s are transferred in both directions. But this transfer rate
also depends on the network connection. This part goes on until the user ends the call.
Ending call: When the call is ended (see Figure 5.3) the one that ends the call transmits 350
to 400 bytes. Then nothing is transferred for 0.3 to 0.7 seconds. Lastly data is transferred at
a rate of 80 bytes/second in both directions. This goes on for 8 to 10 seconds and ends
without any special data chunk.
Figure 5.3: The third and last part of a Skype voice call.
5.2.1.3 Text messaging
In this state the application is used to chat with text messages. For this 15 minutes of data loggings
have been performed.
18
Figure 5.4: Example transfer when a text message is received.
When a text message is received there is one pattern (see Figure 5.4). This always starts with the
reception of data that depends on the message size and is around 100 to 500 byte large. Then 20 to
60 bytes are transmitted, 50 to 300 bytes transmitted and 20 to 50 bytes received. The length of this
pattern varies between 10 and 100 milliseconds. In addition, there is always present the background
data transmission that exists in the standby state.
Figure 5.5: Example transfer when a text message is transmitted.
The transmission of a message has some similarities to the reception (see Figure 5.5). It starts with
transmitting data that depends on the message size. Then 50 to 100 bytes are received and 20 to 50
bytes are transmitted. The length of this operation varies between 10 and 150 milliseconds. When
transmitting a message with 2 characters 240 to 250 bytes are transmitted and 45 to 70 bytes
received in total. With the message size of 50 characters around 300 bytes are transmitted and the
same amount received.
5.2.2 Google Maps
Google Maps is an application that displays maps in different formats. It also has other
functionalities, but these have not been analysed. The different states identified for this application
are standby, map interaction and GPS interaction. All of these states have been analysed except the
GPS interaction.
5.2.2.1 Standby
For this state a 6 hour long data logging has been performed. The data logging is performed while
the application is displaying the satellite map without any user interaction. In this analysis one
pattern has been found (see Figure 5.6). This is the only pattern in the data and it has an optional
part behind it.
19
Figure 5.6: The pattern found for Google maps standby state without the optional part.
The data chunks in this pattern always have the same order and the length of this pattern varies
between 0.5 and 2.5 seconds. This pattern is repeated every 20 ± 10 minutes.



Part 1: The data chunks in this part always transfer the same amount of bytes. But the time
between them can vary probably due to the global network load. It starts with transmitting
55 bytes. Then it receives 968 bytes, transmits 80 bytes and receives 2122 bytes.
Part 2: This part starts transmitting 186 bytes and then 9 bytes are received. Then multiple
small data chunks are transmitted and received. The last data chunk transmitted varies from
tens to a few thousands of bytes.
Part 3: In this part a chunk of data of 445 ± 5 bytes is received.
The optional part of this pattern has the same part two and three. But part one is not exactly the
same. Instead it starts by transmitting 825 bytes or 1430 bytes. Then receiving 2122 bytes and
transmitting 80 bytes up to 20 milliseconds after. This optional part is from 3.5 up to 5 minutes after
the first pattern. The length of this part varies between 500 and 5.700 milliseconds.
5.2.2.2 Using map
Two different analyses have been performed: using a normal map and using a satellite picture map.
In the normal map analysis a 10 minute data logging has been performed. For this analysis no
specific pattern has been found, but some general information about the transferred data. Every
transfer always starts transmitting 30 to 3000 bytes of data. Then from hundreds to tens of
thousands of bytes are received (presumably downloading the cartography). The time from the first
transmitted data and then receiving data varies between 20 and 800 milliseconds. The time until
receiving all data varies between the same instantly and 280 milliseconds.
In the satellite analysis a 15 minute long data logging has been performed. The result is the same as
for the analysis with satellite maps. Data is still transmitted before received and the time differences
between the data chunks are similar to.
5.2.3 Spotify
Spotify is an application that streams music. It also allows the user to browse its media and get some
information about different bands. For this application three different states are identified: standby,
playing music and browsing.
20
5.2.3.1 Standby
For this 3 hour data loggings have been performed. In this analysis five patterns are found and the
average data transmitted are 7 B/s and the average data received are 10 to 40 B/s. Three of the
patterns are small transfers (see Figure 5.7) and two are large transfers.
Figure 5.7: Example of the small patterns in the Spotify standby analysis.
The sizes of the three small patterns are always the same.



First small pattern: This one always transmits and receives 40 bytes in the same frequency.
The pattern is repeated between every 9 and 30 seconds.
Second small pattern: It transmits 11 bytes then 11 bytes are received in the range of 20 to
120 milliseconds later. This pattern is repeated every 60 to 260 seconds.
Third small pattern: It only receives 11 bytes and is repeated between every 5 to 50 seconds.
The patterns for the large transfers are more complex. One transfers around 4.500 ± 500 bytes (see
Figure 5.8) and another that transfers more than 9.000 bytes.
Figure 5.8: The pattern for transferring 4k to 5k bytes in Spotify standby state.
The pattern that transferred 4.500 ± 500 bytes is at fastest repeated every 34 seconds. This is
divided into three parts to make it easier to explain.


Start part: The order of the data chunks is always the same. It starts by transmitting 39
bytes, then receiving 287 bytes up to 100 milliseconds later. This part ends by receiving 344
bytes. The length of this part varies between 140 and 200 milliseconds.
Middle part: It can start directly after the Start part or up to 340 milliseconds later by
receiving 1957 bytes. Then around 120 bytes are transmitted. Lastly 24 and then 27 bytes
are received. The length of this part varies between 20 and 60 milliseconds.
21

Ending part: It starts from 20 milliseconds up to 500 milliseconds after the middle part. The
order of the data chunks in this part varies a great deal. But it always transmits 195 bytes
and always receives 640 bytes in total. The length of this part varies between 250 and 950
milliseconds.
In addition, there is a pattern that varies and have not been completely analysed. This transfers
more than 9.000 bytes. It starts with transmitting 130 bytes, then receives 204 bytes, then
thousands up to tens of thousands of bytes are transferred. The length of this part varies between
1.500 and 1.700 milliseconds and it is repeated in periods in the order of minutes.
5.2.3.2 Playing music
For this analysis a 20 minute data logging has been performed. One pattern in addition to the traffic
associated to the stand-by state, has been found.
Figure 5.9: The general structure of the patterns found in the playing music analysis.
This pattern varies some but has a general structure (see Figure 5.9). It starts with transmitting
hundreds of bytes (Start). Then immediately after up to 600 milliseconds later tens of thousands to
hundreds of thousands of bytes are received (Transfer). There is nothing to indicate that the pattern
is finished and it can have gaps where nothing is received. These gaps are no longer than 1 second
and usually are around 0.5 seconds long. This pattern occurs several times when a song is played and
receives a maximum of 1.6 MB every time. The number of times it occurs depends on the song size.
5.2.3.3 Browsing
In this analysis the application is used to browse music and information about bands. For this a 20
minute long data logging has been performed. When doing this logging the application has been
used for a period of time then not used for a number of seconds. This has been repeated several
times.
No additional patterns have been found. But some general information about the transfers. These
transfers always start with transmitting from tens up to hundreds of bytes. After this, from 1 to 10
kB are received. The length of these transfers varies between 40 and 260 milliseconds. But it can also
have gaps that are 50 ± 30 milliseconds long.
22
5.2.4 Facebook messenger
This is an application that only implements the text chat part of Facebook. The user log in to their
Facebook account and can text chat with all their friends on Facebook. For this application three
states are identified: standby, message reception and message transmission.
5.2.4.1 Standby
For this one hour data loggings have been performed. In this analysis one pattern is found (see
Figure 5.10).
Table 5.10: Second pattern in the sending text analysis of Facebook messenger.
Most of the data chunks in this pattern transfer data that varies in size and two of the data chunks
are optional.


Start: First transmits 80 bytes. Then 4233 bytes are received between 180 and 300
milliseconds later.
End: Starts with an optional transfer that receives between 70 and 120 bytes. Then 23 or 27
bytes are transmitted 20 to 40 milliseconds later.
The length of this pattern varies between 1.200 and 1.700 milliseconds and is repeated every 10 to
20 minutes.
5.2.4.1 Transmitting text
For this analysis a 30 minutes data logging has been performed. In this one new pattern has been
found. When a text message is transmitted this pattern and the one in the standby analysis appears.
What pattern is used does not depend on the message text size it is more or less random. To test
this 20 messages have been transmitted that were 2 to 50 characters long. For the full analysis
around 80 messages have been transmitted.
The first pattern is illustrated in Figure 5.11. Most of the data chunks in this pattern transfer the
same amount of data. Only some of the larger data chunk can vary in size. This pattern starts with
transmitting 80 bytes (1). Then around 200 milliseconds later 924 bytes are received (2). The end
part of this pattern starts with receiving data around 1kB. Then 23 bytes are transmitted at the same
time or up to 80 milliseconds later. In 60% of the cases it has been observed the additional
transmission of 200 to 250 bytes during 80 to 200 milliseconds after the end part. Then there are
two smaller transfers and it ends by receiving 580 to 630 bytes (4). The length of this pattern
23
without the optional part varies between 1.300 and 1.650 milliseconds. With the optional part it
lasts around 3.000 milliseconds.
Figure 5.11: First pattern in the sending text analysis of Facebook messenger.
5.2.4.2 Receiving text
For this analysis a 7 minute data logging has been performed and around 20 messages have been
received. In this analysis the result is similar to the first pattern in the previous analysis. The only
difference is that in front of it there is an additional data chunk that varies between 350 and 700
bytes in size. The inter-arrival time of the pattern varies between 300 and 1.400 milliseconds.
5.2.5 Global stock market
This application keeps track of some of the global stock markets. It shows the current value of a
stock, how much it changed and a diagram of the change. Two states are identified: standby and
interaction.
5.2.5.1 Standby
For this analysis a 6 hour long data logging has been performed. The application was kept running
without any user interaction. No data was transferred during this time.
5.2.5.2 Interaction
For this analysis a 20 minute data logging has been performed. The application is used by looking
through the different stocks and reloading them. This has been performed around 80 times. In this
analysis some patterns are found. Of all the different patterns found only three of them are
analysed. These three patterns have some parts among them that are the same.
The first pattern occurs when a stock is loaded (see Figure 5.12). First, 512 bytes are transmitted.
Then 487 to 488 bytes are transmitted around the same time or up to 100 milliseconds after.
Between the start and end part 2 to 4.5 kB are received and 550 to 600 bytes transmitted. The
optional part receives 5 to 7 kilobytes in multiple data chunks. The length of this pattern varies
between 1.500 and 2.000 milliseconds.
24
Figure 5.12: First pattern in the Global stock market analysis.
The second pattern occurs when the list of stocks is loaded. It is similar to the first pattern but
without the optional part. First, 512 bytes are transmitted. Then 220 to 270 bytes are transmitted
around the same time or up to 100 milliseconds after. The end part of this pattern transmits 477
bytes. Then 180 to 300 milliseconds later receives 249 bytes. The length of this pattern varies
between 1.200 and 1.800 milliseconds.
The third pattern occurs when a stock is reloaded. This consists of the optional part of the first
pattern with an extra data chunk in the beginning. This is transmitted between 1.300 and 2.000
milliseconds before the optional part. The maximum size for the data chunk in the end of this
pattern is 10 kilobytes. The length of this pattern varies between 1.700 and 2.800 milliseconds.
5.2.6 The Weather Channel
This application is used to watch the weather for different locations. The current or future weather
can be checked for one or multiple locations. The application states identified are: standby and
interaction.
5.2.6.1 Standby
For this three different data loggings have been performed with different amounts of locations
selected. One of them has one location and the other have five locations. The longest of them is 3
hours long. No conclusive data exchanged has been found in any of the cases examined. In all the
data there are only three transfers that together transfer around 30 kB.
5.2.6.2 Interaction
A 15 minute data logging has been performed with around 100 interactions. This has been done by
adding and removing locations and checking the weather for the different locations. The two most
frequent patterns are analysed.
The first pattern (see Figure 5.13) starts with transmitting between 440 and 450 bytes. Then 990 or
995 bytes are received between 140 and 220 milliseconds later. The transfers in the middle part of
the pattern can have different orders. But the end part is the same. It starts transmitting 565 bytes.
Then between 200 and 300 milliseconds later 547 bytes are received. The length of this pattern
varies between 1.200 and 1.900 milliseconds and occurs when the weather is checked for a location.
25
Figure 5.13: The first pattern in the using analysis of the weather channel application.
The other pattern (see Figure 5.14) lasts between 1.000 and 1.600 milliseconds. In the start part 170
to 200 bytes are transmitted. Then 610 to 640 bytes are received and between 500 and 1.000
milliseconds after the transfer part begins. In this part 181 bytes are transmitted. Then a larger
transfer is received that varies in size between 15.500 and 16.000 bytes. This pattern occurs when
the application is started and is repeated between every 30 to 80 seconds, but it could depend on a
user action.
The Figure 5.14: The second pattern in the standby analysis.
5.2.7 Tv.nu
This application is used to display the television tableau. It allows the user to select different
categories to show, such as channels, movies and sports. It can also create reminders for TV
programs. Two states have been identified: standby and interaction state. But nothing is transferred
in the standby state.
5.2.7.1 Using
A 13 minute data logging has been performed. Three patterns are found. These patterns are
produced when the application is used to look at tableaus and specific program information.
The first pattern is illustrated in Figure 5.15. This pattern occurs when the different categories are
loaded. It starts with a handshake that consists of some small transfers. Then up to 40 milliseconds
later there is an exchange of information. Around 8096 bytes of data are received and 185 bytes of
data are transmitted. Then it ends transferring a burst of six data chunks. Up to three different
26
variants of this pattern have been observed with a slightly different amount bytes transmitted. The
length varies between 650 and 1.300 milliseconds.
Figure 5.15: The first pattern in the using state analysis of the tv.nu application.
The second pattern (see Figure 5.16) occurs when a detailed description of a program is loaded. It
consists of three different parts. All of these parts have the same structure and start by transmitting
a chunk of data and then receiving one. The first data chunk transmitted has the size 519 bytes (1)
and the last received data chunk has a size around 1 kilobyte (2). The length of this pattern varies
between 200 and 400 milliseconds.
Figure 5.16: The second pattern in the using analysis of the tv.nu application.
The third pattern occurs when a channels tableau is loaded and is very short. It always starts with
transmitting 517 or 519 bytes of data. Then in the same frequency or up to 20 milliseconds after
thousands to tens of thousands of data are received. The length of this pattern varies between 20
and 140 milliseconds.
5.2.8 Background
An analysis for the whole phone when no user applications are running has also been performed.
There are no states identified and only one analysis is performed during 30 minute. Two main
patterns have been found. One is just a handshake with a transmission and reception of data, and
the other is just a transmission of data. In Figure 5.17 an example of this possible pattern is
illustrated.
This possible pattern starts with some smaller data transferred. Then around 2.000 bytes are
received. After this data of the size hundreds to thousands of bytes are transmitted and received
multiple times. But other than that no specific pattern is found.
27
Figure 5.17: An example of a possible pattern in the ground analysis.
5.3 Application pattern grouping
Many of the analysed applications had some similarities, although not for all its different states. The
similarities found are more general characteristics of how the applications use the network.
For example, the chat of Skype and Facebook Messenger has similar behaviour when a message is
sent or received. In both cases the data transmission is initiated on the side that sends the message.
Nevertheless in the Facebook Messenger application the amount of data transmitted is quite stable,
while in Skype can be very different. The quantity of bytes transferred with Facebook is around 9
kilobytes and with Skype around 1 kilobyte.
The most similar applications are Tv.nu, Global Stock Market and the Weather Channel. No data, or a
small amount of data, is transferred in the standby state. Most of the data transferences start
because of a user interaction. The patterns found for these applications do not have any exact
similarities, but they are often long and transmit and receive data multiple times. Google Maps can
also be included in this category, but as opposed to the previous applications, it transfers data in the
standby state. In these applications the data is only transferred when they are used.
Spotify and Skype also have some similarities, but only in the standby state. Both applications
periodically transfer small amounts of data and, less frequently, large amounts of data. The small
data is always transferred in a short period of time and usually data is both transmitted and
received. The larger data patterns are longer and more complex.
5.4 Discussion
This section discusses the lessons learnt and complications that have occurred during the capture
and analysis of the data presented in this chapter.
5.4.1 Lessons learnt
There were many possible patterns that are to complex and vary too much to identify. These
patterns are in most applications and the same application can also have very simple patterns. The
complexion of the patterns is more dependent on the different user actions in an application.
All application we have analysed has very different patterns compared to each other. Even if the
applications have the same functionality or provide the same service there patterns can be very
28
different to each other. An example of this is the text chat of Skype and Facebook Messenger and for
these the amount of bytes transferred is also very different.
5.4.2 Complication
After doing the analysis some unreasonable numbers for Skype were detected. These were that
when doing a voice call too much data is transferred than what is normal.
The reason for this is that our application use the Android interface to get statistics, which cannot
distinguish between different interfaces. So statistics are captured for more than just the wireless
interface. The extra interface that is captured is the application's communication with the Android
service Audio Flinger. This is a service that provides audio facilities to applications.
The applications suspected to be affected by this were Skype and Spotify because they use the
service. But it was later showed that only Skype was affected.
The problem was solved by doing another analysis of the applications with another way of logging
the statistics. In this the data was logged with the Shark application while a firewall was blocking the
rest of the phone. Then this data was loaded in Wireshark, filtered in Wireshark, saved down to a
new file and analysed in Excel.
This problem can also be solved by some other solutions. Our program could be extended to also log
network transfers by Audio Flinger then subtract this from our programs data. We tried to do this,
but we were not able to find where the data was transferred. It could also be solved if the
TrafficStats class was improved.
29
6. Conclusions
The goal of the thesis was to analyse the network usage of smartphone applications and obtain
network usage patterns. An application has been specifically developed and used to log the network
utilisation of many popular smartphone applications. The study shows that it is possible to find and
identify different network usage patterns. The applications may transfer data as a consequence of
user interaction or also when they are in stand-by or background mode. The applications that
transfer data because of user interaction starts by transmitting and ends by receiving when data is
transferred. The applications that transfer data in background have patterns that are often repeated
periodically with a given time interval. The patterns found and their characteristics help to
determine when the application will use the network interface. The results also show that some of
the analysed applications use the network in a non efficient way. Facebook Messenger transfer very
large data when a text message is transferred, around 9 times more than the text messaging facility
of Skype for example. There are also applications that are inefficient in the standby state and have
most transfers spread out instead of grouped together. This information is important to optimise the
communication systems and to create future solutions to save up energy, such as middleware
software solutions proposed in the literature. The information would then determine when data can
be sent in burst instead of continuously and other solutions to lower the energy consumption.
During the development of this thesis we have determined some future enhancements that can be
added to the analysis process. Our application could be improved to monitor many applications at
the same time. This would lower the amount of time needed to do the loggings. It can also be
improved to select what interfaces to log simplifying the isolation of the correct data to be logged.
The results can also be improved by analysing more applications and doing the analyses in more
detail because not all of our analyses were complete. It can also be improved by doing a complete
analysis of the smartphones system. The manual analysis of the network statistics takes long time to
do and this can be improved by automatising parts or the whole process.
30
7. References
[1]
M. Asplund, A. Thomasson, E. J. Vergara, and S. Nadjm-Tehrani, Software-related Energy
Footprint of a Wireless Broadband Module, in The 9th ACM International Symposium on
Mobility Management and Wireless Access (MobiWac), ACM, November 2011.
http://www.ida.liu.se/~rtslab/publications/2011/mobiwac_11_energy.pdf
[2]
Android developer website about basics of Android,
http://developer.android.com/guide/basics/what-is-android.html (accessed on December
2011).
[3] Android web page about Android fundamentals,
http://developer.android.com/guide/topics/fundamentals.html (accessed on December
2011).
[4] TrafficsStats reference web site
http://developer.android.com/reference/android/net/TrafficStats.html (accessed on December
2011).
[5] Android market web page for Shark for root application,
https://market.android.com/details?id=lv.n3o.shark (accessed on December 2011).
[6] Official web page for Wireshark with information about the program
http://www.wireshark.org/about.html (accessed on December 2011).
[7] SystemSens Official web site
http://systemsens.cens.ucla.edu/service/viz/login/?next=/service/media/SystemSens/
(accessed on December 2011).
[8] CountDownTimer reference web site
http://developer.android.com/reference/android/os/CountDownTimer.html (accessed on
December 2011).
[9] IDC: Press Release http://www.idc.com/getdoc.jsp?containerId=prUS22871611 (accessed on
December 2011)
[10] Android web page about Security and Permissions
http://developer.android.com/guide/topics/security/security.html (accessed on December
2011)
[11] Web page about Android Audio Subsystems
http://www.netmite.com/android/mydroid/development/pdk/docs/audio_sub_system.html
(accessed on February 2012)
31
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertisement