Android Operating System

A
Seminar report
on
Android OS
Submitted in partial fulfilment for the requirement award of the degree of
Bachelor of Technology
In
“COMPUTER SCIENCE ENGINEERING”
(session 2019-2020)
Submitted to: - Submitted by: -
Dr. Jitendra Singh Chauhan Nandkishor Kumawat
(Head of Department) E.N.16E1RAMEM40P062(16ERACS022)
COMPUTER SCIENCE ENGINEERING B. TECH 7TH SEMESTER

ACKNOWLEDGEMENT
It gives me immense pleasure in presenting seminar on the topic Android OS. I acknowledge the
enormous assistance and excellent co-operation extended to by my respected guide Assistant Prof. (Mr.)
Devendra Suthar.
I would also like to thank the staff members for their valuable support. Lastly I would like to express
my heartfelt indebtedness towards all those who have helped me directly or indirectly for the success of
the seminar.
Nandkishor Kumawat
(Roll No. 16ERACS022)
(i)

Acknowledgement --------- ----------------------------------------------------------------------------------------- (i)
Table of contents ---------------------------------------------------------------------------------------------------- (ii)
References ----------------------------------------------------------------------------------------------------------- (iv)
Conclusion ----------------------------------------------------------------------------------------------------------- (v)
Glossary ----------------------------------------------------------------------------------------------------------- (vi)
Table of Contents
Chapter 1
1.1 Abstract ----------------------------------------------------------------------------------------------------- 1
Chapter 2 2
2.1 Introduction -------------------------------------------------------------------------- -------------------- 2
2.2 The birth of android --------------------------------------------------------- ----------------------------- 3
2.3 Open handset alliance founded ------------------------------------------------------------------------- 3
2.4 Hardware ------------------------------------------------------------------------------------------------ -- 4-5
Chapter 3 6
3.1 Features of Android OS ------------------------------------------------------------------------------ 6-7
Chapter 4 8
4.1 Android Architecture ----------------------------------------------------------------------------------- 8
4.1.1 Application Framework------------------------------------------------------------------------9
4.1.2 Libraries------------------------------------------------------------------------------------------ 10
4.1.3 Android Runtime-------------------------------------------------------------------------------- 11
4.1.4 Linux Kernel-------------------------------------------------------------------------------------12
Chapter 5 13
5.1 Architecture for Secure Data storage------------------------------------------------------------------ 13
5.2 Security tips ----------------------------------------------------------------------------------------------- 15-26
(ii)

Chapter 6
6.1 Execution Environment --------------------------------------------------------------------------------- 16
6.2 The Dalvik Virtual Machine---------------------------------------------------------------------------- 19
Chapter 7 31
7.1 Lifecycle of an Android Application ----------------------------------------------------------------- 31
7.2 Security and permissions in Android ------------------------------------------------------------------ 33
7.3 Development Tools-------------------------------------------------------------------------------------23
(iii)

Chapter 1
1. 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 and the 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 the Apache free-software and open-source license.
1Open - 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.
1

Chapter 2
2.1 INTRODUCTION
Android is a Linux based operating system it is designed primarily for touch screen mobile devices such as
smart phones and tablet computers. The operating system have developed a lot in last 15 years starting
from black and white phones to recent smart phones or mini computers. One of the most widely used
mobile OS these days is android. The android is software that was founded in Palo Alto of California in
2003.
Figure 1.1: Android Smartphone
The android is a powerful operating system and it supports large number of applications in Smartphones.
These applications are more comfortable and advanced for the users. The hardware that supports android
software is based on ARM architecture platform. The android is an open source operating system means
that it’s free and any one can use it. The android has got millions of apps available that can help you
managing your life one or other way and it is available low cost in market at that reasons android is very
popular.
Figure 2.2: Android OS
2

2.2 The birth of android
Google Acquires Android Inc.
In July 2005, Google acquired Android Inc., a small start-up company based in Palo Alto, CA. Android's
co-founders who went to work at Google included Andy Rubin (co-founder of Danger), Rich Miner (co-
founder of Wildfire Communications, Inc.), Nick Sears (once VP at T-Mobile), and Chris White (one of
the first engineers at WebTV). At the time, little was known about the functions of Android Inc. other
than they made software for mobile phones.
2.3 Open Handset Alliance Founded
The Open Handset Alliance (OHA) is a consortium whose goal is to develop open standards for mobile
devices, promote innovation in mobile phones and provide a better experience for consumers at a lower
cost.
On 5 November 2007, the Open Handset Alliance, a consortium of several companies which include
Google, HTC, Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel and NVIDIA, was unveiled with the
goal to develop open standards for mobile devices. Along with the formation of the Open Handset
Alliance, the OHA also unveiled their first product, Android, an open source mobile device platform
based on the Linux operating system.
OHA members are primarily mobile operators, handset manufacturers, software development firms,
semiconductor companies and commercialization companies. Members share a commitment to expanding
the commercial viability of open platform development.
OHA member companies back the open platform concept for a number of reasons, as follows:
 Lower overall handset costs: Opens up resources, which facilitates the focus on creating innovative
