ABSTRACT

The objective of this project is to create an application “Theft Monitoring” where we are able to find our lost phone easily.

Sometimes we accidently tend to replace our phone somewhere and we end up searching for it. Yet sometimes we are lucky to get our phones back but sometimes we never get it back.

Hence to avoid such situations and keeping the recent demand and the greed for phones in mind we have decided to develop this application “theft monitoring”.

This application gets activated as soon as the person who has stolen the phone changes the sim and switches on the phone. The user will not know that an automatic message is being sent to the predefined number .

This message will contain the sim details as well as the location details. This information will be sent as a message to the destined number till the application is uninstalled in the mobile. This will be like a torture to the user and makes it easy to find the location of the phone and track the user.

The location of the device is found using GPS and the details are sent to the predefined number in the form of a message as soon as the user changes the sim and switches on the phone .

The application also consists of the setting of the number to which the message regarding the sim and the location details are to be sent .

In this application all the operation are done in the background using the concept called “service”.

Thus “theft monitoring” is a useful application which helps us to track and find the device in an effective manner.

INTRODUCTION

Nowadays since the usage of phones has increased, the demand for creative and new applications has also increased .

The security of mobile phones play an important role hence we decided to create a project called “theft monitoring”.

PROJECT ANALYSIS

It is an application where it helps the user to find out where the device is if it is stolen. when the person steals the phone and changes the sim an automatic message which displayes the location of the device, sim number, phone number, imsi number will be sent to a number which we specify in the settings . thus the device that has been stolen will be found easily .

In our application we have the facility to specify the num to which a msg about the location.

The application also consists of the setting of the number to which the message regarding the sim and the location details are to be sent.

In this application all the operation is done in the background using the concept called “service”.

A special feature of this application is that we have provided a long press for the specification of the broadcast receiver number in the application itself which the user will not know. The screen that will be displayed to him

SCOPE:

The scope of this project is that we will be able to get our device back and we will get the sim details even if the person has changed the sim. In addition to that we will also get the phone number and the location details which make the theft monitoring action an easy task.

The objective is to design a simple, intuitive interface with limited screen estate for the monitoring of the theft action.

FEATURES:

The main feature of this project is that this application does not need any special indication or operation, the sim and location details are automatically sent as a message to the destined number as soon as the user changes the sim and switches on the phone.

Another feature of this project is that we have the option to put the sim in white list, so that it traces only if a new sim has been inserted by another person and not our permanent number.Usually when a device is lost we have applications where only the location of the phone is sent to another phone but in our project the sim details and the location details are sent to the destined number making the tracking process a less tedious job.

Our project works in such a way that the user will not be knowing that the sim and the location details is being sent as a message to a specified number as soon as he changes the sim switches on the phone.Since nowadays the craze and the greed for phones has increased it is becoming highly difficult to protect and safeguard our devices Hence we have proposed this project in such away to get our devices back even if it gets stolen.

Existing system with limitations:

In the existing phones we only have the facility where the location of the device is tracked and is sent back to the user. In such cases if the user has lost his phone and the person who has taken the device changes the sim and replaces it with another sim then the tracking of location will be of no use since the sim has been replaced with another sim . and even if ther is a provision of sending the location of the device to another android phone ,the information is not enough to find out the location of the device.

This application combines both the details that is the sim and the location details and sends it in a message to the predefined number making the tracking of the device an easy task.

Proposed system with features:

In our application “theft monitoring” gives both the sim details as well as the location details of the device which has been stolen.

As soon as the user removes the sim and replaces it with another sim the GPS tracks the location of the device and sends it in the form of a message to the predefined number which has been set by the owner of the phone.

Additionally this application takes all the sim details such as phone number, sim serial number and the imsi number and sends these details as a message to the predefined number.

2. BACKGROUND

2.1 Theoretical Background:

Android

Android is a Linux-based operating system for mobile devices such as smartphones and tablet computers. It is developed by the Open Handset Alliance, led by Google, and other companies

