Upload
sahil-batra
View
219
Download
0
Embed Size (px)
Citation preview
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 1/32
Android Operating System
Submitted in partial fulfillment of the requirement
for the award of the degree of
Bachelor of Technology
In
Computer Science
Under the guidance of Submitted By
NAME: Mrs. Asha Pahuja NAME: Mr. Gaurav Kumar
DESIGNATION: Lecturer Enroll. No: 1391332708
HMR Institute Of Information Technology And Management
Guru Gobind Singh Indraprastha University
(2008-2012)
i
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 2/32
CERTIFICATE
This is to certify that the dissertation project report (ETCS-455) entitled ― ANDROID
OS‖ done by Mr. Gaurav Kumar, Roll No. 1391332708 is an authentic work carried
out by his at HMR INSTITUTE OF TECHNOLOGY & MANAGEMENT under my
guidance. The matter embodied in this report has not been submitted earlier for the
award of any degree to the best of my knowledge and belief.
Date: 4-10-2011 Signature of the Guide
NAME: Mrs. Asha Pahuja
Designation: Lecturer
ii
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 3/32
ACKNOWLEDGEMENT
I would like to thank my Guide, Mr. Gaurav Kumar , for his timely and valuable
guidance and direction for this work. It has been a great learning experience workingunder his supervision. His vast domain knowledge helped me to have deep insight on
the subject. His suggestion and recommendations from time to time helped me
immensely. He continuously encouraged me while doing the project work and
throughout the preparation of the report.
I would also like to thank the committee members and other staff members of the
University for their Support. Further I would like to thank my friends and family
member for providing unrelenting encouragement throughout the preparation of the
report.
Date: 4-10-2011 NAME:Gaurav Kumar
COURSE:B.Tech (CSE/7TH
sem)
ENROLL. No. : 1391332708
EMAIL ID:[email protected]
iii
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 4/32
ABSTRACT
Android is a software stack for mobile devices that includes an operating System,
middleware and key applications. Android is a software platform and operating system
for mobile devices based on the Linux operating system and developed by Google andthe Open Handset Alliance. It allows developers to write managed code in a Java-like
language that utilizes Google-developed Java libraries, but does not support programs
developed in native code.
The unveiling of the Android platform on 5 November 2007 was announced with the
founding of the Open Handset Alliance, a consortium of 34 hardware, software and
telecom companies devoted to advancing open standards for mobile devices. When
released in 2008, most of the Android platform will be made available under theApache
free-software and open-source license.
Open - Android allows to access core mobile device functionality through standard API
calls. All applications are equal - Android does not differentiate between the phone's
basic and third-party applications -- even the dialer or home screen can be replaced.
Breaking down boundaries - Combine information from the web with data on the phone
-- such as contacts or geographic location -- to create new user experiences. Fast and
easy development - The SDK contains what need to build and run Android
applications, including a true device emulator and advanced debugging tools.
iv
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 5/32
Table of Contents
Chapter Page No.
Title Page………………………………...…………...……………....………………..i
Certificate……………………………………………………………………...…........ii
Acknowledgement………………………………….……………………………........iii
Abstract…………………………………………….………………………………….iv
Table of Contents………………………………………………………………………v
List of Tables…...………………………………….………………………………….vi
List of Figure…………………………………………..………….…….....................vii
List of Symbol..........……………………………………...……………………........viii
1. Introduction……………………………………………………………………1
1.1 The Birth Of Android………………………….………………………….1
2. Features of Android OS……………...…………………………………………….3
3. Android Architecture………………………………………………………………4
4. Application Framework……………………………………………………………5
5. Libraries…………………………………………………………………………… 6
6. Android Runtime……………………….………………………………………… 7
7. Linux Kernel…………………………….………………………………………...8
8. Architecture for Secure Data storage…………………………………………… ..9
9. Execution Environment…………………………………………………………...12
9. The Dalvik Virtual Machine…………………….………………………………...15
10. Lifecycle of an Android Application………………………………………… ....1611. Security and permissions in Android………………..………………………..…19
12. Development Tools………………………………………………………… ..….20
13. Conclusion…………………………………………………………………..…..23
14. References………………….…………………………………………………..……24
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 6/32
List Of Tables
1. Usage share of the different versions of Android by September 2, 2011
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 7/32
vi
List of Figures
1. Architecture Of Android OS2. Conversion from .java to .dex file
3. Android and Secure Local Data Storage
4. Regular Java Execution Process
5. Android Execution Environment
vii
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 8/32
List Of Symbols
1. SDK - Software Development Kit
2. APIs - Application Program Interfaces
3. GUI - Graphical User Interface
4. OHA - Open Handset Alliance
5. GPS – Global Positioning system
6. LRU – Last Recently Used
7. MHTML – Mobile HTML
8. QoS – Quality of Service
9. WAP – Web Application Protocol
10. CSD – Circuit Switched Data
11. OTA – Over-the-Air
viii
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 9/32
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 10/32
Google has unveiled at least three prototypes for Android, at the Mobile World
Congress on February 12, 2008. One prototype at the ARM booth displayed several
basic Google applications. A 'd-pad' control zooming of items in the dock with a
relatively quick response.
~2~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 11/32
2. Features of Android OS
1. Application framework - enabling reuse and replacement of components
2. Dalvik virtual machine- optimized for mobile devices
3. Integrated browser - based on the open source WebKit engine
4. Optimized graphics- powered by a custom 2D graphics library; 3D graphics based on
the OpenGL ES 1.0 specification (hardware acceleration optional)
5. SQLite- for structured data storage
6. Media support - for common audio, video, and still image formats (MPEG4, H.264,
MP3, AAC, AMR, JPG, PNG, GIF)
7. GSM Telephony- (hardware dependent)
8. Bluetooth, EDGE, 3G, and WiFi- (hardware dependent)
9. Camera, GPS, compass, and accelerometer - (hardware dependent)
10. Rich development environment - including a device emulator, tools for debugging,
memory and performance profiling, and a plugin for the Eclipse IDE
Usage share of the different versions, by September 2, 2011 :
Distribution API level %3.x.x Honeycomb 11-13 1.4%
2.3.x Gingerbread 9-10 31.3%2.2 Froyo 8 51.2%2.1 Éclair 7 13.3%
1.6 Donut 4 1.8%1.5 Cupcake 3 1.0%
~3~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 12/32
3. Android Architecture
The following diagram shows the major components of Android
~4~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 13/32
4. Application Framework
Developers have full access to the same framework APIs used by the core applications.
The application architecture is designed to simplify the reuse of components; any
application can publish its capabilities and any other application may then make use of
those capabilities (subject to security constraints enforced by the framework). This same
mechanism allows components to be replaced by the user.
Underlying all applications is a set of services and systems, including:
1. A rich and extensible set of Views that can be used to build an application,
including lists, grids, text boxes, buttons, and even an embeddable web browser
2. Content Providers that enable applications to access data from other
applications (such as Contacts), or to share their own data
3. A Resource Manager, providing access to non-code resources such as localized
strings, graphics, and lat files
4. A Notification Manager that enables all applications to display custom alerts in
the status bar
5. An Activity Manager that manages the life cycle of applications and provides a
common navigation backstack
~5~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 14/32
5. Libraries
Android includes a set of C/C++ libraries used by various components of the Android
system. These capabilities are exposed to developers through the Android application
framework. Some of the core libraries are listed below:
1. System C library - a BSD-derived implementation of the standard C system
library (libc), tuned for embedded Linux-based devices
2. Media Libraries - based on PacketVideo's Open CORE; the libraries support
playback and recording of many popular audio and video formats, as well as
static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
3. Surface Manager - manages access to the display subsystem and seamlessly
composites 2D and 3D graphic layers from multiple applications4. LibWebCore - a modern web browser engine which powers both the Android
browser and an embeddable web view
5. SGL - the underlying 2D graphics engine
6. 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries
use either hardware 3D acceleration (where available) or the included, highly
optimized 3D software rasterizer
7. Free Type - bitmap and vector font rendering
SQLite - a powerful and lightweight relational database engine available to all
applications.
~6~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 15/32
6. Android Runtime
Android includes a set of core libraries that provides most of the functionality
available in the core libraries of the Java programming language. Every Android
application runs in its own process, with its own instance of the Dalvik virtualmachine. Dalvik has been written so that a device can run multiple VMs efficiently.
The Dalvik VM executes files in the Dalvik Executable (.dex) format which is
optimized for minimal memory footprint. The VM is register-based, and runs
classes compiled by a Java language compiler that have been transformed into the
.dex format by the included "dx" tool. The Dalvik VM relies on the Linux kernel
for underlying functionality such as threading and low-level memory management.
At the same level there is Android Runtime, where the main component Dalvik
Virtual Machine is located. It was designed specifically for Android running in limited
environment, where the limited battery, CPU, memory and data storage are the main
issues. Android gives an integrated tool ―dx‖, which converts generated byte code from
.jar to .dex file, after this byte code becomes much more efficient to run on the small
processors.
Figure 2: Conversion from .java to .dex file
As the result, it is possible to have multiple instances of Dalvik virtual machine
running on the single device at the same time. The Core libraries are written in Java
language and contains of the collection classes, the utilities, IO and other tools.
~7~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 16/32
7. Linux Kernel
Android Architecture is based on Linux 2.6 kernel. It helps to manage security, memory
management, process management, network stack and other important issues.Therefore, the user should bring Linux in his mobile device as the main operating
system and install all the drivers required in order to run it. Android provides the
support for the Qualcomm MSM7K chipset family. For instance, the current kernel tree
supports Qualcomm MSM 7200A chipsets, but in the second half of 2008 we should
see mobile devices with stable version Qualcomm MSM 7200, which includes major
features:
1. WCDMA/HSUPA and EGPRS network support
2. Bluetooth 1.2 and Wi-Fi support
3. Digital audio support for mp3 and other formats
4. Support for Linux and other third-party operating systems
5. Java hardware acceleration and support for Java applications
6. Qcamera up to 6.0 megapixels
7. gpsOne – solution for GPS
~8~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 17/32
8. Architecture for Secure Data Storage
Figure 3 Android and Secure Local Data StorageSecure data storage solution that could potentially be deployed on Android. It is
as shown in the figure. However, many shortcomings of the design have been
addressed. Additional security highlights will be presented at the end of the section.
Using figure 3, we have the following workflow:
1. The user enters his credentials on the handset.
2. The credentials are not sent to the SSO service over the network. Instead, the
credentials are used as the passphrase to decrypt the local public/private key pair
of the user. We define the public/private key pair to be of type RSA and of at
least 4096 bits in size. Already we gain the advantage that the user’s password is
not sent over the network
~9~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 18/32
3. The private key is used to decrypt the symmetric cipher key. The symmetric
cipher key is used to encrypt/decrypt any locally cached data. A strong
symmetric cipher like 3DES is used.
4. All data found in the local cache is encrypted with the symmetric cipher key
defined in step #3.
5. If the requested data is not locally cached or expired. We must communicate with
the SSO service again to be able to receive fresh data from the Restful web
services. However, unlike the architecture presented in section 2 of this
document, we login to the SSO server using a hostile challenge based on the
private key of the user. As such, we login with the SSO system using
public/private key infrastructure. The user name and the password are never sent
over the network. The SSO system can identify the user based on this challengeand returns a 496 bit alpha numeric token.
6. The tokens generated by the SSO system are set to automatically expire after a
given period of time.
7. On reception of the SSO token. The Android background application can now
communicate with any Restful web services that adhere to the same SSO
federation. Public/private key infrastructure is once again used to setup a secure
communication channel between the phone and the server. The certificates of the
servers that host the web services are procured from the same certificate authority
that shipped with the phone.
8. On reception of a request, the SSO token is extracted from the request. The web
service calls upon the SSO system to authorize the operation.
9. On reception of the data, the symmetric cipher described in bullet #3 above is
used to encrypt the data before it reaches any local persistent storehouse.
10. Data is returned to the user facing application.
Additional security notes:
1. The public/private key pair of the user is generated directly on the
handset at install time. As such, the private key has never left the
~10~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 19/32
phone nor has it been transferred over any network.
2. The certificate of the user must at least be registered once in the SSO
application. This could be done at install time of the handset application.
3. ―Man-in-the-middle‖38 attacks are not possible since the application is
deployed with the CA certificate of the company that will be hosting the web services.
4. If the device is lost, all the locally cached data is completely unreadable. The
symmetric key that encrypted this data is also unreadable. The public/private keys that
are central to the security architecture are protected by a passphrase.
5. The passphrase is the weakest link in the chain. If the user enters an overly
simple password, access could be gained to the private key and hence the locally cached
data.
6. That being said, it would be possible to further extend this architecture tostore the encrypted symmetric key on the server. This way, even if the passphrase of the
private key is compromised, the locally cached data still cannot be accessed. This is
because the encrypted strong symmetric cipher key is stored on the server. By the time
the passphrase has been cracked, there has been ample time to report the stolen phone
and revoke this key from this user account on the server. Furthermore, under this
scheme, the key stored on the server is still encrypted. Even if this key is intercepted in
transit it is useless without the user’s private key.
7. It is also possible to enforce a strong password policy directly from the
handset application.
8. Even if this design is significantly more secure than the previous iteration, to
the user, the experience is the same. The user must enter a username and password to
prove his identify.
9. We could augment the architecture in yet another direction. The local caching
system could also require an SSO token and subsequently request authorization from an
SSO system. Such a design would prevent terminated employees, i.e., an Individual
who already knows what the local credentials are, from accessing the locally cached
data.
~11~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 20/32
9. Execution Environment
Figure 4 Regular Java Execution Process
~12~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 21/32
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 22/32
Figures 4 and 5 represent the regular Java and Android execution paths respectively. It
is interesting to note here however is that the Android compilers do not operate on Java
language code. Instead, the Android translators work on the resulting Java bytecode
emitted from a traditional Java compiler.
As such, it is possible to reuse existing Java libraries, even if the original source
code is not available. Such libraries must meet stringent requirements however, they
need to:
1. adhere to the Java SE 5 dialect
2. not use any Java classes or packages found in Java SE 5 not found in the
Android platform
3. not use any packages or classes specific to the Sun Microsystems platform
4. still behave in a predictable manner under the Apache Harmony Javaenvironment
Following these guidelines, it’s possible to integrate existing Java source code,
packages and libraries piecemeal. Special care will be needed in the integration phase of
such code but the potential savings offered by such integration far outweighs the cost of
rewriting well-coded, well-documented and well-tested libraries ready for use.
Furthermore, it is expected that has Apache Harmony matures, more and more
compatibility issues will be resolved further increasing the pool of available Java code
that will be able to execute unmodified under the Android platform.
~14~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 23/32
10. The Dalvik Virtual Machine
The Dalvik virtual machine is an interpreter only machine optimized for use on
low powered, low memory devices like phones. Notably, Dalvik does not make use of just in time (JIT) Compilation to improve the performance of an application at runtime.
Furthermore, Dalvik is not a Java virtual machine. This is because Dalvik is unable to
read Java bytecode34, instead it uses its own bytecode format called ―dex‖. Google
claims this format allows battery power to be better-conserved at all different stages of
execution of an application. This means that standard Java SE applications and libraries
cannot be used directly on the Android Dalvik virtual machine.
Dalvik however stands at the center of the Android value proposition. Its low
electrical power consumption, rich libraries, and unified, non-fragmented application
programming interfaces make it stand out, or so Google hopes, over the fragmented
ecosystem that is Java ME35 today.
Furthermore, since Dalvik uses the Java programming language but not the Java
execution environment (JVM), Google is free to develop Android without the need to
license or obtain certification from Sun Microsystems Inc, the legal owner of the Java
trademark and brands.
~15~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 24/32
11. Lifecycle of an Android Application
In most cases, every Android application runs in its own Linux process. This
process is created for the application when some of its code needs to be run, and will
remain running until it is no longer needed and the system needs to reclaim its memory
for use by other applications.
An important and unusual feature of Android is that an application process's
lifetime is not directly controlled by the application itself. Instead, it is determined by
the system through a combination of the parts of the application that the system knows
are running, how important these things are to the user, and how much overall memory
is available in the system.
It is important that application developers understand how different application
components (in particular Activity, Service, and IntentReceiver) impact the lifetime of
the application's process. Not using these components correctly can result in the system
killing the application's process while it is doing important work.
A common example of a process life-cycle bug is an IntentReceiver that starts a
thread when it receives an Intent in its onReceiveIntent() method, and then returns fromthe function. Once it returns, the system considers that IntentReceiver to be no longer
active, and thus its hosting process no longer needed (unless other application
components are active in it). Thus, it may kill the process at any time to reclaim
memory, terminating the spawned thread that is running in it. The solution to this
problem is to start a Service from the IntentReceiver, so the system knows that there is
still active work being done in the process.
To determine which processes should be killed when low on memory, Android
places them into an "importance hierarchy" based on the components running in them
and the state of those components. These are, in order of importance:
~16~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 25/32
1. A foreground process is one holding an Activity at the top of the screen that
the user is interacting with (its onResume () method has been called) or an
IntentReceiver that is currently running (its onReceiveIntent () method is executing).
There will only ever be a few such processes in the system, and these will only be killed
as a last resort if memory is so low that not even these processes can continue to run.
Generally at this point the device has reached a memory paging state, so this action is
required in order to keep the user interface responsive.
2. A visible process is one holding an Activity that is visible to the user on-
screen but not in the foreground (its onPause() method has been called). This may
occur, for example, if the foreground activity has been displayed with a dialog
appearance that allows the previous activity to be seen behind it. Such a process is
considered extremely important and will not be killed unless doing so is required to
keep all foreground processes running.
3. A service process is one holding a Service that has been started with the
startService() method. Though these processes are not directly visible to the user, they
are generally doing things that the user cares about (such as background mp3 playback
or background network data upload or download), so the system will always keep such
processes running unless there is not enough memory to retain all foreground and
visible process.
4. A background process is one holding an Activity that is not currently
visible to the user (its onStop() method has been called). These processes have no direct
impact on the user experience. Provided they implement their activity life cycle
correctly (see Activity for more details), the system can kill such processes at any time
to reclaim memory for one of the three previous processes types. Usually there are
many of these processes running, so they are kept in an LRU list to ensure the processthat was most recently seen by the user is the last to be killed when running low on
memory.
~17~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 26/32
5. An empty process is one that doesn't hold any active application components.
The only reason to keep such a process around is as a cache to improve startup time the
next time a component of its application needs to run. As such, the system will often kill
these processes in order to balance overall system resources between these empty
cached processes and the underlying kernel caches.
~18~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 27/32
12. Security and Permissions in Android
Android is a multi-process system, where each application (and parts of the
system) runs in its own process. Most security between applications and the system is
enforced at the process level through standard Linux facilities, such as user and group
IDs that are assigned to applications. Additional finer-grained security features are
provided through a "permission" mechanism that enforces restrictions on the specific
operations that a particular process can perform.
Android mobile phone platform is going to be more secure than Apple’s iPhone
or any other device in the long run. There are several solutions nowadays to protect
Google phone from various attacks. One of them is security vendor McAfee, a member
of Linux Mobile (LiMo) Foundation. This foundation joins particular companies to
develop an open mobile-device software platform. Many of the companies listed in the
LiMo Foundation have also become members of the Open Handset Alliance (OHA).
As a result, Linux secure coding practice should successfully be built into the
Android development process. However, open platform has its own disadvantages, such
as source code vulnerability for black-hat hackers. In parallel with great opportunities
for mobile application developers, there is an expectation for exploitation and harm.
Stealthy Trojans hidden in animated images, particular viruses passed from friend to
friend, used for spying and identity theft, all these threats will be active for a long run.
Another solution for such attacks is SMobile Systems mobile package. Security
Shield – an integrated application that includes anti-virus, anti-spam, firewall and other
mobile protection is up and ready to run on the Android operating system. Currently,
the main problem is availability for viruses to pose as an application and do things like
dial phone numbers, send text messages or multi-media messages or make connections
to the Internet during normal device use. It is possible for somebody to use the GPS
feature to track a person’s location without their knowledge.
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 28/32
13. Development Tools
The Android SDK includes a variety of custom tools that help develop mobile
applications on the Android platform. The most important of these are the Android
Emulator and the Android Development Tools plugin for Eclipse, but the SDK also
includes a variety of other tools for debugging, packaging, and installing are
applications on the emulator.
1. Android Emulator
A virtual mobile device that runs on computer use the emulator to design,
debug, and test r applications in an actual Android run-time environment.
2. Android Development Tools Plugin for the Eclipse IDE
The ADT plugin adds powerful extensions to the Eclipse integrated environment,
making creating and debugging r Android applications easier and faster. If use Eclipse,
the ADT plugin gives an incredible boost in developing Android applications:
It gives access to other Android development tools from inside the Eclipse IDE. For
example, ADT lets access the many capabilities of the DDMS tool — takingscreenshots, managing port-forwarding, setting breakpoints, and viewing thread and
process information — directly from Eclipse.
It provides a New Project Wizard, which helps quickly create and set up all of the basic
files’ll need for a new Android application.
It automates and simplifies the process of building r Android application.
~20~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 29/32
It provides an Android code editor that helps write valid XML for r Android manifest
and resource files.
3. Dalvik Debug Monitor Service (ddms)
Integrated with Dalvik, the Android platform's custom VM, this tool lets manage
processes on an emulator or device and assists in debugging. can use it to kill
processes, select a specific process to debug, generate trace data, view heap and thread
information, take screenshots of the emulator or device, and more.
4. Android Debug Bridge (adb)
The adb tool lets install application's .apk files on an emulator or device and access the
emulator or device from a command line. can also use it to link a standard debugger toapplication code running on an Android emulator or device.
5. Android Asset Packaging Tool (aapt)
The aapt tool lets create .apk files containing the binaries and resources of Android
applications.
6. Android Interface Description Language (aidl)
Aidl Lets generate code for an interprocess interface, such as what a service might use.
7. SQLite
Included as a convenience, this tool lets access the SQLite data files created and used by
Android applications.
8. Trace view
This tool produces graphical analysis views of trace log data that can generate from rAndroid application.
~21~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 30/32
9. mksdcard
Helps create a disk image that can use with the emulator, to simulate the presence of
an external storage card (such as an SD card).
~22~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 31/32
14. Conclusion
Android is a truly open, free development platform based on Linux and open source.
Handset makers can use and customize the platform without paying a royalty.
A component-based architecture inspired by Internet mash-ups. Parts of oneapplication can be used in another in ways not originally envisioned by the developer.
can even replace built-in components with own improved versions. This will unleash a
new round of creativity in the mobile space.
1. Android is open to all: industry, developers and users
2. Participating in many of the successful open source projects
3. Aims to be as easy to build for as the web.
4. Google Android is stepping into the next level of Mobile Internet
~23~
8/4/2019 A Seminar Report Final
http://slidepdf.com/reader/full/a-seminar-report-final 32/32
15. References
1. http://www.spectrumdt.com
2. http://code.google.com/android/ - Google Android official webpage
3. http://www.openhandsetalliance.com/ - Open Handset Alliance webpage
4. http://en.wikipedia.org/wiki/Android_(mobile_phone_platform) – Wikipedia
information
5. http://googleblog.blogspot.com/ - Official Google Blog
~24~