applications, solutions and services.
 Developer-friendly environment: In the open-source community, developers share notes to
expedite application development.
 Post-development: Provides an ideal channel for application marketing and distribution.
3

2.4 Hardware
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.
The main hardware platform for Android is ARM (the ARMv7 and ARMv8-A architectures), with x86
and x86-64 architectures also officially supported in later versions of Android. The unofficial Android-x86
project provided support for x86 architectures ahead of the official support.
The ARMv5TE and MIPS32/64 architectures were also historically supported but removed in later
Android releases. Since 2012, Android devices with Intel processors began to appear, including phones
and tablets. While gaining support for 64-bit platforms, Android was first made to run on 64-bit x86 and
then on ARM64. Since Android 5.0 "Lollipop", 64-bit variants of all platforms are supported in addition to
the 32-bit variants. Requirements for the minimum amount of RAM for devices running Android 7.1 range
from in practice 2 GB for best hardware, down to 1 GB for the most common screen, to absolute minimum
512 MB for the lowest spec 32-bit smartphone.
The recommendation for Android 4.4 is to have at least 512 MB of RAM, while for "low RAM" devices
340 MB is the required minimum amount that does not include memory dedicated to various hardware
components such as the baseband processor. Android 4.4 requires a 32-bit ARMv7, MIPS or x86
architecture processor (latter two through unofficial ports), together with an OpenGL ES 2.0 compatible
graphics processing unit (GPU). Android supports OpenGL ES 1.1, 2.0, 3.0, 3.1 and as of latest major
version, 3.2 and since Android 7.0 Vulkan (and version 1.1 available for some devices). Some applications
may explicitly require a certain version of the OpenGL ES, and suitable GPU hardware is required to run
such applications.
Android devices incorporate many optional hardware components, including still or video cameras, GPS,
orientation sensors, dedicated gaming controls, accelerometers, gyroscopes, barometers, magnetometers,
proximity sensors, pressure sensors, thermometers, and touchscreens. Some hardware components are not
required, but became standard in certain classes of devices, such as smartphones, and additional
requirements apply if they are present. Some other hardware was initially required, but those requirements
have been relaxed or eliminated altogether.
4

For example, as Android was developed initially as a phone OS, hardware such as microphones were
required, while over time the phone function became optional. Android used to require an autofocus
camera, which was relaxed to a fixed-focus camera if present at all, since the camera was dropped as a
requirement entirely when Android started to be used on set-top boxes.
In addition to running on smartphones and tablets, several vendors run Android natively on regular PC
hardware with a keyboard and mouse. In addition to their availability on commercially available hardware,
similar PC hardware-friendly versions of Android are freely available from the Android-x86 project,
including customized Android 4.4. Using the Android emulator that is part of the Android SDK, or third-
party emulators, Android can also run non-natively on x86 architectures. Chinese companies are building a
PC and mobile operating system, based on Android, to "compete directly with Microsoft Windows and
Google Android". The Chinese Academy of Engineering noted that "more than a dozen" companies were
customising Android following a Chinese ban on the use of Windows 8 on government PCs
5

Chapter 3
3.1 Features of Android OS
General
Messaging
SMS and MMS are available forms of messaging, including threaded text messaging and Android Cloud
to Device Messaging (C2DM) and now enhanced version of C2DM, Android Google Cloud Messaging
(GCM) is also a part of Android Push Messaging services. Android phones also have the ability to send
and receive RCS via the messages app (if supported by the carrier).
Auto Correction and Dictionary
Android Operating System has an interesting feature called Auto Correction. When any word is
misspelled, then Android recommends the meaningful and correct words matching the words that are
available in Dictionary. Users can add, edit and remove words from Dictionary as per their wish.
Web browser
The web browser available in Android is based on the open-source Blink (previously WebKit) layout
engine, coupled with Chromium's V8 JavaScript engine. Then the WebKit-using Android Browser scored
100/100 on the Acid3 test on Android 4.0 ICS; the Blink-based browser currently has better standards
support. The old web browser is variably known as 'Android Browser', 'AOSP browser', 'stock browser',
'native browser', and 'default browser' (from the time it was always the default). Starting with Android 4.4
KitKat, Google has begun licensing Google Chrome (a proprietary software) separately from Android,
but usually bundled with (what most device vendors did). Since Android 5.0 Lollipop, the WebView
browser that apps can use to display web content without leaving the app has been separated from the rest
of the Android firmware in order to facilitate separate security updates by Google.
Voice-based features
Google search through voice has been available since initial release. Voice actions for calling, texting,
navigation, etc. are supported on Android 2.2 onwards. As of Android 4.1, Google has expanded Voice
Actions with ability to talk back and read answers from Google's Knowledge Graph when queried with
specific commands. The ability to control hardware has not yet been implemented.
6