It is a mobile operating system that is based on a modifi ed version of Linux. It was originally developed by a startup of the

same name, Android, Inc. In 2005, as part of its strategy to enter the mobile space, Google purchased Android and took over its development work (as well as itsdevelopment team). Google wanted Android to be open and free; hence, most of the Android code was released under the open source Apache License, which means that anyone who wants to use Android can do so bydownloading the full Android source code. Moreover, vendors (typically hardware manufacturers) can add their own proprietary extensions to Android and customize Android to differentiate their products from others. This simple development model makes Android very attractive and has thus piqued the interest of many vendors. This has been especially true for companies affected by the phenomenon of Apple’s iPhone, a hugely successful product that revolutionized the smartphone industry. Such companies include Motorola and Sony Ericsson, which for many years have been developing their own mobile operating systems. When the iPhone was launched, many of these manufacturers had to scramble to find new ways of revitalizing their products. These manufacturers see Android as a solution — they will continue to design their own hardware and use Android as the operating system that powers it.

The main advantage of adopting Android is that it offers a unified approach to application development. Developers need only develop for Android, and their applications should be able to run

on numerous different devices, as long as the devices are powered using Android. In theworld of smartphones, applications are the most important part of the success chain. Device manufacturers therefore see Android as their best hope to challenge the onslaught of the iPhone, which already commands a large base of applications.

Home screen displayed by Samsung Galaxy Nexus, running Android 4.0 "Ice Cream Sandwich"

Features of AndroidBecause Android is open source and freely available to manufacturers for customization, there are no fixed hardware or software configurations. However, Android itself supports the following features:

Storage — Uses SQLite, a lightweight relational database, for data storage. Chapter 6

discusses data storage in more detail. Connectivity — Supports GSM/EDGE, IDEN, CDMA, EV-

DO, UMTS, Bluetooth (includesA2DP and AVRCP), Wi-Fi, LTE, and WiMAX. Chapter 8 discusses networking in more detail

Messaging — Supports both SMS and MMS. Chapter 8 discusses messaging in more detail.

Web browser — Based on the open source WebKit, together with Chrome’s V8 JavaScript

engine Media support — Includes support for the following media:

H.263, H.264 (in 3GP or MP4container), MPEG-4 SP, AMR, AMR-WB (in 3GP container), AAC, HE-AAC (in MP4 or

3GP container), MP3, MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF, and BMP

Hardware support — Accelerometer Sensor, Camera, Digital Compass, Proximity Sensor,

and GPS Multi-touch — Supports multi-touch screens Multi-tasking — Supports multi-tasking applications Flash support — Android 2.3 supports Flash 10.1. Tethering — Supports sharing of Internet connections as a

wired/wireless hotspot

Foundation:

Android, Inc. was founded in Palo Alto, California, United States in October, 2003 by Andy Rubin Danger Rich Miner (co-founder of Wildfire Communications, Inc.) Nick Sears (once VP at T-Mobile), and Chris White (headed design and interface development at WebTV) to develop, in Rubin's words "...smarter mobile devices that are more aware of its owner's location andpreferences".Despite the obvious past accomplishments of the founders and early employees, Android Inc. operated secretly, revealing only that it was working on software for mobile phones. That same year, Rubin ran out of money. Steve Perlman, a close friend of Rubin, brought him $10,000 in cash in an envelope and refused a stake in the company.

Design:

Architecture diagram

Features

Connectivity:Android supports connectivity technologies including GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, NFC and WiMAX.

Multiple language support: Android suspports multiple languages.

Web browser:The web browser available in Android is based on the open-source WebKit layout engine, coupled with Chrome's V8 JavaScript engine. The browser scores 100/100 on the Acid3 test on Android 4.0.

Java support:While most Android applications are written in Java, there is no Java Virtual Machine in the platform and

Java byte code is not executed. Java classes are compiled into Dalvik executables and run on Dalvik, a specialized virtual machine designed specifically for Android and optimized for battery-powered mobile devices with limited memory and CPU. J2ME support can be provided via third-party applications.

