“Phone Book Directory”

A TRAINING REPORT

Submitted by

Abhishek Kumar Dinkar

11EIECS002

in partial fulfillment for the award of the degree

of

BACHELOR OF ENGINEERING

In

Computer Science

At

International Institute of Management,

Engineering & Technology, Jaipur

June 2014

i

“Phone Book Directory”

A TRAINING REPORT

Submitted by

Abhishek Kumar Dinkar

11EIECS002

in partial fulfillment for the award of the degree

of

BACHELOR OF ENGINEERING

In

Computer Science

At

International Institute of Management,

Engineering & Technology, Jaipur

June 2014

ii

A

Industrial Training Report

Submitted

In partial fulfillment

For the award of the degree of

Bachelor of Technology

in Department of computer science Engineering

(with specialization in ANDROID)

June 2014

Submitted by:

Abhishek Kumar Dinkar

11EIECS002

iii

ACKNOWLEDGEMENT

A scholarly and quality work like designing of any project work can be

accomplished by motivation, guidance and inspiration of certain quarters besides the

individual efforts. Let me in this page express my heartiest gratitude to all those who

helped me in various stages of this study.

We are very much thankful to Mr. Pankaj Jain, HOD, CSE for giving me the

permission to undergo this project and providing all the necessary facilities.

During my project period all the staff members of department have helped us with

their skills. Here by I express our sincere thanks to project coordinators Mr.

Rishikant Shukla Assistant Professor, CS & IT whose valuable guidance and kind

cooperation without which this project would have not been possible.

Abhishek Kumar Dinkar

(11EIECS002)

Batch: 2011-2015

v

INDEX

Topics Page no.

ACKNOWLEDGMENT iii

CERTIFICATE iv

ABSTRACT vii

COMPANY PROFILE viii

TECHNOLOGY LEARNED IN TRAINING ix

Chapter 1

Introduction

1.1 The Birth Of Android

1.2 Open Handset Alliance Founded

1.3 Hardware

1

1

2

Chapter 2

Features of Android OS

3

Chapter 3

Android Architecture

3.1 Application Framework

3.2 Libraries

3.3 Linux Kernel

4

5

6

8

Chapter 4

Architecture for secure data storage

4.1 Additional Security notes

9

11

Chapter 5

Execution Environment

5.1 The Dalvik Virtual Machine

12

14

Chapter 6

Lifecycle of an Android Application

6.1 Security and Permissions in Android

6.2 Development Tool

16

18

19

vi

Chapter 7

List of Android version from Alpha to Lollypop

21

Chapter 8

About Project

8.1 Project Requirement

8.1.1 Front end

8.1.2 Back end

8.2 Summary of Project

22

22

23

24

Chapter 9

Snapshots

9.1 Search view

9.2 Add Contact View

9.3 Action View

9.4 Update View

9.5 Show Details View

9.6 Send SMS View

9.7 Sending Email View

25

25

26

27

28

29

30

31

Glossary 32

Conclusion 33

Future Scope 34

References 35

vii

ABSTRACT

The title of this project is “Phone Book Directory”. The main purpose of phone book is to

manage phone contact daily operation efficiently. This system basically directory has been

frequently in use in our daily life.

We commonly see directory installed in, mobile phone etc. Phonebook Directory application

provides the ability to search, view, and manage entries in a directory. Mobile Directory

application should allow any subscriber with any type of mobile device.

The search result data loads directly to the mobile screen and gives the user option to CALL,

SAVE,VIEW, END TO FRIEND or DISCARD. Mobile Directory eliminates the need to call

any other call center.

viii

Company Profile

WEBMITRA is a website and Software development company based in Jodhpur,

India. We have an expertise in web Designing and Development of the projects for

the professional, corporate business houses. We also cater to the small upcoming

business and the personal biographic websites. Our center also in Jaipur.

Wide range of WEBMITRA training services includes:-

JAVA2SE

JAVA2EE

PHP

DOTNET

ANDROID

ORACLE

ADMIN1

ADMIN2

PHP, MySQL, JAVA projects development and maintenance

With its advanced and core Java courses. WEBMITRA makes professionals enable

to meet industry demand for high quality enterprise-level skills.

ix

Technology

ANDROID language originally developed by Google in 2005.

ANDROID is an Operating System which is built upon Linux kernel.

.

ANDROID is O.S. (For mobile device).

Chapter 1

1

INTRODUCTION

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.

1.1 THE BIRTH OF ANDROID

Google Acquires Android Inc.

In July 2005, Google acquired Android Inc., a small startup 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.

1.2 Open Handset Alliance Founded

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.

Chapter 1

2

1.3 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.

Chapter 2

3

Features of Android OS

Application framework enabling reuse and replacement of components

Dalvik virtual machine optimized for mobile devices

Integrated browser based on the open source WebKit engine

Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the

OpenGL ES 1.0 specification (hardware acceleration optional)

SQLite for structured data storage

Media support for common audio, video, and still image formats (MPEG4, H.264, MP3,

AAC, AMR, JPG, PNG, GIF)

GSM Telephony (hardware dependent)

Bluetooth, EDGE, 3G, and WiFi (hardware dependent)