Multi-touch
Android has native support for multi-touch which was initially made available in handsets such as the
HTC Hero. The feature was originally disabled at the kernel level (possibly to avoid infringing Apple's
patents on touch-screen technology at the time). Google has since released an update for the Nexus One
and the Motorola Droid which enables multi-touch natively.
Multitasking
Multitasking of applications, with unique handling of memory allocation, is available.
Screen capture
Android supports capturing a screenshot by pressing the power and home-screen buttons at the same time.
Prior to Android 4.0, the only methods of capturing a screenshot were through manufacturer and third-
party customizations (apps), or otherwise by using a PC connection (DDMS developer's tool). These
alternative methods are still available with the latest Android.
TV recording
Android TV supports capturing video and replaying it.
Video calling
Android does not support native video calling, but some handsets have a customized version of the
operating system that supports it, either via the UMTS network (like the Samsung Galaxy S) or over IP.
Video calling through Google Talk is available in Android 2.3.4 (Gingerbread) and later. Gingerbread
allows Nexus S to place Internet calls with a SIP account. This allows for enhanced VoIP dialing to other
SIP accounts and even phone numbers. Skype 2.1 offers video calling in Android 2.3, including front
camera support. Users with the Google+ Android app can perform video chat with other Google+ users
through Hangouts.
Multiple language support
Android supports multiple languages.
Accessibility
Built-in text-to-speech is provided by TalkBack for people with low or no vision. Enhancements for
people with hearing difficulties are available, as are other aids.
7

· Chapter 4
4.1 Android Architecture
The following diagram shows the major components of Android
Figure 4.1: Architecture of Android OS
8

4.1.1 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:
 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.
 Content Providers that enable applications to access data from other applications (such as Contacts),
or to share their own data.
 A Resource Manager, providing access to non-code resources such as localized strings, graphics,
and large files.
 A Notification Manager that enables all applications to display custom alerts in the status bar
 An Activity Manager that manages the life cycle of applications and provides a common navigation
back stack.
9

4.1.2 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:
System C library - a BSD-derived implementation of the standard C system library (libc), tuned for
embedded Linux-based devices
Media Libraries - based on Packet Video’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
Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D
graphic layers from multiple applications
LibWebCore - a modern web browser engine which powers both the Android browser and an embeddable
web view
SGL - the underlying 2D graphics engine
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
Free Type - bitmap and vector font rendering
SQLite - a powerful and lightweight relational database engine available to all applications.
10

4.1.3 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 virtual machine. 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 4.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.
11

4.1.4 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. Camera up to 6.0 megapixels
7. gpsOne – solution for GPS
12

Chapter 5
5.1 Architecture for Secure Data Storage
Figure 5.1: Android and Secure Local Data Storage
Secure 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 5.1, 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.
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.
13

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 challenge and 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 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.
6. 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.
7. That being said, it would be possible to further extend this architecture to store the encrypted
symmetric key on the server. This way, even if the passphrase of the private key is compromised.
14

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.
9. It is also possible to enforce a strong password policy directly from the handset application.
10. 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.
11.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.
5.2 Security Tips:
Android has built-in security features that significantly reduce the frequency and impact of application
security issues. The system is designed so that you can typically build your apps with the default system
and file permissions and avoid difficult decisions about security.
The following core security features help you build secure apps:
 The Android Application Sandbox, which isolates your app data and code execution from other
apps.
 An application framework with robust implementations of common security functionality such
as cryptography, permissions, and secure IPC.
 Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and
Linux mmap_min_addr to mitigate risks associated with common memory management errors.
 An encrypted file system that can be enabled to protect data on lost or stolen devices.
 User-granted permissions to restrict access to system features and user data.
 Application-defined permissions to control application data on a per-app basis.
It is important that you be familiar with the Android security best practices in this document. Following
these practices as general coding habits reduces the likelihood of inadvertently introducing security issues
that adversely affect your users.
15

Store data
The most common security concern for an application on Android is whether the data that you save on the
device is accessible to other apps. There are three fundamental ways to save data on the device:
 Internal storage.
 External storage.
 Content providers.
The following paragraphs describe the security issues associated with each approach.
Use internal storage
By default, files that you create on internal storage are accessible only to your app. Android implements
this protection, and it's sufficient for most applications.
Generally, avoid the MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE modes for IPC
files because they do not provide the ability to limit data access to particular applications, nor do they
provide any control of data format. If you want to share your data with other app processes, instead
consider using a content provider, which offers read and write permissions to other apps and can make
dynamic permission grants on a case-by-case basis.
To provide additional protection for sensitive data, you can encrypt local files using the Security library.
This measure can provide protection for a lost device without file system encryption.
Use external storage
Files created on external storage, such as SD cards, are globally readable and writable. Because external
storage can be removed by the user and also modified by any application, don't store sensitive
information using external storage.
To read and write files on external storage in a more secure way, consider using the Security library,
which provides the EncryptedFile class.
You should Perform input validation when handling data from external storage as you would with data
from any untrusted source.
16

You should not store executables or class files on external storage prior to
dynamic loading. If your app does retrieve executable files from external storage, the files should be
signed and cryptographically verified prior to dynamic loading.
Use content providers
Content providers offer a structured storage mechanism that can be limited to your own application or
exported to allow access by other applications. If you do not intend to provide other applications with
access to your ContentProvider, mark them as android:exported=false in the application manifest.
Otherwise, set the android:exported attribute to true to allow other apps to access the stored data.
When creating a ContentProvider that is exported for use by other applications, you can specify a single
permission for reading and writing, or you can specify distinct permissions for reading and writing. You
should limit your permissions to those required to accomplish the task at hand. Keep in mind that it’s
usually easier to add permissions later to expose new functionality than it is to take them away and impact
existing users.
If you are using a content provider for sharing data between only your own apps, it is preferable to use the
android:protectionLevel attribute set to signature protection. Signature permissions do not require user
confirmation, so they provide a better user experience and more controlled access to the content provider
data when the apps accessing the data are signed with the same key.
Content providers can also provide more granular access by declaring the android:grantUriPermissions
attribut FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION
flags in the Intent object that activates the component. The scope of these permissions can be further
limited by the <grant-uri-permission> element.
When accessing a content provider, use parameterized query methods such as query(), update(), and
delete() to avoid potential SQL injection from untrusted sources. Note that using parameterized methods
is not sufficient if the selection argument is built by concatenating user data prior to submitting it to the
method.
17

Don't have a false sense of security about the write permission. The write permission allows SQL
statements that make it possible for some data to be confirmed using creative
WHERE clauses and parsing the results. For example, an attacker might probe for the presence of a
specific phone number in a call log by modifying a row only if that phone number already exists. If the
content provider data has predictable structure, the write permission may be equivalent to providing both
reading and writing.
Use permissions
Because Android sandboxes applications from each other, applications must explicitly share resources
and data. They do this by declaring the permissions they need for additional capabilities not provided by
the basic sandbox, including access to device features such as the camera.
Request permissions
You should minimize the number of permissions that your app requests. Restricting access to sensitive
permissions reduces the risk of inadvertently misusing those permissions, improves user adoption, and
makes your app less vulnerable for attackers. Generally, if a permission is not required for your app to
function, don't request it. If there is a feature that the app can't run without, declare it using a <uses-
feature> element in the manifest file.
If it's possible to design your application in a way that does not require any permissions, that is
preferable. For example, rather than requesting access to device information to create a unique identifier,
create a GUID for your application (see the section about Handling user data). Or, rather than using
external storage (which requires permission), store data on the internal storage.
In addition to requesting permissions, your application can use the <permission> element to protect IPC
that is security sensitive and is exposed to other applications, such as a ContentProvider. In general, we
recommend using access controls other than user confirmed permissions where possible because
permissions can be confusing for users. For example, consider using the signature protection level on
permissions for IPC communication between applications provided by a single developer.
Do not leak permission-protected data. This occurs when your app exposes data over IPC that is available
only because your app has permission to access that data. The clients of your app's IPC interface may not
have that same data-access permission.
18

Create permissions
Generally, you should strive to define as few permissions as possible while satisfying your security
requirements. Creating a new permission is relatively uncommon for most applications, because the
system-defined permissions cover many situations. Where appropriate, perform access checks using
existing permissions.
If you must create a new permission, consider whether you can accomplish your task with a signature
protection level. Signature permissions are transparent to the user and allow access only by applications
signed by the same developer as the application performing the permission check. If the new permission is
still required, it's declared in the app manifest using the <permission> element. Apps that wish to use the
new permission can reference it by each adding a <uses-permission> element in their respective manifest
files. You can also add permissions dynamically by using the addPermission() method.
If you create a permission with the dangerous protection level, there are a number of complexities that you
need to consider:
 The permission must have a string that concisely expresses to a user the security decision they are
required to make.
 The permission string must be localized to many different languages.
 Users may choose not to install an application because a permission is confusing or perceived as
risky.
 Applications may request the permission when the creator of the permission has not been installed.
Each of these poses a significant nontechnical challenge for you as the developer while also confusing your
users, which is why we discourages the use of the dangerous permission level.
Use networking
Network transactions are inherently risky for security, because they involve transmitting data that is
potentially private to the user. People are increasingly aware of the privacy concerns of a mobile device,
especially when the device performs network transactions, so it's very important that your app implement
all best practices toward keeping the user's data secure at all times.
Use IP networking
Networking on Android is not significantly different from other Linux environments. The key
consideration is making sure that appropriate protocols are used for sensitive data, such as
HttpsURLConnection for secure web traffic. You should use HTTPS over HTTP anywhere that HTTPS
is supported on the server, because mobile devices frequently connect on networks that are not secured,
such as public Wi-Fi hotspots.
Authenticated, encrypted socket-level communication can be easily implemented using the SSLSocket
class. Given the frequency with which Android devices connect to unsecured wireless networks using Wi-
Fi, the use of secure networking is strongly encouraged for all applications that communicate over the
network.
19

Some applications use localhost network ports for handling sensitive IPC. You should not use this
approach because these interfaces are accessible by other applications on the device. Instead, use an
Android IPC mechanism where authentication is possible, such as with a Service. Binding to
INADDR_ANY is worse than using loopback because then your application may receive requests from
anywhere.
Make sure that you don't trust data downloaded from HTTP or other insecure protocols. This includes
validation of input in WebView and any responses to intents issued against HTTP.
Use telephony networking
The SMS protocol was primarily designed for user-to-user communication and is not well-suited for apps
that want to transfer data. Due to the limitations of SMS, you should use Google Cloud Messaging (GCM)
and IP networking for sending data messages from a web server to your app on a user device.
Beware that SMS is neither encrypted nor strongly authenticated on either the network or the device. In
particular, any SMS receiver should expect that a malicious user may have sent the SMS to your
application. Don't rely on unauthenticated SMS data to perform sensitive commands. Also, you should be
aware that SMS may be subject to spoofing and/or interception on the network. On the Android-powered
device itself, SMS messages are transmitted as broadcast intents, so they may be read or captured by other
applications that have the READ_SMS permission.
Perform input validation
Insufficient input validation is one of the most common security problems affecting applications,
regardless of what platform they run on. Android has platform-level countermeasures that reduce the
exposure of applications to input validation issues, and you should use those features where possible. Also
note that the selection of type-safe languages tends to reduce the likelihood of input validation issues.
If you are using native code, any data read from files, received over the network, or received from an IPC
has the potential to introduce a security issue. The most common problems are buffer overflows, use after
free, and off-by-one errors. Android provides a number of technologies like ASLR and DEP that reduce the
exploitability of these errors, but they don't solve the underlying problem. You can prevent these
vulnerabilities by carefully handling pointers and managing buffers.
Dynamic, string-based languages such as JavaScript and SQL are also subject to input validation problems
due to escape characters and script injection.
If you are using data within queries that are submitted to an SQL database or a content provider, SQL
injection may be an issue. The best defense is to use parameterized queries, as is discussed in the above
section about content providers. Limiting permissions to read-only or write-only can also reduce the
potential for harm related to SQL injection.
If you can't use the security features above, you should make sure to use well-structured data formats and
verify that the data conforms to the expected format. While blacklisting of characters or character-
replacement can be an effective strategy, these techniques are error prone in practice and should be avoided
when possible.
20

Handle user data
In general, the best approach for user data security is to minimize the use of APIs that access sensitive or
personal user data. If you have access to user data and can avoid storing or transmitting it, don't store or
transmit the data. Consider if there is a way that your application logic can be implemented using a hash or
non-reversible form of the data. For example, your application might use the hash of an email address as a
primary key to avoid transmitting or storing the email address. This reduces the chances of inadvertently
exposing data, and it also reduces the chance of attackers attempting to exploit your application.
If your application accesses personal information such as passwords or user names, keep in mind that some
jurisdictions may require you to provide a privacy policy explaining your use and storage of that data.
Following the security best practice of minimizing access to user data may also simplify compliance.
You should also consider whether your application might be inadvertently exposing personal information
to other parties such as third-party components for advertising or third-party services used by your
application. If you don't know why a component or service requires personal information, don’t provide it.
In general, reducing the access to personal information by your application reduces the potential for
problems in this area.
If your app requires access to sensitive data, evaluate whether you need to transmit it to a server or you can
run the operation on the client. Consider running any code using sensitive data on the client to avoid
transmitting user data. Also, make sure that you do not inadvertently expose user data to other applications
on the device through overly permissive IPC, world-writable files, or network sockets. Overly permissive
IPC is a special case of leaking permission-protected data, discussed in the Requesting Permissions section.
If a GUID is required, create a large, unique number and store it. Don't use phone identifiers such as the
phone number or IMEI, which may be associated with personal information. This topic is discussed in
more detail in the Android Developer Blog.
Be careful when writing to on-device logs. In Android, logs are a shared resource and are available to an
application with the READ_LOGS permission. Even though the phone log data is temporary and erased on
reboot, inappropriate logging of user information could inadvertently leak user data to other applications.
In addition to not logging PII, production apps should limit log usage. To easily implement this, use debug
flags and custom Log classes with easily configurable logging levels.
Use WebvView
Because WebView consumes web content that can include HTML and JavaScript, improper use can
introduce common web security issues such as cross-site-scripting (JavaScript injection). Android includes
a number of mechanisms to reduce the scope of these potential issues by limiting the capability of
WebView to the minimum functionality required by your application.
If your application doesn't directly use JavaScript within a WebView, do not call setJavaScriptEnabled().
Some sample code uses this method, which you might repurpose in production application, so remove that
method call if it's not required. By default, WebView does not execute JavaScript, so cross-site-scripting is
not possible.
21

Use addJavaScriptInterface() with particular care because it allows JavaScript to invoke operations that
are normally reserved for Android applications. If you use it, expose addJavaScriptInterface() only to
web pages from which all input is trustworthy. If untrusted input is allowed, untrusted JavaScript may be
able to invoke Android methods within your app. In general, we recommend exposing
addJavaScriptInterface() only to JavaScript that is contained within your application APK.
If your application accesses sensitive data with a WebView, you may want to use the clearCache() method
to delete any files stored locally. You can also use server-side headers such as no-cache to indicate that an
application should not cache particular content.
Devices running platforms older than Android 4.4 (API level 19) use a version of webkit that has a number
of security issues. As a workaround, if your app is running on these devices, it must confirm that WebView
objects display only trusted content. To make sure your app isn’t exposed to potential vulnerabilities in
SSL, use the updatable security Provider object as described in Updating Your Security Provider to Protect
Against SSL Exploits. If your application must render content from the open web, consider providing your
own renderer so you can keep it up to date with the latest security patches.
Handle credentials
To make phishing attacks more conspicuous and less likely to be successful, minimize the frequency of
asking for user credentials. Instead use an authorization token and refresh it.
Where possible, don't store user names and passwords on the device. Instead, perform initial authentication
using the user name and password supplied by the user, and then use a short-lived, service-specific
authorization token.
Services that are accessible to multiple applications should be accessed using AccountManager. If
possible, use the AccountManager class to invoke a cloud-based service and don't store passwords on the
device.
After using AccountManager to retrieve an Account, use CREATOR before passing in any credentials so
that you do not inadvertently pass credentials to the wrong application.
If credentials are used only by applications that you create, you can verify the application that accesses the
AccountManager using checkSignature(). Alternatively, if only one application uses the credential, you
might use a KeyStore for storage.
Use cryptography
In addition to providing data isolation, supporting full-filesystem encryption, and providing secure
communications channels, Android provides a wide array of algorithms for protecting data using
cryptography.
In general, you should know which Java Cryptography Architecture (JCA) security providers your
software uses. Try to use the highest level of the pre-existing framework implementation that can support
your use case. If applicable, use the Google-provided providers in the Google-specified order.
To read and write local files more securely, use the Security library.
22

If you need to securely retrieve a file from a known network location, a simple HTTPS URI may be
adequate and requires no knowledge of cryptography. If you need a secure tunnel, consider using
HttpsURLConnection or SSLSocket rather than writing your own protocol. If you use SSLSocket, be
aware that it does not perform hostname verification. See Warnings about using SSLSocket directly.
If you find that you need to implement your own protocol, you shouldn't implement your own
cryptographic algorithms. Use existing cryptographic algorithms, such as the implementations of AES and
RSA provided in the Cipher class. Additionally, you should follow these best practices:
 Use 256-bit AES for commercial purposes. (If unavailable, use 128-bit AES.)
 Use either 224- or 256-bit public key sizes for elliptic curve (EC) cryptography.
 Know when to use CBC, CTR, or GCM block modes.
 Avoid IV/counter reuse in CTR mode. Ensure that they're cryptographically random.
 When using encryption, implement integrity using the CBC or CTR mode with one of the following
functions:
 HMAC-SHA1
 HMAC-SHA-256
 HMAC-SHA-512
 GCM mode
Use a secure random number generator, SecureRandom, to initialize any cryptographic keys generated by
KeyGenerator. Use of a key that is not generated with a secure random number generator significantly
weakens the strength of the algorithm and may allow offline attacks.
If you need to store a key for repeated use, use a mechanism, such as KeyStore, that provides a mechanism
for long term storage and retrieval of cryptographic keys.
Use interprocess communication
Some apps attempt to implement IPC using traditional Linux techniques such as network sockets and
shared files. However, you should instead use Android system functionality for IPC such as Intent, Binder
or Messenger with a Service, and BroadcastReceiver. The Android IPC mechanisms allow you to verify
the identity of the application connecting to your IPC and set security policy for each IPC mechanism.
Many of the security elements are shared across IPC mechanisms. If your IPC mechanism is not intended
for use by other applications, set the android:exported attribute to false in the component's manifest
element, such as for the <service> element. This is useful for applications that consist of multiple processes
within the same UID or if you decide late in development that you don't actually want to expose
functionality as IPC, but you don’t want to rewrite the code.
If your IPC is accessible to other applications, you can apply a security policy by using the <permission>
element. If IPC is between your own separate apps that are signed with the same key, it is preferable to use
signature level permission in the android:protectionLevel
Use intents
For activities and broadcast receivers, intents are the preferred mechanism for asynchronous IPC in
Android. Depending on your application requirements, you might use sendBroadcast(),
sendOrderedBroadcast(), or an explicit intent to a specific application component. For security purposes,
explicit intents are preferred.
23

Note that ordered broadcasts can be consumed by a recipient, so they may not be delivered to all
applications. If you are sending an intent that must be delivered to a specific receiver, you must use an
explicit intent that declares the receiver by name.
Senders of an intent can verify that the recipient has permission by specifying a non-null permission with
the method call. Only applications with that permission receive the intent. If data within a broadcast intent
may be sensitive, you should consider applying a permission to make sure that malicious applications can't
register to receive those messages without appropriate permissions. In those circumstances, you may also
consider invoking the receiver directly, rather than raising a broadcast.
Use services
A Service is often used to supply functionality for other applications to use. Each service class must have a
corresponding <service> declaration in its manifest file.
By default, services are not exported and cannot be invoked by any other application. However, if you add
any intent filters to the service declaration, it is exported by default. It's best if you explicitly declare the
android:exported attribute to be sure it behaves as you'd like. Services can also be protected using the
android:permission attribute. By doing so, other applications need to declare a corresponding <uses-
permission> element in their own manifest to be able to start, stop, or bind to the service.
A service can protect individual IPC calls into it with permissions, by calling checkCallingPermission()
before executing the implementation of that call. You should use the declarative permissions in the
manifest, since those are less prone to oversight.
Use binder and messenger interfaces
Using Binder or Messenger is the preferred mechanism for RPC-style IPC in Android. They provide a
well-defined interface that enables mutual authentication of the endpoints, if required.
You should design your app interfaces in a manner that does not require interface-specific permission
checks. Binder and Messenger objects are not declared within the application manifest, and therefore you
cannot apply declarative permissions directly to them. They generally inherit permissions declared in the
application manifest for the Service or Activity within which they are implemented. If you are creating an
interface that requires authentication and/or access controls, you must explicitly add those controls as code
in the Binder or Messenger interface.
If you are providing an interface that does require access controls, use checkCallingPermission() to verify
whether the caller has a required permission. This is especially important before accessing a service on
behalf of the caller, as the identity of your application is passed to other interfaces. If you are invoking an
interface provided by a Service, the bindService() invocation may fail if you do not have permission to
access the given service. If calling an interface provided locally by your own application, it may be useful
to use the clearCallingIdentity() method, which masks the caller permissions against the app's
permissions, to satisfy internal security checks. You can restore the caller permissions later by using the
restoreCallingIdentity() method.
24

Use broadcast receivers
A BroadcastReceiver handles asynchronous requests initiated by an Intent.
By default, receivers are exported and can be invoked by any other application. If your BroadcastReceiver
is intended for use by other applications, you may want to apply security permissions to receivers using the
<receiver> element within the application manifest. This prevents applications without appropriate
permissions from sending an intent to the BroadcastReceiver.
Dynamically load code
We strongly discourage loading code from outside of your application APK. Doing so significantly
increases the likelihood of application compromise due to code injection or code tampering. It also adds
complexity around version management and application testing. It can also make it impossible to verify the
behavior of an application, so it may be prohibited in some environments.
If your application does dynamically load code, the most important thing to keep in mind about
dynamically-loaded code is that it runs with the same security permissions as the application APK. The
user makes a decision to install your application based on your identity, and the user expects that you
provide any code run within the application, including code that is dynamically loaded.
The major security risk associated with dynamically loading code is that the code needs to come from a
verifiable source. If the modules are included directly within your APK, they cannot be modified by other
applications. This is true whether the code is a native library or a class being loaded using
DexClassLoader. Many applications attempt to load code from insecure locations, such as downloaded
from the network over unencrypted protocols or from world-writable locations such as external storage.
These locations could allow someone on the network to modify the content in transit or another application
on a user's device to modify the content on the device.
Security in a virtual machine
Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android, but many of
the concerns regarding secure code in other virtual machines also apply to Android. In general, you
shouldn't concern yourself with security issues relating to the virtual machine. Your application runs in a
secure sandbox environment, so other processes on the system can't access your code or private data.
If you're interested in learning more about virtual machine security, familiarize yourself with some existing
literature on the subject. Two of the more popular resources are:
 Securing Java
 Related 3rd party Projects
25

This document focuses on areas that are Android specific or different from other VM environments. For
developers experienced with VM programming in other environments, there are two broad issues that may
be different about writing apps for Android:
 Some virtual machines, such as the JVM or .NET runtime, act as a security boundary, isolating
code from the underlying operating system capabilities. On Android, the Dalvik VM is not a
security boundary—the application sandbox is implemented at the OS level, so Dalvik can
interoperate with native code in the same application without any security constraints.
 Given the limited storage on mobile devices, it’s common for developers to want to build modular
applications and use dynamic class loading. When doing this, consider both the source where you
retrieve your application logic and where you store it locally. Do not use dynamic class loading
from sources that are not verified, such as unsecured network sources or external storage, because
that code might be modified to include malicious behavior.
Security in native code
In general, you should use the Android SDK for application development, rather than using native code
with the Android NDK. Applications built with native code are more complex, less portable, and more like
to include common memory-corruption errors such as buffer overflows.
Android is built using the Linux kernel, and being familiar with Linux development security best practices
is especially useful if you are using native code. Linux security practices are beyond the scope of this
document, but one of the most popular resources is Secure Programming HOWTO - Creating Secure
Software.
An important difference between Android and most Linux environments is the Application Sandbox. On
Android, all applications run in the Application Sandbox, including those written with native code. At the
most basic level, a good way to think about it for developers familiar with Linux is to know that every
application is given a unique UID with very limited permissions. This is discussed in more detail in the
Android Security Overview, and you should be familiar with application permissions even if you are using
native code.
26

Chapter 6
6.1 Execution Environment
Figure 6.1: Regular Java Execution Process
27

Figure 6.2: Android Execution Environment
28

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 Java environment
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.
29

6.2 The Dalvik Virtual Machine
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 centre 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.
Programs for Android are commonly written in Java and compiled to bytecode for the Java virtual
machine, which is then translated to Dalvik bytecode and stored in .dex (Dalvik EXecutable) and .dex
(Optimized Dalvik EXecutable) files; related terms .dex and de-.dex are associated with respective
bytecode conversions. The compact Dalvik Executable format is designed for systems that are
constrained in terms of memory and processor speed.
The successor of Dalvik is Android Runtime (ART), which uses the same bytecode and .dex files (but
not .dex files), with the succession aiming at performance improvements transparent to the end users.
The new runtime environment was included for the first time in Android 4.4 "KitKat" as a technology
preview, and replaced Dalvik entirely in later versions; Android 5.0 "Lollipop" is the first version in
which ART is the only included runtime.
30

Chapter 7
7.1 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 from the 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:
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.
31

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 process that was most
recently seen by the user is the last to be killed when running low on memory.
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.
When deciding how to classify a process, the system picks the most important level of all the
components currently active in the process.
32

7.2 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. Hence SMobile Systems is ready to notify and
block these secure alerts. But the truth is that it is not possible to secure r mobile device or personal
computer completely, as it connects to the internet. And neither the Android phone nor other devices will
prove to be the exception.
33

7.3 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 r applications on the emulator.
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.
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 — taking screenshots, 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.
It provides an Android code editor that helps write valid XML for r Android manifest and
resource files.
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.
34

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 to application code running on an
Android emulator or device.
Android Asset Packaging Tool (aapt)
The aapt tool lets create .apk files containing the binaries and resources of Android applications.
Android Interface Description Language (aidl)
Aidl Lets generate code for an interprocess interface, such as what a service might use.
sqlite3
Included as a convenience, this tool lets access the SQLite data files created and used by Android
applications.
Trace view
This tool produces graphical analysis views of trace log data that can generate from r Android
application.
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).
dx
The dx tool rewrites .class bytecode into Android bytecode (stored in .dex files.)
activityCreator
A script that generates Ant build files that can use to compile r Android applications. If are
developing on Eclipse with the ADT plugin, won't need to use this script.
35

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 one application 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.
· Android is open to all: industry, developers and users
· Participating in many of the successful open source projects
· Aims to be as easy to build for as the web.
· Google Android is stepping into the next level of Mobile Internet
(iv)