Media support:Android supports the following audio/video/still media formats: WebM, H.263, H.264 (in 3GP or MP4 container), MPEG-4 SP, AMR, AMR-WB (in 3GP container), AAC, HE-AAC (in MP4 or 3GP container), MP3, MIDI, Ogg Vorbis, FLAC, WAV, JPEG, PNG, GIF, BMP,Web

Additional hardware support:Android can use video/still cameras, touchscreens, GPS, accelerometers, gyroscopes, barometers, magnetometers, dedicated gaming controls, proximity and pressure sensors, thermometers, accelerated 2D bit blits (with hardware orientation, scaling, pixel format conversion) and accelerated 3D graphics

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

Activities:

An Activity is an application component that provides a screen with which users can interact in order to do something, such as dial the phone, take a photo, send an email, or view a map. Each activity is given a window in which to draw its user interface. The window typically fills the screen, but may be smaller than the screen and float on top of other windows.

An application usually consists of multiple activities that are loosely bound to each other. Typically, one activity in an application is specified as the "main" activity, which is presented to the user when launching the application for the first time. Each activity can then start another activity in order to perform different actions. Each time a new activity starts, the previous activity is stopped, but the system preserves the activity in a stack (the "back stack"). When a new activity starts, it is pushed onto the back stack and takes user focus. The back stack abides to the basic "last in, first out" stack mechanism, so, when the user is done with the current activity and presses the Back button, it is popped from the stack (and destroyed) and the previous activity resumes. (The back stack is discussed more in the Tasks and Back Stack document.)

Creatinsg an Activity:

To create an activity, you must create a subclass of Activity (or an existing subclass of it). In your subclass, you need to implement callback methods that the system calls when the activity transitions between various states of its lifecycle, such as when the activity is being created, stopped, resumed, or destroyed. The two most important callback methods are:

onCreate()You must implement this method. The system calls this when creating your activity. Within your implementation, you should initialize the essential components of your activity. Most importantly, this is where you must call setContentView() to define the layout for the activity's user interface.

onPause()The system calls this method as the first indication that the user is leaving your activity (though it does not always mean the activity is being destroyed). This is usually where you should commit any changes that should be persisted beyond the current user session (because the user might not come back).

Fig:Activitylifecycle

Service : It is an application component that can perform long-running operations in the background and does not provide a user interface. Another application component can start a service

and it will continue to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform interprocess communication (IPC). For example, a service might handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background.

A service can essentially take two forms:

StartedA service is "started" when an application component (such as an activity) starts it by calling startService(). Once started, a service can run in the background indefinitely, even if the component that started it is destroyed. Usually, a started service performs a single operation and does not return a result to the caller. For example, it might download or upload a file over the network. When the operation is done, the service should stop itself.

BoundA service is "bound" when an application component binds to it by calling bindService(). A bound service offers a client-server interface that allows components to interact with the service, send requests, get results, and even do so across processes with interprocess communication (IPC). A bound service runs only as long as another application component is bound to it. Multiple components can bind to the service at once, but when all of them unbind, the service is

destroyed.Although this documentation generally discusses these two types of services separately, your service can work both ways—it can be started (to run indefinitely) and also allow binding. It's simply a matter of whether you implement a couple callback methods: onStartCommand() to allow components to start it and onBind() to allow binding

Menus: Options menu and action bar:

