A Minor Project Report

on
BILL GENERATOR
(ANDROID APPLICATION)
Submitted
In partial fulfillment
For the award of the degree of

Bachelor of Technology
In
Information Technology

Project Guide:
Mr .Ashish Payal
Assistant Professor
USICT,GGSIPU

Submitted by:
Gurteg Sawhney
Roll No: 01416401511
B.Tech IT 7th Semester

USICT,GGSIPU

University School of Information and Communication Technology,

GGS Indraprastha University,Delhi

CERTIFICATE
This is to certify that the project report entitled Bill Generator(ANDROID Application)
done by Mr Gurteg Sawhney, Roll NO.01416401511 is an authentic work carried out by
him at University School of Information and Communication Technology under my
guidance.The matter embodied in this project work has not been submitted earlier for the
award of any degree or diploma to the best of my knowledge and belief.

Date:

Signature of the Guide

Mr. ASHISH PAYAL
Assistant Professor
USICT,GGSIPU

ACKNOWLEDGEMENT
I am deeply indebted to my project guide Mr.Ashish Payal ,Assistant Professor in
University

School

of

Information

and

Communication

Technology,

whose

help,stimulating suggestions and encouragement helped me during the working with the
project on Bill Generator(ANDROID Application).

Gurteg Sawhney
01416401511
B.Tech IT,7th semester
USICT,GGSIPU

List of figures

CHAPTERS

ii

PAGE NO

1) Introduction
1.1 Project Background
1.2 Overview
1.3 Objective
1.4 Development Requirements

7
8
9

2) Preparation
2.1 Introduction
ii) Introduction to Android
iii) Features of Android
iv) Android Architecture
v) Application Framework
vi) The Dalvik Virtual Machine
vii) Lifecycle of an Android Application

10
11-12
13
13-14
14
15
16
17-20

3) Requirement Specifications
i) Functional Requirements
ii) Non - Functional Requirements

22
23-24
24-26

4) Requirement Analysis and Design

i) Proposed System Environment
ii) About Front End
iii) About Back End

28
29
30-34
35-36

5) Project Implementation

37-68

5.1 Using the Emulator

5.2 Project Screenshots
6) Conclusion
6.1 Scope for further Improvement
Bibliography

69-80
81-84

89

List of Figures

Chapter 1
Introduction

1.1 Project Background

The purpose of the project is to present the requirement of an Android application of

Mobile Bill Generator. The project thus calculates the mobile bills (call and sms
charges)automatically. It does almost every work which is related to automatic mobile
billing system,the same that we receive from our mobile service providers monthly
postpaid bill. Bill Generatoris developed as per seeing the requirement to give brief
bill details to the person and thus removes any ambiguity or confusion created when the
service providers postpaid bill is generated. The person can tally the mobile bills
generated by the android application with the service providers postpaid bill. Thus a new
software has been proposed to provide greater flexibility ,user-friendliness and a sense of
satisfaction as the the postpaid bills may pop up with some errors .

1.2 Overview

This application is based on the features of Background services and SQLite Database for
data storage and retrieval.Android supports applications and services designed to run in
the background while our application isnt being actively used.Modern mobiles and
tablets are by nature multifunctional devices,however,their screen sizes and interaction
models mean that generally only one interactive application is visible at any time.

Platforms that dont support

background execution limit the viability of

applications that dont need your constant attention.Background services make it possible
to create invisible application components that perform automatic processing without
direct user action.
In our application,once the user makes a call or sends a message to any
number,the corresponding number,the duration of the call,date and time of the call or sms
are stored in the database.The call rates per second and the sms charges can be set as per
your service providers charges.The duration of the call in sec is multiplied by thecall rate
per second and similarly the sms charge is multiplied by the number of messages sent to a
number,the total bill is generated by adding the previously obtained call and sms charges.
.
The purpose of the project is to present the requirement of the Computerization of
Telephone Billing System. The project thus calculates the telephone bills automatically. It
does almost every work which is related to automatic telephone billing connection system
via- new connection , customer record modification, viewing customer records & all
works related to rate of bills, meter readings in addition to bill calculation and bill
generation. Telephone Billing

System is developed as per seeing the increasing

requirement to speed up the work and incorporate a new work culture. Thus a new
software has been proposed to reduce manual work, improving work efficiency, saving
time and to provide greater flexibility and user-friendliness as the system previously
followed was totally manual one with lots of errors.

1.3 Objective
The objectives of this project were to create an Application:
i.

That can give the call details such as mobile no. on which call was made,date and

time of the call,duration of the call and the call charges for the last 15 /30 days.
ii.

That can give the sms details such as mobile no. on which the sms was sent,date and

time of the sent message and the sms charges for the last 15/30 days.
iii. That generates a mobile bill for all the calls and all the messages sent by the userin
the last 15/30 days.

1.4 Development Requirements

This process was developed on Eclipse using the android developer toolkit. It
was developed in android api level 7. This makes it available to a majority of
android users.
We decided to use Eclipse because it is the google approved development
environment and as such has the greatest level of online upport .android
applicaton are developed uing the java framework.the app was run on sony xperia
u running android 2.3.7

Operating System:Windows 7

Programming Languages:Java

Mobile Technology:Adroid 2.2 or higher

Softwares:

Eclipse Indigo