Camera, GPS, compass, and accelerometer (hardware dependent)

Rich development environment including a device emulator, tools for debugging,

memory and performance profiling, and a plugin for the Eclipse IDE

Chapter 3

4

Android Architecture

The following diagram shows the major components of Android

Figure 1: Architecture of Android OS

Chapter 3

5

3.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 lat 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 backstack

Chapter 3

6

3.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 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

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 3.3 Android Runtime

Chapter 3

7

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 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.

Chapter 3

8

3.4 Linux Kernal

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 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

Chapter 4

9

Architecture for Secure Data Storage

Figure 3 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 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

Chapter 4

10

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.

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.

Chapter 4

11

4.1 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.

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 to store 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.

Chapter 5

12

Execution Environment

Figure 4 Regular Java Execution Process

Chapter 5

13

Figure 5 Android Execution Environment

Chapter 5

14

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 byte code 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 packages or classes specified to the Sun Microsyatem platform

3. 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.

5.1 The Dalvik Virtual Machines

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 byte code34, instead it uses

its own byte code 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

Chapter 5

15

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.

Chapter 6

16

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 on ReceiveIntent() method, and then returns from the function. Once it

returns, the system considers that Intent Receiver 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 Intent Receiver, 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.

Chapter 6

17

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.

Chapter 6

18

6.1 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.

Chapter 6

19

6.2 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

Fig 6 –Eclipse ADT

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.

Chapter 6

20

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.

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.

Chapter 7

21

LIST OF ANDROID versions from Android Alpha to lollipop

Version Name Released Date

Android 1.0 Alpha Sep 2008

Android 1.1 Beta Feb 2009

Android 1.5 Cupcake April 2009

Android 1.6 Donut Sep 2009

Android 2.0-2.1 Eclair Oct 2009

Android 2.2-2.2.3 Froyo May 2010

Android 2.3-2.3.7 Ginger Bread Dec 2010

Android 3.0-32.6 Honey Comb Feb 2011

Android 4.0-4.0.4 Ice cream Sandwich Oct 2011

Android 4.1-4.3.1 Jelly Bean June 2012

Android 4.4-4.4.4 Kit Kat Sep 2013

Android 5.0 Lollypop* Not releases just announced

Chapter 8

22

ABOUT PROJECT

The title of this project is “Phone Book Directory”. The main purpose of phone

book is to manage phone contact daily operation efficiently. This system basically

directory has been frequently in use in our daily life. We commonly see directory

installed in, mobile phone etc. Phonebook Directory application provides the ability

to search, view, and manage entries in a directory. Mobile Directory application

should allow any subscriber with any type of mobile device. The search result data

loads directly to the mobile screen and gives the user option to CALL, SAVE, VIEW,

SEND TO FRIEND or DISCARD. Mobile Directory eliminates the need to call any

other call center.

8.1 Project Requirement

In the development of this application, we have used ANDROID as Front End and

SQLITE as Back End.

8.1.1 Front End

Android- version: 4.3(Jelly Bean)

Chapter 8

23

8.1.2 Back end

SQLite

Contains the SQLite database management classes that an application would use to

manage its own private database.

Applications use these classes to manage private databases. If creating a content

provider, you will probably have to use these classes to create and manage your own

database to store content. See Content Providers to learn the conventions for

implementing a content provider. See the Notepad Provider class in the Notepad

sample application in the SDK for an example of a content provider. Android ships

with SQLite version 3.4.0.

Chapter 8

24

8.2 Summary of project

Phonebook Directory allows the user to store the contact details and the person

details.This software allows storing the details of all the data related to person

whose add your phonebook. The implementation of the system in the organization

will considerably reduce data entry, time.

This project is helpful to track all the number and person information. The software

will be able to handle all the necessary information. The Phonebook Directory

process is made computerized to reduce human errors and to increase the

efficiency. The main focus of this project is to lessen human efforts. The

maintenance of the records is made efficient, as all the records are stored in the

database, through which data can be retrieved easily. The navigation control

(tabular form) is provided in all the forms to navigate through the large amount

of records.

The computerization of this project will not only improve the efficiency but will

also reduce human stress thereby indirectly improving human resources.

Chapter 9

25

Snapshots

9.1 Search View

Chapter 9

26

9.2 Add Contact View

Chapter 9

27

9.3 Action View

Chapter 9

28

9.4 Update View

Chapter 9

29

9.5 Show Details View

Chapter 9

30

9.6 Sending SMS View

Chapter 9

31

9.7 Sending Email View

32

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

33

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

34

Future Scope

Android Developers have built outstanding careers through the development activity.

Demand for new apps and enhancing the existing apps is increasing.

It has opened a new stream of technological advancements. And interestingly, there

seems no end to experimenting and evolving new applications and mobile phones using

this innovative and dynamic technology.

The Android phonebook gets updated automatically based on caller’s voice, gets sorted

by itself and even stores emotional state of a caller.

The Android phonebook take backup to contact.

35

References

1. http://code.google.com/android/

2. http://www.openhandsetalliance.com/

3. http://en.wikipedia.org/wiki/Android_(mobile_phone_platform)

4. http://googleblog.blogspot.com