The options menu is the primary collection of menu items for an activity. It's where you should place actions that have a global impact on the app, such as "Search," "Compose email," and "Settings." If you're developing for Android 2.3 or lower, users can reveal the options menu panel by pressing the Menu button.On Android 3.0 and higher, items from the options menu are presented by the action bar as a combination of on-screen action items and overflow options. Beginning with Android 3.0, the Menu button is deprecated (some devices don't have one), so you should migrate toward using the action bar to provide access to actions and other options.

.Context menu and contextual action mode:

A context menu is a floating menu that appears when the user performs a long-click on an element. It provides actions that affect the selected content or context frame.

When developing for Android 3.0 and higher, you should instead use the contextual action mode to enable actions on selected content. This mode displays action items that affect the selected content in a bar at the top of the screen and allows the user to select multiple items.

Dialogs: AlertDialog :

A dialog that can manage zero, one, two, or three buttons, and/or a list of selectable items that can include checkboxes or radio buttons. The AlertDialog is capable of constructing most dialog user interfaces and is the suggested dialog type.

ProgressDialog: A dialog that displays a progress wheel or progress bar. Because it's an extension of the AlertDialog, it also supports buttons.

DatePickerDialog : A dialog that allows the user to select a date.

TimePickerDialog :

A dialog that allows the user to select a time.

Custom Dialog:

If you want a customized design for a dialog, you can create your own layout for the dialog window with layout and widget elements. After you've defined your layout, pass the root View object or layout resource ID to setContentView(View).

3.3 Feasibility Study:

Feasibility study is an important phase in the software development process. It enables the developer to have an assessment of the product being developed. It refers to the

feasibility study of the product in terms of outcomes of the product, operational use and technical support required for implementing it.

Feasibility study should be performed on the basis of various criteria and parameters.

The various feasibility studies are:

Operational feasibility

Technical feasibility

Economic feasibility

3.3.1 Operational Feasibility:

The aspect of study is to check the level of acceptance of the system by the user. This includes the process of training the user to use the system efficiently. The user must not feel threatened by the system, instead must accept it as a necessity. The level of acceptance by the users solely depends on the methods that are employed to educate the user about the system and to make him familiar with it. His level of confidence must be raised so that he is also able to make some constructive criticism, which is welcomed, as he is the final user of the system.

3.3.2 Technical Feasibility:

This study is carried out to check the technical feasibility, that is, the technical requirements of the system. Any

system developed must not have a high demand on the available technical resources. This will lead to high demands on the available technical resources. This will lead to high demands being placed on the client. The developed system must have a modest requirement, as only minimal or null changes are required for implementing this system.

3.3.3 Economic Feasibility:

This study is carried out to check the economic impact that the system will have on the organization. The amount of fund that the company can pour into the research and development of the system is limited. The expenditures must be justified. Thus the developed system as well within the budget and this was achieved because most of the technologies used are freely available. Only the customized products had to be purchased.

As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system.

This section of the requirements document provides use cases on the functional aspects for the portable theft monitoring as requested by the participants of the study in the previous section.

3.4 Software Requirement Specification

Front End : Java Back End : Sqlite Operating System : Windows-xp Frame Work : Android

Hardware Requirements:

Processor : Intel Pentium-IV and above Hard disk : 500GB Min. RAM : 2GB Min. & Above Others : If any Applicable

4.DESIGN

4.1 Unified Modeling Language:

The UML’s four structural diagram exists to visualize, specify, construct and document the static aspects of system. Just as the static aspects of a house encompass the existence and placement of such things as walls, doors, windows, pipes, wires and vents. So to do the static aspects of a software system encompass the existence and placement of such things classes, interfaces, collaborations, components and nodes.

Relations:

Dependency:

Dependency is a semantic relationship between two things in which change to one thing may affect the semantics of other things.Graphically a dependency rendered as a dashed-line, possibly directed occasionally including a label.

Fig: Dependency

Association:

Association is a structural relationship that describes set of links.

a link being a connection among objects. Aggregation is a special kind of association a structural relationship between a whole and its parts.

It is graphically rendered as a solid-line. Such as multiplicity and role name _________________

Employer employee

Fig: Association

Generalization:

Generalization is a specialization/generalization relationship in which objects of specialized element (child) are substitutable for object of the generalized element (parent).in this way the child shares the structure and behavior of the parent.

Graphically rendered as a solid-line with a hollow over-head

pointing to the parent.

Fig: Generalization

Realization:

A realization is a semantic relationship between classifiers. Where in one classifier specifies a contract that another classifier guarantees to carry-out you will encounter relationships in two places between interfaces and classes or components between use case collaborations.

Graphically rendered as cross between generalization and dependency relationships.

Fig:Realization

4.1.1 Use case Diagram:

A use case diagram shows as set of use cases and actors and their relationships. Use case diagrams are especially important in organizing and modeling behavior of a system.

4.1.2 Sequence Diagram:

A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. A sequence diagram shows a set of objects and messages sent and receive by those objects. The objects are typically named or anonymous instances of other things, such as collaborations, components and nodes. We can use sequence diagrams to illustrate the dynamic view of a system.

4.1.3 Collaboration Diagram:

Collaboration diagram:

set ph no() click button set number white list() close

Get phno() Stores ph.no() Loading app Checks sim changed or not Search location Get ph.details Get receiver ph.no

Send sms to receiver() Check location whether changed or not

App

User

4.1.4 Class Diagram:

Classes are the most important building blocks of any object-oriented language. A class is a description of a set of objects that share the same at attributes, operations, relationships, and semantics. A class is an abstraction of things that are apart of a vocabulary. A class is not an individual object, but rather represents a whole set of objects.

For Example:

Shape

-origin

move( )resize ( )

Name

Attribute

Name:

A name is a textual string. The name alone is called as simple name; a path name is a class name prefixed by the name of the package in which the class lives.

Attribute:

An attribute is a named property of a class that describes a range of values that instances of the property may hold. An attribute represents some property of the thing you are modeling that is shared by all objects of that class.

Operations:

An operation is the implementation of a service that can be requested from ay object of the class to effect behavior.

Class may have any number of operations or no operation at all.

Operation

Class diagram:

User Application Device

Mobile Number 1 1 Sim Number Sim Number IMEI IMEI Open() Device ID Device ID Set Mobile Number() Close() get Mobile Number() Set Sim in White List() Check Number white Accessing

list or not() Check Sim changed or not() Network

Get sim & device details() & Send sms of details() GPS() Updates location() Check locatiod provider()

Get Location

Provider Details Longitude

4.1.5Activity Diagram:

An activity diagram is essentially a flow chart, showing flow of control from activity to activity. Activity diagrams may stand alone to visualize, specify, construct and document the dynamics of a society of objects or they may be used to model the flow of control of an operation.

Elements Symbols

Initial state

Final state

Action state

Control flow

start

User

No

Yes

NO stop

6.TESTING

The Android testing framework, an integral part of the development environment, provides an architecture and powerful

Application

Set Mobile Number

Close

Check in Background Sim Details

Get Sim Details

Search

Location

Get Location

No Location

Send SMS of Sim Details

Location Details

tools that help you test every aspect of your application at every level from unit to framework.

The testing framework has these key features:

Android test suites are based on JUnit. You can use plain JUnit to test a class that doesn't call the Android API, or Android's JUnit extensions to test Android components. If you're new to Android testing, you can start with general-purpose test case classes such as AndroidTestCase and then go on to use more sophisticated classes.

The Android JUnit extensions provide component-specific test case classes. These classes provide helper methods for creating mock objects and methods that help you control the lifecycle of a component.

Test suites are contained in test packages that are similar to main application packages, so you don't need to learn a new set of tools or techniques for designing and building tests.

The SDK tools for building and tests are available in Eclipse with ADT, and also in command-line form for use with other IDES. These tools get information from the project of the application under test and use this information to automatically create the build files, manifest file, and directory structure for the test package.

The SDK also provides monkeyrunner, an API testing devices with Python programs, and UI/Application Exerciser Monkey, a

command-line tool for stress-testing UIs by sending pseudo-random events to a device.

This document describes the fundamentals of the Android testing framework, including the structure of tests, the APIs that you use to develop tests, and the tools that you use to run tests and view results. The document assumes you have a basic knowledge of Android application programming and JUnit testing methodology.

The following diagram summarizes the testing framework

Test Structure: Android's build and test tools assume that test projects are

organized into a standard structure of tests, test case classes, test packages, and test projects.

Android testing is based on JUnit. In general, a JUnit test is a method whose statements test a part of the application under test. You organize test methods into classes called test cases (or test suites). Each test is an isolated test of an individual module

in the application under test. Each class is a container for related test methods, although it often provides helper methods as well.

In JUnit, you build one or more test source files into a class file. Similarly, in Android you use the SDK's build tools to build one or more test source files into class files in an Android test package. In JUnit, you use a test runner to execute test classes. In Android, you use test tools to load the test package and the application under test, and the tools then execute an Android-specific test runner.

AndroidTestCase:

A useful general test case class, especially if you are just starting out with Android testing, is AndroidTestCase. It extends both TestCase and Assert. It provides the JUnit-standard setUp() and tearDown() methods, as well as all of JUnit's Assert methods. In addition, it provides methods for testing permissions, and a method that guards against memory leaks by clearing out certain class references.

Component-specific test cases:

A key feature of the Android testing framework is its component-specific test case classes. These address specific component testing needs with methods for fixture setup and teardown and component lifecycle control. They also provide methods for

setting up mock objects. These classes are described in the component-specific testing topics:

Activity Testing Content Provider Testing Service Testing

Android does not provide a separate test case class for BroadcastReceiver. Instead, test a BroadcastReceiver by testing the component that sends it Intent objects, to verify that the BroadcastReceiver responds correctly.

ApplicationTestCase:

You use the ApplicationTestCase test case class to test the setup and teardown of Application objects. These objects maintain the global state of information that applies to all the components in an application package. The test case can be useful in verifying that the <application> element in the manifest file is correctly set up. Note, however, that this test case does not allow you to control testing of the components within your application package.

Instrumentation Test Case:

If you want to use instrumentation methods in a test case class, you must use InstrumentationTestCase or one of its subclasses.

The Activity test cases extend this base class with other functionality that assists in Activity testing.

Assertion classes:

Because Android test case classes extend JUnit, you can use assertion methods to display the results of tests. An assertion method compares an actual value returned by a test to an expected value, and throws an AssertionException if the comparison test fails. Using assertions is more convenient than doing logging, and provides better test performance. Besides the JUnit Assert class methods, the testing API also provides the MoreAsserts and ViewAsserts classes:

MoreAsserts contains more powerful assertions such as assertContainsRegex(String, String), which does regular expression matching.

ViewAsserts contains useful assertions about Views. For example it contains assertHasScreenCoordinates(View, View, int, int) that tests if a View has a particular X and Y position on the visible screen. These asserts simplify testing of geometry and alignment in the UI.

Mock object classes:

To facilitate dependency injection in testing, Android provides classes that create mock system objects such as Context objects, ContentProvider objects, ContentResolver objects, and

Service objects. Some test cases also provide mock Intent objects. You use these mocks both to isolate tests from the rest of the system and to facilitate dependency injection for testing. These classes are found in the Java packages android.test and android.test.mock.

Mock objects isolate tests from a running system by stubbing out or overriding normal operations. For example, a MockContentResolver replaces the normal resolver framework with its own local framework, which is isolated from the rest of the system. MockContentResolver also stubs out the notifyChange(Uri, ContentObserver, boolean ) method so that observer objects outside the test environment are not accidentally triggered.

Mock object classes also facilitate dependency injection by providing a subclass of the normal object that is non-functional except for overrides you define. For example, the MockResources object provides a subclass of Resources in which all the methods throw Exceptions when called. To use it, you override only those methods that must provide information.

These are the mock object classes available in Android

Contexts for testing :

Android provides two Context classes that are useful for testing:

IsolatedContext provides an isolated Context, File, directory, and database operations that use this Context take place in a test area. Though its functionality is limited, this Context has enough stub code to respond to system calls.

This class allows you to test an application's data operations without affecting real data that may be present on the device.

RenamingDelegatingContext provides a Context in which most functions are handled by an existing Context, but file and database operations are handled by a IsolatedContext. The isolated part uses a test directory and creates special file and directory names. You can control the naming yourself, or let the constructor determine it automatically.

This object provides a quick way to set up an isolated area for data operations, while keeping normal functionality for all other Context operations.

Running Tests:Test cases are run by a test runner class that loads the test case class, set ups, runs, and tears down each test. An Android test runner must also be instrumented, so that the system utility for starting applications can control how the test package loads test cases and the application under test. You tell the Android platform which instrumented test runner to use by setting a value in the test package's manifest file.

Seeing Test Results:

The Android testing framework returns test results back to the tool that started the test. If you run a test in Eclipse with ADT, the results are displayed in a new JUnit view pane. If you run a test from the command line, the results are displayed in STDOUT. In both cases, you see a test summary that displays the name of each test case and method that was run. You also see all the assertion failures that occurred. These include pointers to the line in the test code where the failure occurred. Assertion failures also list the expected value and actual value.

Working With Package names:

In the test environment, you work with both Android application package names and Java package identifiers. Both use the same naming format, but they represent substantially different entities. You need to know the difference to set up your tests correctly.

An Android package name is a unique system name for a .apk file, set by the "android:package" attribute of the <manifest> element in the package's manifest. The Android package name of your test package must be different from the Android package name of the application under test. By default, Android tools create the test package name by appending ".test" to the package name of the application under test.

The test package also uses an Android package name to target the application package it tests. This is set in the

"android:targetPackage" attribute of the <instrumentation> element in the test package's manifest.

A Java package identifier applies to a source file. This package name reflects the directory path of the source file. It also affects the visibility of classes and members to each other.

What to Test:

The topic What To Test describes the key functionality you should test in an Android application, and the key situations that might affect that functionality.

Most unit testing is specific to the Android component you are testing. The topics Activity Testing, Content Provider Testing, and Service Testing each have a section entitled "What To Test" that lists possible testing areas.

When possible, you should run these tests on an actual device. If this is not possible, you can use the Android Emulator with Android Virtual Devices configured for the hardware, screens, and versions you want to test.

OUTPUT SCREENS

When the application is opened the screen is appeared as below immediately after the user changes thesim and replaces it with another sim. “sorry phone version not supporting” is where we give the phone number of the broadcast reciever to whom the message is sent. Since the user should not understand such a name is given. And it doesn’t open unless and until we give it a long press.. The second screen shot is displayed when the broadcast reciever number is entered in the box.

8.CONCLUTION

Purchasing a latest and a good phone should not only be the priority of a user. What plays an important role is the maintenance and the security of the device. In such a hectic and a busy life people tend to forget the small things in their life and misplace them at times, and they end up searching for it. Our application comes in handy in such situations. “Theft monitoring” is such an application which helps us to track the device. When the user takes the device and changes the sim , the application opens and checks the location of the device using GPS. The location details along with the sim details are sent in a message to the predefined number which has been set by the owner of the device. This application helps the owner of the phone to get his phone back easily and effectively. In other phones there is no facility of getting the sim details but this application gives all the details required to get his device back. Thus this is a very useful application for every mobile user.

BIBLIOGRAPHY

References Made From:

Beginning Android 4 Application Development by Wei-Meng Lee

Beginning Android By Mark Murphy

Professional Android 2 Application Development by Reto Meier(Wrox)

Introducing Android Development with Ice Cream Sandwich by Shane Conder, Lauren Darcey

Sams Teach Yourself Java in 24 Hours (Covering Java 7 and Android) By Rogers Cadenhead

Programming Android By Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

Amazing Android Apps For Dummies by Daniel A.Begun

Developing Android Applications with Flex 4.5  By Rich Tretola

Sites Referred:

http://developer.android.com/guide/index.htmlhttp://www.codeproject.com/Articles/102065/Android-A-beginner-s-guidehttp://mobile.dzone.com/articles/fundamentals-android-tutorialhttp://mobile.tutsplus.com/tutorials/android/java-tutorial/