Android SDK

SQLite Database Browser 2.0

Chapter 2
Preparation

2.1 Introduction
System analysis is the performance management and documentation of activities related
to the four life cycle phases of any software namely:

The Study Phase

The Design Phase

The Development Phase

The Operators Phase

System analysis is a vast field of study through which system analyst puts his thoughts
and searches for the solution of problem. He has to get a clear idea of what he has in hand
and what he has to produce. He has to extract the essence of expectations. He has to
satisfy the user in the very possible way. System analysis needs and should include the
following steps of study:
Study of current methods, the basic inputs available and output desired.
The splitting of a variable inputs into (.dbf) files so as to reduce
redundancy and increase consistency.
Give the idea of key field (if any) .

 Ideas regarding code generation.

Software Analysis starts with a preliminary analysis and later switches on to a detailed
one. During the preliminary analysis the Analyst takes a quick look at what is needed and
whether the cost benefits. Detailed analysis studies in depth all the cornered factors,
which builds and strengthens the software.
A system study is a step-by-step process used to identify and then developed the software
needed to control the processing of specific application. System study is also known as
SDLC (Software Development Life Cycle).
Steps of SDLC are:
1. Problem Definition
2. Feasibility Study
3. System Analysis
4. System Design
5. Implementation
6. Post Implementation
7. Maintenance

2.2 Introduction to Android

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.

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

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

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

2.3 Features of Android

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 .

2.4 Android Architecture

The following diagram shows the major components of Android

Fig. 2.1: Architecture of Android OS

2.5 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

2.5.1 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

SQLite - a powerful and lightweight relational database engine available to all

applications.

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

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

2.5.3 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
2. Bluetooth 1.2 and Wi-Fi support
3. Digital audio support for mp3 and other formats
4. Support for Linux and other third-party operating systems
5. Java hardware acceleration and support for Java applications
6. Qcamera up to 6.0 megapixels
7. gpsOne solution for GPS

2.6 The Dalvik Virtual Machine

The Dalvik virtual machine is an interpreter only machine optimized for use on
low powered, low memory devices like phones. Notably, Dalvik does not make use of
just in time (JIT) Compilation to improve the performance of an application at runtime.
Furthermore, Dalvik is not a Java virtual machine. This is because Dalvik is unable to
read Java bytecode34, instead it uses its own bytecode format called dex. Google
claims this format allows battery power to be better-conserved at all different stages of

execution of an application. This means that standard Java SE applications and libraries
cannot be used directly on the Android Dalvik virtual machine.
Dalvik however stands at the center of the Android value proposition. Its low
electrical power consumption, rich libraries, and unified, non-fragmented application
programming interfaces make it stand out, or so Google hopes, over the fragmented
ecosystem that is Java ME35 today.
Furthermore, since Dalvik uses the Java programming language but not the Java
execution environment (JVM), Google is free to develop Android without the need to
license or obtain certification from Sun Microsystems Inc, the legal owner of the Java
trademark and brands.

2.7 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.
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 3
Requirement
Specifications

This chapter will cover the initial stage of development in which the various requirements
for the mobile application is gathered . the requirements are grouped into functional and
non- functional requirements.

3.1 Functional Requirements

The application should satisfy the following functional requirements:
i.

Provide user with the ability to view the total call and sms tariffs.

ii.

Allow user to save the call and sms rate as per his/her service provider.

iii.

Allow the user to set a password for logging in.

iv.

Keep log of the call and sms details for the last 15/30 days.

3.2 Non Functional Requirements

i.

Performance: The system should be prompt in response to user actions,the

application should have minimum lag time.

ii.

Usability: The UI of the application should be fairly simple for any user to
understand.

iii.

Dependency: The application should have a stable network connection,also

the background service should not not be killed by any other process running
in the phone.

iv.

Backward Compatability: The application should function without any faults

from the 4.0.3 version of android to version 2.2.

v.

Recovery: The application should be able to recover from an error upon relaunch and the data should rollback to the state prior to the error.

Chapter 4
Requirement
Analysis and Design

Chapter 5
Project Implementaion

5.1 Using the Emulator

Fig. 5.1 Android Emulator

5.2 Project Screenshots

Fig. 5.2 Bill Generator App

Fig.5.3: login page

Fig 5.4 Main Activity

Fig .5.5: Backup options

Fig 5.6: call/sms charge(as per service provider)

fig

Fig 5.8: total sms charges

Chapter 6
Conclusion

SCOPE FOR FURTHER IMPROVEMENT

Every project whether large or small has some limitations no matter however diligently
developed. In some cases limitations is small while in other cases they may be broad also.
The android app has got some limitations. Major areas where modifications can be done
are as follows:
Our app does not give the data usage charges of the customer so further it can be
improved.
It should give the data usage details in MBs and also the charges for the data
used over a period of time.
.

BIBLIOGRAPHY

1.

Androids Programmer Guide- McGraw Hill.

2.

http://www.android.com - Android Official Webpage

3.

http://www.androidwiki.com Android Wiki

4.

http://en.wikipedia.org/wiki/Android_(operating_system)Wikipedia

Information
5.

www.developer.android.sdk/index.html - SDK manager

6.

http://www.webopedia.com/TERM/A/Android_SDK.html

7.

http://developer.android.com/guide/basics/what-is-android