References
1. "Android Language Breakdown". Open Hub. October 25, 2017. Archived from the original on
December 14, 2017. Retrieved December 15, 2017.
2. Morrill, Dan (September 23, 2008). "Announcing the Android 1.0 SDK, release 1". Android
Developers Blog. Archived from the original on March 5, 2017. Retrieved March 11, 2017.
3. Bohn, Dieter (September 3, 2019). "Android 10 officially released for Google Pixel phones".
The Verge.
4. "Android 7.0 Nougat". Archived from the original on August 22, 2016. Retrieved September 5,
2016. Internationalization
5. "android/platform/bionic/". Archived from the original on December 3, 2017.
6. "android/platform/external/mksh/". Archived from the original on January 21, 2016.
7. "android/platform/external/toybox/toys/". Archived from the original on March 14, 2016.
8. "Android gets a toybox". Archived from the original on March 4, 2016.
9. "Licenses". Android Source. Archived from the original on December 15, 2016. Retrieved
March 11, 2017.
10. "Is Android Really Open Source? And Does It Even Matter?". MakeUseOf.
11. "Android – Google Mobile Services". Android. Retrieved October 21, 2018. While the Android
Open Source Project (AOSP) provides common, device-level functionalities such as email and
calling, GMS is not part of AOSP. GMS is only available through a license with Google [..] We
ask GMS partners to pass a simple compatibility test and adhere to our compatibility
requirements for their Android devices.
12. "Number of available applications in the Google Play Store from December 2009 to December
2019". Statista. Retrieved January 22, 2020.
13. Google's Android OS: Past, Present, and Future". PhoneArena. August 18, 2011. Archived from
the original on March 13, 2017. Retrieved March 12, 2017.
14. Alabaster, Jay (April 16, 2013). "Android founder: We aimed to make a camera OS". PC World.
International Data Group. Archived from the original on May 10, 2017. Retrieved May 9, 2017.
(v)

Glossary
SDK - Software Development Kit
APIs - Application Program Interfaces
GUI - Graphical User Interface
OHA - Open Handset Alliance
GPS – Global Positioning system
LRU – Last Recently Used
MHTML – Mobile HTML
QoS – Quality of Service
WAP – Web Application Protocol
CSD – Circuit Switched Data
OTA – Over-the-Air
(vi)

Android Operating System

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Android Operating System

Semelhante a Android Operating System (20)

Último

Último (20)

Android Operating System