Online Cars System

MANSOURA UNIVERSITY FACULTY OF ENGINEERING Electronics and communications
DESIGN AND IMPLMENTATION OF
Online Cars System
Supervised by
Dr. El-saeid Marzouk

2013
Online Cars System

Teamwork:
Ahmed Adel El-Emam Azam Amr Salah Rashed El-behedy Amr Mohamed Mohamed El-shamy Mohamed Elsaeid Elsaeid Eissa Mohamed Saad Taher Nada Mohamed Mohamed Aiad Omar Mohamed Belal Shaban
TO OUR NATION
Table of Contents
Preface: About GPS Technology Receiver Clock Error __________________________________________________ 1 Geometry to the rescue! _______________________________________________ 2 System Accuracy ____________________________________________________ 2 Differential GPS ______________________________________________________3 Single-Frequency Operation ____________________________________________ 3 Everyone on the dock will have one soon _________________________________4 Chapter 1:Team Building, Mission Zero and Project Selection _____________ 6 1.1. Team Buildin___________________________________________________ 6 1.2.Project Selection ________________________________________________ 6 Chapter 2:Abstract __________________________________________________ 9 2.1. Problem Definition _______________________________________________ 9 2.2. Problem Solution (project added-value) ______________________________9 2.3.Customers needs as interpreted from the market research _____________ 10 2.4.Business Objectives of the Project _________________________________ 11 2.5. Market and Competitons__________________________________________ 11 2.6. Breakdown Structure ____________________________________________ 12 Chapter 3:Market Research ___________________________________________15 3.1.Product Planning ________________________________________________ 15 3.2. Identifying Opportunities _________________________________________ 15
3.3. Market Plan ____________________________________________________ 16 3.3.1. Compe ve Strategy __________________________________________________ 16
3.3.2. Market Segmenta on _________________________________________________ 16 3.3.3. Product Pla orm Planning ______________________________________________ 17 3.4.Allocate Pre-Project Resources and Time Planning____________________ 17 3.4.1.Resource Alloca on ___________________________________________________ 17 3.4.2.Time Planning ________________________________________________________ 18 3.5.Complete Pre-Project Planning_____________________________________ 18 3.5.1.Mission Statement ____________________________________________________ 18 3.6.Identifying Customer needs _______________________________________ 19 3.6.1.Organize the needs into a hierarchy _______________________________________ 19 3.7. Software and Hardware Tools ____________________________________ 20 3.7.1. Hardware Components ________________________________________________ 20 3.7.2.So ware components: _________________________________________________ 20 Chapter 4: Vision Scope and Project Plan ______________________________ 22 4.1 Solution Concept _______________________________________________ 22 4.1.1.Usage Analysis _______________________________________________________ 22 4.1.2. Usage Scenarios ______________________________________________________22 4.2.Scope _________________________________________________________ 24 4.2.1.Feature / Func on List _________________________________________________ 24 4.2.2.Out of Scope _________________________________________________________ 24 4.2.3.Acceptance Criteria ____________________________________________________ 25
4.2.4.Opera onal Criteria ___________________________________________________ 25 4.3.Schedule Planning ____________________________________________ 26 4.3.1.Schedule Summary ____________________________________________________ 26 4.3.2.Team Working Time table ______________________________________________ 26 4.4.Risk Identification/Statements____________________________________ 27 4.4.1.Risk Analysis _________________________________________________________ 28 4.4.2.Risk Plan ____________________________________________________________ 38 Chapter 5: Detailed Design of the Project _____________________________ 31 5.1.Software Requirements Specification (SRS) ________________________ 31 5.1.1.Overall Descrip on ____________________________________________________ 31 5.1.2.Product Perspec ve ___________________________________________________ 31 5.1.3.System Interfaces _____________________________________________________ 31 5.1.4.User Interfaces _______________________________________________________ 31 5.1.5.Hardware Interfaces ___________________________________________________ 32 5.1.6.So ware Interfaces ___________________________________________________ 32 5.1.7.Communica on Protocols ______________________________________________ 32 5.1.8.Assump ons and Dependencies __________________________________________ 32 5.1.9.Appor oning of Requirements ___________________________________________ 33 5.1.10.Specic Requirements ________________________________________________ 33 5.1.11.Func onal Requirements ______________________________________________ 33 5.1.12.Logical database Requirements _________________________________________ 34 5.1.13. Design Constraints ___________________________________________________ 35
5.1.14.Other Requirements __________________________________________________ 35 5.1.15.Priori za on of Requirements and Dependencies between them ______________ 35 5.2.System Requirements Specifications (SyRS) __________________________ 36 5.2.1.General System Descrip on _____________________________________________ 36 5.2.2.System context _______________________________________________________ 36 5.2.3.System modes and states _______________________________________________ 37 5.2.4.Major System capabili es _______________________________________________ 38 5.2.5.Major System Constraints ______________________________________________ 40 5.2.6.System Interfaces _____________________________________________________ 40 5.3.Software High Level Design Description ______________________________ 41 5.3.2.Typical Use Scenarios __________________________________________________ 41 5.3.3. Use Cases ___________________________________________________________ 43 5.4.Conceptual Design _______________________________________________ 46 5.4.1 Major System Components _____________________________________________ 46 Chapter 6: OCS navigation algorithm ___________________________________ 49 6.1 what is meaning of algorithm _______________________________________49 6.2 Dijkstra algorithm _________________________________________________49 6.2.1 Dijkstra Engine ________________________________________________________ 50 6.2.2 what it does __________________________________________________________ 50 6.2.3 how it work ___________________________________________________________ 50 6.2.4 Detailed example ______________________________________________________ 50 6.3: OCS navigation algorithm _________________________________________ 57 Chapter 7: Hardware Platform _________________________________________ 60
7.1.Introduction _____________________________________________________ 60 7.2.Requirements ____________________________________________________ 60 7.3.Solution _________________________________________________________60 7.4.Architecture _____________________________________________________ 61 7.4.1.CPU ________________________________________________________________ 62 7.4.2.GPS Receiver _________________________________________________________ 66 7.4.2.1.SiRF chipset ________________________________________________ 66 7.4.2.2.NMEA standard _____________________________________________ 67 7.4.3.Interfaces ___________________________________________________________ 69 7.4.4.Power Supply ________________________________________________________ 69 7.5. Prototype ______________________________________________________ 74 7.5.1. Selec on criteria: ___________________________________________________ 74 7.5.2. Selected Evalua on Kit for Prototyping __________________________________ 76 7.5.3. Selected GPS Receiver for Prototyping __________________________________ 79
Chapter 8: Operating System Porting __________________________________ 83 8.1. Introduction ___________________________________________________ 83 8.2.Android _______________________________________________________ 85 8.3. Android features _______________________________________________ 86 8.4. Android Architecture ___________________________________________ 89 8.5. initializing a build Environment ___________________________________ 96 8.6. Getting Linux Kernel Source Code ________________________________ 97 8.7. Configuring and Building Linux Kernel ____________________________ 98
8.8. Getting Android Source Code ____________________________________ 100 8.9. Android Build System __________________________________________ 101 8.10. Building the Android File System ________________________________ 106 8.11. U-Boot image generation _______________________________________ 108 8.12.X-loader image generation_______________________________________ 108 8.14 android system demonstration ___________________________________109 Chapter 9 : Online Cars System________________________________________114 PART A :Android programming________________________________________114 9.A.1.Android Develop tools___________________________________________114 9.A.2 Essential Command line tools ____________________________________115 9.A.3 other third-party development tools_______________________________117 9.A.4 Managing projects______________________________________________121 9.A.5 Library projects________________________________________________124 9.A.6 Development tools considerations ________________________________126 9.A.7 test projects___________________________________________________128 9.A.8 testing a library project__________________________________________129 9.A.9 building and running ___________________________________________130 9.A.10 detailed look at build project____________________________________131 9.A.11 Debugging___________________________________________________133 9.A.12 Google Maps_________________________________________________135 9.A.13 parsing the xml response ______________________________________145 PART B :Server Programming ________________________________________148 9.B.1-collecting feedback from the cars for each road _____________________148
9.B.2-Analyzing feedbacks and Sending the status for any road when requested from a car _______________________________________________________149 9.B.3-Selecting the best route between a source & destination and sending it when requested from a car _________________________________________149 Chapter 10: Documentation _________________________________________ 154 10.1. Reporting system _____________________________________________ 154 10.1.1. Project proposal __________________________________________________ 154 10.1.2 MOMs ___________________________________________________________ 155 Appendix A: Sample Documents ______________________________________ 157 A.1. Online forms used in information gathering _________________________ 157 A.2. Survey used in organizing needs into a hierarchy ____________________ 158 A.3. An Example of a proposal ________________________________________ 162 Appendix B: Source Code____________________________________________ 157 About Team members _______________________________________________ 204 References _____________________________________________________ 207
Online Cars System 2013
About GPS Technology

Amazingly precise satellite navigation receivers are now widely available and reasonably priced, thanks to the Global Positioning System (GPS). How do these little wonders figure out exactly where you are? OCS (Online Cars System ) is a system that provides modular GPS services. The modularity will be from both hardware and software aspects. Other applications will be able to make use of OCSs APIs such as location, routing etc. Other devices will also be able to connect to our system and make use of the functions provided by it via USB or serial ports. OCS is based on Google Android OS & open source software making it highly reliable, efficient and cost effective. The basic principle behind GPS is simple, and it's one that you may have used if you have done any coastal navigation: if you know where a landmark is located, and you know how far you are from it, you can plot a line of position. (In reality, it's a circle or sphere of position, but it can be treated as a line if the circle is very large.) If you plot two or more lines of position, you know that your location is the point where those lines cross. With GPS, the landmarks are a couple of dozen satellites flying about 11,000 miles above the earth. Although they are moving very rapidly, their positions and orbits are known with great precision at all times. Part of every GPS receiver is a radio listening for the signals being broadcast by these satellites. Each spacecraft continuously sends a data stream that contains its orbit information, equipment status, and the exact time. All of the information is useful, but the exact time is crucial. GPS receivers have computers that can calculate the difference between the time a satellite sends a signal and the time it is received. The computer multiplies this time of signal travel by the speed of travel to get the distance between the GPS receiver and the satellite (TIME x SPEED = DISTANCE), location in space.
Receiver Clock Error

Even with two lines of position, though, the resulting fix may not be very good due to receiver clock error. The orbiting satellites have extremely accurate (and expensive!) clocks

that use the vibrations of an atom as the fundamental unit of time, but if GPS receivers had similar atomic clocks they would be much too expensive for recreational users. Since precise measurement of time is so critical to the system - a clock error of only one thousandth of a second causes a position error of almost 200 miles - the system designers were faced with dilemma. Geometry to the rescue! It turns out that GPS receivers can use inexpensive quartz clocks (like the ones used in wristwatches) and still come up with extremely accurate position fixes as long as one extra line of position is calculated. How does this work? First, imagine two earthbound landmarks with well-known positions. For example, we'll use two BIG landmarks: the cities of Honolulu and Los Angeles. If we measure the travel time of radio waves from each of these cities to San Francisco, we can use the known speed of the radio waves to compute two lines of position that cross. If our clock is a little fast, those position lines will show us to be closer to both cities than we really are; the lines will cross, but the crossing point might be somewhere out in the ocean southwest of San Francisco. On the other hand, if our clock is too slow, the radio waves will seem to take longer to get to us, and the position lines will show us to be farther away from the landmarks than we really are. The lines might cross near Sacramento, to the northeast. System Accuracy For accurate two-dimensional (latitude and longitude) position fixes, then, we always need to get signals from at least three satellites to get around receiver clock error. Fortunately, there are now enough GPS satellites orbiting the earth to allow even three-dimensional position determination (latitude, longitude, and altitude, which requires signals from at least FOUR satellites) anytime, from anywhere in the world. The more satellites your receiver can "see" at one time, the more accurate your position fix will be, up to the system's standard accuracy limit of a few hundred feet. The U.S. Department of Defense (DOD) is responsible for the GPS system, and it reserves increased accuracy for military users. For this reason, the satellites

broadcast a coded signal - the encrypted P-code - that only special military receivers can use, providing positions that are about ten times more accurate than those available with standard receivers. In addition, random errors are put into the satellite clock signals that the civilian GPS receivers use. Not everybody is happy with this intentional degradation of accuracy, though, including the U.S. Coast Guard. Differential GPS To get around the DOD-imposed accuracy limitation, the Coast Guard is setting up "differential beacons" around the U.S. A differential beacon is a special device positioned at a precisely surveyed location; it picks up GPS satellite signals and determines the difference between its real position and the computed position based on GPS. The beacon then broadcasts this error information over a radio channel for all nearby differential equipped receivers to use. With this method, inexpensive GPS receivers can produce position information accurate to within a few inches using the standard, un-coded civilian signal. GPS receivers that can take advantage of this differential broadcast are becoming quite common, although a separate differential beacon receiver usually must be purchased. Single-Frequency Operation The way GPS receivers pick up the satellite signals is pretty interesting: all of the satellites broadcast their messages on the same frequency, but they each include a unique identification code. The receiver determines which message is from which satellite by matching the identification code with the codes stored in its memory. This is similar to standing in a room with many people speaking at the same time you can listen to what only one person is saying among all of the conversations taking place simultaneously, and you can identify a person's voice by its unique sound. In the same way, a GPS receiver picks up signals from all of the satellites in view and matches them with patterns in memory until it figures out which ones are "talking" and what they are saying.

This technique allows GPS receivers without Backyard-sized dish antennas to reliably use the tiny signals that the satellites transmit toward earth.
Everyone on the dock will have one soon
Ten years ago, it would have been hard to believe that you could buy a device capable of using the most advanced satellite technology to provide your precise location anywhere on the globe, and even harder to believe that it would be smaller than a frozen waffle and cost less than a TV set. In just a few years, though, I suspect that these technological marvels will be just about everywhere, and even cheaper. There are terrific handheld units with basic course plo ers selling for under $500, and the prices keep going down.
the page left intentionally..........
Chapter 1:Team Building, Mission Zero and Project

Selection
1.1. Team Building
the core members of the team ( Mohamed Nada , Mohamed Eissa , Ahmed Elemam) decided to start of building a strong team to work in the graduation project . they work together many times before graduation project , and the first two members were participants at EED (Egyptian Engineering Day ) at the summer of 2012 . at the summer of 2012 they started to search and think about gradua on project ideas . after they find the project idea , they search about other members to help in the implementation of the project . the team members selection based on the next criteria : - Technical abilities. - Time management and awareness of deadlines. - Motivation. - Work. - Efficiency. - Team worker. finally they decide to add four new members to their team , working to achieve success with this project .
1.2. Project Selection

Applicable and can be marketed the above words were our slogan during searching about ideas . we gathered more than 10 ideas to be evaluated. The ideas to be selected had to be mainly feasible and to have high market value. to select only one idea we must to answer about the next questions for every idea : - Does it t in 8 months? - Is it valuable in the Egyptian market? - Is it valuable in the world market?

- Will it be sponsored easily? - What is the estimated cost? - What it are the required background areas of experience and knowledge? - Are all the required resources available? - Is it a unique idea? - Will we face limitations or restrictions? and we select the more suitable idea . As an example of our ideas we think about : 1- a glass for blind people to see 2-power over IP

Chapter 2:Abstract
2.1. Problem Definition
That one of the most serious problems that we face every day is the problem of traffic congestion , Daily individuals need to move from region to region and from city to city, everyone wants to go to work and children to school, and this is often at the same time each day, leading to traffic congestion. Traffic congestion has many risks, which have a negative impact on the individual and on society. Traffic congestion affects the health of the individual because of car exhaust, and it does not affect the drivers only, but affects the residential areas around the busy roads .And thus affect the overall health of the community and the average age of the society individuals . Another serious problem, a waste of time as a result of standing for hours in crowded roads, and thus be late every day about the performance of the work required and be late for access to work schedules .Which also adversely affects the society in general. Also wasting huge amounts of fuel while standing in the crowded roads, costing the country a lot of money wasted without benefit .after solve this problem we can save these funds and use them in the form of services help the individual and society and affect it positively 2.2. Problem Solution (project added-value)
we intended to develop a system which help to solve the traffic problems . we use two main factors in our project . 1- GPS technology 2- users Feedback about the roads GPS:

- Global Navigation Satellite Systems (GNSS) is the standard generic term for satellite navigation systems (sat nav) that provide autonomous geo-spatial positioning with global coverage. - GNSS allows small electronic receivers to determine their location (longitude, latitude, and altitude) to within a few meters using time signals transmitted along a line-of-sight by radio from satellites. Receivers calculate the precise time as well as position, which can be used as a reference for scientific experiments. - The Global Positioning System (GPS) is a space-based global navigation satellite system that provides reliable location and time information in all weather and at all times and anywhere on or near the Earth when and where there is an unobstructed line of sight to four or more GPS satellites: o It is maintained by the United States government and is freely accessible by anyone with a GPS receiver. o The Egyptian market has increasing needs for GPS solutions since Egypt has lifted the ban on importing GPS receivers; the countrys National Telecommunication Regulatory Authority is now allowing the importation of devices with civilian applications provided that NTRA authorizes the type of machines based on its criteria and procedures .
Users Feedback about roads :

while the user is driving to reach his destination in a road , we ask him to leave his feedback about road traffic situation , is this road stable ? is it crowded with cars ? , is there any accident ? and then we can use users feedbacks to inform the other users about the roads they intend to use to reach their destination . and then using the data collected we can select the suitable road to every user to use to reach his destination in a short time .
2.3.Customers needs as interpreted from the market research

- knowing data about the locations and services . - Downloadable on-demand data about the traffic. - Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information

- Accurate maps. - Notifications in case of arrival to some pre-defined places. - Downloadable on-demand data about the traffic. - Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information - Accurate maps. - Notifications in case of arrival to some pre-defined places. - Implementing an efficient algorithm to find best routes. - Authentication programs in the device. - In Case of Emergency Service. - Connectivity and control with car security system. - TV receiver / Radio receiver. - Extra accessories
2.4.Business Objectives of the Project

- Satisfying a customer need which is Location detection using Global Positioning System (GPS) - The GPS devices were illegal in Egypt 4 year ago. - The Egyptian market has increasing needs for GPS solutions since Egypt has lifted the ban on importing GPS receivers; the countrys National Telecommunication Regulatory Authority (NTRA) is now allowing the importation of devices with civilian applications. -we aim to spread our system in every car . it will lead to accurate data . - also we use a SIM card in every device . this will increase mobile companies markets . - we noted that the previous systems only use the feature of feedback or the GPS navigation . then we tried to combine the two feature in a such project .
2.5. Market and Competition

- Market segments will be car drivers . - Targeted customers will buy it because: o Drivers will find it useful to find their current location besides the ability to find their best routes. - Our major competitors are the foreigner GPS companies like Navking, Mio Moov and Supernav besides the GPS-enabled mobile manufacturers such as Nokia and

Sony. - Our competitive edge is to introduce the first made-in-Egypt device which can be as reliable and efficient as imported products with lower prices. - We are using a reliable operating system (Google Android) Our tools and applications will be open-source which will allow the open development in the final product, making it an excellent choice for manufacturers to consider it as a platform to develop new products. - Our competitors have the strengths of their old repetition in the market and their technical support.
2.6. Breakdown Structure

- Description. - Team gathering and hierarchical construction. - Documentation. - Project identification and selection. - High-level design. - Requirements gathering. - Components selection. - Components purchasing and shipping. - Researching/Studying Android development. - Testing Android and compiling images. - Maps navigation application. - Researching extension manager. - Native extensions. - Routing. - Implementing extension manager. - Integrate components. - Testing. and before starting our work in the project , we have to draw a mind map . to know what exactly tasks we should do and when .
Online Cars System 2013 Our Mind Map

Chapter 3:Market Research

3.1.Product Planning
The planning process considers the project development opportunities, identified by many sources including: research, customers, learning from competitors and more.
3.2. Identifying Opportunities

- Implications of trends in lifestyles, demographics and technology for existing product categories and for opportunities: o Thousands of people travel through far distances each day; they need an easy way to provide them the route for a specific destination in both fast and easy way. o National Telecommunication Regulatory Authority (NTRA) has left the ban on importing GPS devices. o Compared to traditional GPSs, our product has the advantage of including the real-time crowdedness status of roads in the parameters of choosing the best road. o At the same time , it is easier to use in cars than the mobile applications that offers a similar service. o IN addition, the connectivity to the internet and the future usages after applica on of 4G technology are not oered in the market.
Opportunity statements
The Opportunity Statement describes the customers current situation that creates the need for the project. It may contain a statement of the customers opportunity and the impact of capitalizing on that opportunity (product innovation, revenue enhancement, cost avoidance, operational streamlining, and leveraging knowledge). It may contain a statement of the customers problem and the impact of solving the problem (revenue protection, cost reduction, regulatory compliance, alignment of strategy and technology).

It should include a statement that connects the customers opportunity/problem to the relevant business strategy and drivers. The Opportunity Statement is written concisely using a business executives voice.
All opportunity statements we have reached
- A GPS device that performs basic GPS functions. - An application (not specified) that makes use of GPS and performs some action (mostly in control field). - Real time application that provide instantaneous and dynamic updates .
3.3. Market Plan

3.3.1. Competitive Strategy
- Cost Leadership: by using Open source Operating system, Software development kits and applications instead of the proprietary ones the productions cost will be decreased significantly. - Customer focus : a solution for traffic problems more improved way than the application provide the same service in the market .
3.3.2.Target Market
-we designed our platform to be fit to car drivers needs (regular car owners or professional drivers). -Government (ambulances, police patrols, etc).
3.4.3. Product Platform Planning
3.4.Allocate Pre-Project Resources and Time Planning

3.4.1.Resource Allocation
Hardware resources : for networking we used 3G components , and we use GPS . Software resources are available and mostly open source. Personnel may not be familiar with Android as they are with other operating systems such as windows

or Linux so modifications and hacking of the operating system functions may not be as efficient as possible. Our team members are familiar with java programming language, which is the main programming language for android, so our focus will be on the applications more than on the operating system.
3.4.2.Time Planning
- Timing of product introductions: The prototype of the project is expected to be completed upon the graduation project presenta on in July 2013 . - Technology readiness: o The technology of GPS has been introduced to the world markets in the 1980s and proved to be reliable. o Android as the operating system is a reliable efficient open source operating system and has been deployed to a number of embedded systems such as smart phones.
3.5.Complete Pre-Project Planning

The Vision Statement section clearly and concisely describes the future desired state of the customers environment once the project is complete. This statement provides a context for decision-making. It should be motivational to the project team and the customer. Our vision statement:
it`s always a win win deal
3.5.2.Mission Statement
Product Description Key Business Goals Primary market Make Egyptian device can solve traffic problems and low cost . - Introduce the made in Egypt GPS device which everyone need to use it - Egyptian market. - Drivers . - First introduction - July 2013.

Secondary market Assumptions and Constrains - Global market - Government - New Egyptian product - Location detection technology - Open source software are used - Purchasers & users - Project sponsor - Manufacturing operations - Distributors & resellers
Stakeholders
3.6.Identifying Customer needs

3.6.1.Organize customer needs into a hierarchy
OCS has the ability to get updates from the Internet: - Downloadable on-demand data about the locations and services. () - Downloadable on-demand data about the traffic. () - Downloadable on-demand data about the weather. () OCS stores accurate location-related information - Pre-defined locations on the map saved along with touristic information. () - Accurate maps. () - Notifications in case of arrival to some pre-defined places. () OCS connects to the Internet - Always on Internet connection for sending the locations information. () - Packet switching capability like 3G. () OCS interacts with user in the most convenient ways - Ability for voice recognition. () - Touch screen. () - Ability for voice generation. () OCS saves time by finding best routes

- Implementing an efficient algorithm to find best routes. ( ) OCS provides entertainment - MP3 player / video player. ()
3.7. Software and Hardware Tools

3.7.1. Hardware Components
For the prototype the following items will be needed:
Components description Components name Number of required items Company Price
Development kit GPS module 3G module Touch screen SD card
Devkit8500D GPS8000-S CDMA800-U N/A N/A
1 1 1 1 1
Embest Embest Embest Embest Embest
US$329 US$59 US$79 Included Included
3.7.2.Software components:
Components description Components name Number of required items Company Price
Operating System SDK IDE
Android Android SDK Eclipse IDE
1 1 1
Google Google VisualAge
Free Free Free
Chapter 4: Vision Scope and Project Plan

4.1 Solution Concept
4.1.1.Usage Analysis
Driver: A driver needs to know his location, reach certain places using the best possible routes. Allowing to save his routes , knowing about weather condition . He or she can be driving a private car, trunk, cab, ambulance or police patrol car.
4.1.2. Usage Scenarios

Usage Scenarios define the sequences of activities the users perform within the proposed solutions environment. This information is comprised of a set of key events that will occur within the users environment. These events should be described by their objectives, key activities and their sequences, and the expected results.
4.1.2.1. Present Scenarios

Scenario 1 Normal Car driving 1. 2. 3. 4. 5. 6. 7. Ahmed is driving the car. Ahmed turns on the OCS. Ahmed checks his current location on the map. Ahmed define his destination on the map. Ahmed finds the best route to his destination. Ahmed Start to send his feedback about the road . Ahmed want to know all the event on his road , he select to see the feedback of other users . 8. There was a accident after few Kms from his location 9. The algorithm change Ahmeds road dynamically to avoid the accident

10. Ahmed reach his destination .
Scenario 2 Using OCS Accessories : 1. Ahmed want to play a song or a video. 2. Ahmed select mp3 player and select his song or video . Scenario 3 -Weather checking: 1. Ahmed clicks a bu on on the Main Screen to get Current City. 2. Device connects via Internet to a dedicated server. 3. Device gets the weather, and shows on GUI.
4.1.2.2. Future Scenarios

Scenario 1 -Activating sound recognition: 1. 2. 3. 4. 5. Ahmed want to send his feedback Ahmed presses a button on GUI or makes a gesture. Ahmed tells OCS his feedback Ahmed orders OCS to give him feedback about a road OCS replay phonetically to Ahmed
Scenario 2 using CAN bus : CAN bus (for controller area network) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host computer. CAN bus is a message-based protocol, designed specifically for automotive applications but now also used in other areas such as aerospace, industrial automation and medical equipment. 1. Ahmed want to send his feedback 2. Automatically OCS used CAN bus to send feedback to the server based on cars speed.
Scenario 2 Each Road is a community :

Users in the sane road can share road information with each other phonetically . Each road is a chat roam . Ahmed and other users in the same road can make a conversation during their travel .
4.2.Scope
The Scope places a boundary around the solution by detailing the range of features and functions, by defining what is out of scope, and by discussing the criteria by which the solution will be accepted by users and operations. The Scope clearly delineates what stakeholders expect the solution to do, thus making it a basis for defining project scope and for performing many types of project and operations planning.
4.2.1.Feature / Function List

The Feature/Function List section contains an expression of the solution stated in terms of Features and Functions. It identifies and defines the components required to satisfy the customers requirements. The Feature/Function List enables the customer and project team to understand what the project will develop and deliver into the customers environment. It is also the input to the Architectural and Technical Design Strategies. Feature GPS Internet connectivity Touch screen Storage Implementation of routing algorithms Function Determine the current position Download on-demand data like weather, services, etc Easy Interface with user Store maps, visited locations Find best paths from a source point to a destination point
4.2.2.Out of Scope
- The Out of Scope section lists and defines a limited set of features and functions

excluded from a product or solution -that is, the features and functions that fall outside its boundaries. It does not list everything that is Out of Scope; it only lists and defines the features and the functions that some users and other stakeholders might typically associate with a type of solution or product. - Out of Scope documentation helps to clarify the solution scope and explicitly states what will not be delivered in the solution. - Making our own hardware is out of scope the final product will follow open standards like PC104 for produc on, USB & serial ports as interfaces.
4.2.3.Acceptance Criteria
Acceptance Criteria define the metrics that must be met in order for the customer to understand that the solution meets the requirements. Acceptance Criteria communicates the terms and conditions under which the customer will accept the solution to the project team. - Availability on time of competition for the prototype. - Accurate working of all functions. - Elegancy, smartness and handheld shape. - Ease of operating. - Re-chargeability by more than one method (electrical ports, car batteries). - Reliability. - Reduced development cost. - Ease of use.
4.2.4.Operational Criteria
Operational Criteria define the conditions and circumstances by which the customers operations team judges the solution readiness to deploy into the production environment. Once deployed, the customer takes ownership of the solution. Operational Criteria communicate to the project team the terms and conditions under which the customer will allow deployment and ultimately sign off on the project. This information provides a framework for planning the solutions deployment. - Available budget. - Required function of the device (many combinations can be made due to the modularity).
4.3.Schedule Planning
The Project Scope section defines the tasks, deliverables, resources, and schedule necessary to deliver the customers solution. The tasks are expressed in the Master Project Approach, the Milestone Approach, the Project Estimates, and the Project Schedule. These multiple views allow the customer and project team to look at the project from different perspectives and to analyze how the work is organized. The tasks, deliverables, resources, and schedule exist at a high level of detail. These Project Scope statements provide the context for more detailed planning during follow-on project phases.
4.3.1.Schedule Summary
The Schedule Summary section identifies and compiles the collective work tasks and their calendar dates into a complete project schedule that identifies its beginning and end dates. Each major Project Milestone is identified and assigned a targeted completion date. The schedule is a consolidated schedule it includes the work and dates of all project teams. The scheduling process is iterative. During the envisioning phase, the projects Major Milestones anchor the schedule. During the planning phase, the schedule will become more granular as the work tasks are broken down. The Schedule provides the basis for the customer and/or the sponsor to verify timelines and for the project team to produce a constrained master plan from which it can validate proposed budgets, resources, and timescales.
4.3.2.Team Working Time table This section illustrates the number of hours that our team practically worked on the project from the beginning till the finals. 3 hours/day

Start date 25/9/2012 End date 1/7/2013 About 10 months About 30 days / months Available hours will equal 10*30*3 = 900 hours / individual Cumula ve working hours for team = 900 * 7 = 6300 hours
4.4.Risk Identification/Statements
The Risk and Issue Assessment section identifies and quantifies all the risks and issues that have become apparent through the envisioning phase. This section should be developed early in the phase and be updated as more information is gathered. At the close of the envisioning phase, this section should contain all risks and issues that exist at that point in time. The section includes the following: Risk Identification/Statements: a list of project risks and the conditions and consequences of each of the risks. Risk Analysis: the objective assessment of any risks significance; the calculation of risk exposure by assessing probability and impact for each item on the list of risks. Risk Plan: the actions that will prevent and minimize risks and provide a course of action if risks occur. Risk Priorities: the top x risks the project should focus on Risk identification Legality issues with GPS and tracking applications Consequence(s) The project can be banned from the market. Required components cant be Imported - No financial support for the team. - No technical support for the team. More time required for studying in the field of embedded systems. - Selection of the required components will take long time
There might be some difficulties in sponsorship deals. some technical difficulties related to working with embedded systems

Allowed time may not be sufficient for all phases Some of the iterations may not be delivered.
4.4.1.Risk Analysis
Each risk statement/identification will take a number from one to 5 where one is the least risky and 5 is the most. Risk identification Legality issues with GPS and tracking applications. There might be some difficulties in sponsorship deals. Some technical difficulties related to working with Embedded Systems. Allowed time may not be sufficient Risk analysis and prioritization 4 1 3
4.4.2.Risk Plan
Risk identification Legality issues with GPS and tracking applications. There might be some difficulties in sponsorship deals. Risk analysis and prioritization - Guarantees of academic usage to the authorities. 1. Sucient informa on about the project must be provided in the proposals sent to the potential sponsors. 2. Contac ng organiza ons and companies who provide sponsorships to universities such as ITIDA. 3. Project supervisor and professors can

help us in finding sponsors. 1. Gathering informa on about famous architectures, technologies and famous development kits. Prioritize the deliverables to guarantee that the most important iterations are delivered at time.
Some technical difficulties related to working with Embedded Systems. Allowed time may not be sufficient

Chapter 5: Detailed Design of the Project

5.1.Software Requirements Specification (SRS)
It describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are dened in detail in Sec on 2 of the SRS, and makes them easier to understand
5.1.2.Product Perspective
This subsection of the SRS puts the product into perspective with other related products and describes the context and origin of the system. - The modularity in our system will be an improvement to the existing GPS devices, which are usually un-customizable and targeted to specific applications. - Using open-source OS and applications to encourage the development and increase the space of customizability
5.1.3.System Interfaces
This lists each system interface and identifies the functionality of the software to accomplish the system requirement and the interface description to match the system. Our system will be variant depending on application needs, it may be - Touch screen friendly GUI. - Device push buttons. - Voice Recognition. - Narrator.
5.1.4.User Interfaces
There will be various interfaces depending on the application needs like: - Touch-screen-friendly GUI. - Device push buttons. - Voice recognition. - Narrator/Speakers.

5.1.5.Hardware Interfaces The GPS platform will have variant interfaces for communications - USB. - 3G. The device won't be limited to those, as the platform is designed to be modular we may extend the platform in the future to have any of the following interfaces: - 4G. - Bluetooth. - ZigBee. - CAN bus.
5.1.6.Software Interfaces
- Google Android API v.7 - revision 1 - android.location - android.database.sqlite - android.voice - Open Street Map. - Google Weather APIs.
5.1.7.Communication Protocols
The platform will have the following communication protocols to fetch information, maps, and add-ons: - CDMA2000 via 3G module to get connected to the Internet. - NMEA 0182 via GPS module to get connected to GPS satellite.
5.1.8.Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly

- If no Internet connec on available via 3G then user won't be able to send or receive feedback , or weather status , etc. - Android OS: if we had problems that prevent us from using Android, we will have to rewrite some parts of the application that depend on Android APIs. - User won't be able to find out his place if no GPS signal coverage in that location.
5.1.9.Apportioning of Requirements
This subsection of the SRS identifies requirements that may be delayed until future versions of the system. These future requirements can be: - Communication with car computer CAN bus - Voice recognition
5.1.10.Specific Requirements
This section of the SRS contains all of the software requirements to a level of detail sufficient to enable designers to design a system that can satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. These requirements should include at minimum a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output.
5.1.11.Functional Requirements
This section of the SRS contains all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. A functional requirement does not define the inner workings of the proposed system; it does not include the specification how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system. - Downloadable on-demand data about the locations and services. - Downloadable on-demand data about the traffic.

- Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information. - Accurate maps. - Notifications in case of arrival to some pre-defined places. - Always-on Internet connection for sending the locations information. - Packet switching capability like 3G or 4G . - Ability for voice recognition. - Touch screen. - Ability for voice generation. - Implementing an efficient algorithm to find best routes. - Authentication programs in the device. - Connectivity and control with car security system. - TV receiver / Radio receiver. - Extra
5.1.12.Logical database Requirements

Our system will not be remarkably dependant on database, we will only use MYSQL database to store minor information and the design is rather trivial:
So, mainly a complicated database design is not required.

5.1.13. Design Constraints
This specifies design constraints that can be imposed by other standards, hardware limitations. - Low Processing Power for mobile devices limits the number of add ons/extensions can be installed and supported. - Android constraints on application: android kills any application that lags/stops for more than 5 seconds, so we have to make the main process light-weighted one to avoid this unavoidable kill. - Small and light-weight - Provide long periods of operation and standby from a single battery charge - Low power consumption.
5.1.14.Other Requirements
- Low price - Efficiency - Usability (driving friendly interface) - Interoperability - Extensibility - Performances
5.1.15.Prioritization of Requirements and Dependencies between them

Put the requirements prioritized based on their importance to the customer HERE and requirements that are interdependent. Req. Ref. Name No. 1 Downloadable on-demand data about the locations and services 2 Downloadable on-demand data about the traffic 3 Downloadable on-demand data about the weather 4 Pre-defined locations on the map saved along with touristic information 5 Accurate maps Priority 4.3 4.5 4.5 3.7 3

6 7 8 9 10 11 12 13 Notifications in case of arrival to some predefined places GPS always connected to the internet for sending the locations information 3G connec on Voice recognition Touch screen Implementing an efficient algorithm to find best routes Narrator Radio receiver 4 3.2 4 2.5 3.5 4.5 3.5 3
5.2.System Requirements Specifications (SyRS)

5.2.1.General System Description
It describes the general factors that affect the product and its requirements.
5.2.2.System context
Appropriate diagrams and narrative are included in this sub clause, to provide an overview of the context of the system, defining all significant interfaces crossing the systems boundaries plus the actors (users and/or external services) that interact with the proposed system (System interaction with the environment is also shown). The Device will interact with user with a Touch screen to ease the accessibility especially with the Maps navigation program. User may also interact through microphone so he/she can use while being busy for example while driving.
The main system software will allow extensibility with allowing other programs to be installed and run on the device, and then interact with the system to add more functionality to the system according to user needs. New hardware can be connected using USB to allow extensions to add even more functions to the device when used by extensions based upon this new Hardware. The full-fledged installment will contain networking capabilities: - GPS module to get connected to GPS satellite. - 3G : allows connec vity to the internet to send or receive feedback and consume very important services on the web; like finding important places around you like restaurants, parking areas, cinemas ...etc.
5.2.3.System mode and state

Software Mode: - Fully Operational: All systems functions and extensions are running.

Device hardware mode: fully featured device will contain: o Touch screen LCD o Microphone and speakers o 3G for Internet access o GPS
5.2.4.Major System capabilities Components:

- Core (CPU + Memory + GPS +Power Supply + Interfaces ) - 3G / GSM - SD card - Touch screen - Audio Jack - serial interface
Functions: - Feedback updates - Position logging - Memory extensibility. - Basic location detection - Map navigation - Best device usage experience. - Services updates. - Weather and Traffic data. - Real time location tracking. - Storing offline maps.

- Storing Multi-media. - Update/Replace OS. - Development purposes.
5.2.6.Major System Constraints

- Areas with no GPS coverage - coverage obstacles, there some situation when your GPS receiver can't connect with the satellites due to being in a closed area. - Being not able to use other GPS frequencies (e.g. L2) for it being restricted to military uses; which have could provided more accurate data about position, but we hope that this would be solved if we used the new Galileo (a new satellite navigation system) in the future as it may have more accuracy. - Long battery lifetime - Small Size, lightweight and handheld device for the ease of mobility for users. - Egypt regulations has lots of constraints/reservation on tracking devices, so there may be some extensions that could be developed facing problems with these regulations. - Cost effectiveness: we have a major constraint that will limit the amount of hardware we want to add on the device.
5.2.7.System Interfaces
- USB connections: user can connect new hardware through using USB. - Internet or GSM: the device can access the internet with the provided 3G module. - User can add new data and port them on SD cards and plugging them into the device. - Mainly GPS module will be used to get location but if the user chosen a better accurate location can be calculated through GSM connection. - Most of our used protocols will be handled by Android, so it's out of our scope of interest. -serial port for purposes of debugging
Online Cars System 2013 5.3.Software High Level Design Description

5.3.1.Typical Use Scenarios
1. Need feedback of road X ?
2. Go to a restaurant?
3. His only need is to see his current location to check the map around him.

5.3.2.Use Cases
<Use-case 1: Running map navigation application> Name Description Actors Preconditions Actions Running map navigation application Opening the navigation program User The device is powered on. - User selects the source and the destination . - User navigates through the installed maps
<Use-case 2: Selecting a new destination> Name Description Actors Preconditions Actions Selecting a new destination. user selects a place to navigate to User Navigation application is running - User search/navigate map, till he finds his destination. - Mark the location, and selects navigate to.
<Use-case 3: Get short path driving instructions> Name Description Actors Preconditions Actions Postconditions Get short path driving instructions User gets the shortest path to his destination User User selects destination Device executes an algorithm and calculates the shortest path User get instruction on screen or from narrator
<Use-case 4: Activate accurate positioning> Name Activate accurate positioning

Description Actors Preconditions Actions Postconditions User use GPS to get his accurate position User Device is running GPS start connection to get the position on the map GPS gives accurate Positioning
<Use-case 5: Adding a place bookmark> Name Description Actors Preconditions Actions Adding a place bookmark Select destination in the Navigation program to save for further access User Navigation extension is running - User Navigates to specific location - User Selects the Saving option - User types a name for this location The Location is saved into device memory
Postconditions
<Use-case 6: Activating sound recognition> Name Description Actors Preconditions Actions Postconditions Activating sound recognition Makes device listen for a voice command User Device is powered on User press a button on GUI or makes a gesture Desired command is run
<Use-case 7: Playing media> Name Description Playing media Play media, using existing car sound system

Actors Preconditions Actions Postconditions User A connection to an existing sound system. - User selects media file - Select play on Car Media plays
<Use-case 8: Check traffic> Name Description Actors Preconditions Actions Check traffic Checks traffic of a selected street User Navigation Application is running - User selects a location (saved or navigated to) - User select to Check traffic - Device connects via Internet to a dedicated server - OCS gets the traffic (feedback of users ), and shows on GUI
Postconditions <Use-case 9: Check weather>
Name Description Actors Preconditions Actions
Check weather Checks weather of a selected city User - Navigation Application is running - Or Just Device is powered on - User Selects a City or use GPS to get your current city - click to get the weather - Device connects via Internet to a dedicated server - OCS gets the weather, and shows on GUI
Postconditions
Online Cars System 2013 5.4.Conceptual Design

5.4.1 Major System Components
Location API This class can be used by other extensions or native components to get information about location: GetLocation() Used to when the current location of the device is needed. TranslateLocation(location : GPSLocation) An extension can use this function to translate the GPS data to a real world address. GetAccurateLocation() If the user enabled using the GSM module to pinpoint the device location, this function will return the current location according to the GSM measurement. GetSpeed() Calculates the speed at which the device is moving with. SupscripeToLocation(location : GPSLocation, callBackFunction : method) An extension would want in some situations to be informed if the device has reached a certain location, so the Observer pattern is used here. Map Navigator component The application that will view visual maps and routes on the LCD screen; it can be regarded as a native extension (for sake of modularity we will do it so), but as its very important one it will have much more permissions and priority. EditCurrentLocation(location : GPSLocation) To inform the app that the current location of the device has changed. AddNewDestination(location : GPSLocation) Add a location to the map and mark it as a destination where the app will

draw a path to it. DeleteDestination(location : GPSLocation) Delete an added destination. UpdateDestination(location : GPSLocation) Relocate a destination to a new location. AddBookmark(location : Bookmark) Add a bookmarked place the user want to know about later and save , can be his home, a bank, a gas station or a public service MoveTo(location : GPSLocation) An extension may want to move the app screen focus to another part of the map (the device is still in its place here). Bookmarks A data structure used to add/save the user bookmarked sites.

Chapter 6 :OCS navigation algorithm

6.1what is the meaning of algorithm ?
an algorithm is a step-by-step procedure for calculations. Algorithms are used for calculation, data processing, and automated reasoning . An algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function. Starting from an initial state and initial input (perhaps empty), the instructions describe a computation that, when executed, proceeds through a finite number of well-defined successive states, eventually producing "output" and terminating at a final ending state . by a simple expression " it`s the way to make your idea tidy and clear " this idea can be a solution for a problem as we have here for our algorithm as we want to find a decent solution for route planning . Route planning problems in car navigation systems are search problems for finding an optimal route from a starting point to a destination on a road map in OCS navigation algorithm we use Dijekstra algorithm . Dijekstra considered as one of the best shortest path algorithms , so famous in networking field as it used with OSPF and IS-IS routing protocols and in artificial intelligence fields .
6.2 Dijkstra's algorithm:

Invented by Edsger Wybe Dijkstra *May 11, 1930 August 6, 2002 *Dutch computer scientist from Netherlands *Received the 1972 A. M. Turing Award, widely considered the most prestigious award in computer science *Known for his many essays on programming
6.2.1.DijkstraEngine: Dijkstra's algorithm is probably the best-known and thus most implemented shortest path algorithm. It is simple, easy to understand and implement, yet impressively efficient. By getting familiar with such a sharp tool, a developer can solve efficiently and elegantly problems that would be considered impossibly hard otherwise. 6.2.2.What It Does : Dijkstra's algorithm, when applied to a graph, quickly finds the shortest path from a chosen source to a given destination. In fact, the algorithm is so powerful that it finds all shortest paths from the source to all destinations! This is known as the single-source shortest paths problem. 6.2.3.How It Works : First let's start by defining the entities we use. The graph is made of vertices (or nodes, I'll use both words interchangeably), and edges which link vertices together. Edges are directed and have an associated distance, sometimes called the weight or the cost. The distance between the vertex u and the vertex v is noted [u, v] and is always positive.
Dijkstra's algorithm partitions vertices in two distinct sets, the set of unsettled vertices and the set of settled vertices. Initially all vertices are unsettled, and the algorithm ends once all vertices are in the settled set. A vertex is considered settled, and moved from the unsettled set to the settled set, once its shortest distance from the source has been found.
6.2.4.Detailed example :
The goal is to find a path of minimum total weight (cost) from s to t .
Initially we put all the vertices in the uncolored (black) set T and set up a possible cost function on the vertices. We set (s) = 0 which indicates that we have found a path from s to s of total weight 0 (the path with no edges). For any other vertex v we set (v) = since we havent even veri ied that an s v path exists. Lets add the -values to the picture.
The smallest -value is (s) = 0, we remove s from T, indicating that (s) = 0 represents the smallest possible total weight of a path from s to s :
We examine the edges that leave s. The edge sa gives us a path of cost 18 from s to a so we change on a to (a) = 18. Likewise, we change (c) from to the smaller value 15 :
The smallest -value on a black vertex is 15, which happens at c, so we color c:
The edge ca has weight 6, tells us we can get from s to a for a cost of (a) + (ca) = 15 + 6 = 21, which is more than 18. We leave (a) at 18. The edge cb has weight 14, tells us we can getfrom s to b for a cost of (c) + (cb) = 15 + 14 = 29, which is less than , so we change on b so that (b) = 29. The edge cd has weight 14, tellsus we can get from s to d for a cost of (d) + (cd) = 15 + 7 = 22, than so which is less , so we change on d that (d) = 22.
The smallest -value on a black vertex is (a) = 18, so we color a
Now we reexamine the -values at the uncolored neighbor of a
Now the smallest -value on T occurs at d
Recalculate (b) and (t)
The min occurs at b
Recalculate (t)
The min occurs at t
Now starting at t, find edges vw where (v) + (vw) = (w) and mark them with an arrow from v to w : since 27 + 28 = 55
Since 18 + 9 = 27, Since 0 + 18 = 18,
In this case, the cheapest path from s to t is unique, and has total cost 55
this simple example for Dijeksra algorithm demonstration explain in detail how DA works and all the concepts related to it .
Online Cars System 2013 6.3.OCS navigation Algorithm

this is the flow chart of our Algorithm :
step 1: client send his source and destination to the server step 2: the server identify nodes , which is the the main points between source and destination - these points stored in the database step 3 : the server calculate the cost to be used in Dijkstra algorithm by this equation
step 4 : run Dijektra algorithm as stated previously step 5 : send the best rout to the user to be used

Chapter 7: Hardware Platform

7.1.Introduction
In this chapter; all the mandatory hardware specifications will be taken into account; for each one of them a proper hardware solution for OCS will be discussed. Hardware is an important issue in our system because the modularity issue must be provided. This positioning application meets strict needs such as car navigation, mapping and so on .
7.2.Requirements
- Fast CPU - Suitable Memory RAM, NAND Flash - High performance - Small and light-weight - Provide long periods of operation and standby from a single battery charge - Cost-efficient - Scalability. - Ability of integration with other H.W - Provide various types of connectivity i.e. wire/wireless, Ethernet/Can bus, USB. GPS receiver. - Extension Ports or General Purpose I/O
7.3.Solution
The underlying silicon solution is essential to meet our system design requirements. The solution must provide specialized processing and dedicated engines to achieve the communications and multimedia tasks. To keep board size and manufacturing expense under control, the processor must offer (SoC) integration that includes multiple processing cores, ample memory and all necessary system peripherals. The manufacturing process and circuit design must enable the greatest performance-per-unit of power consumed during active operation and negligible leakage during standby periods.
7.4.Architecture
Our architectural design vision is to build modular system, which provides the modularity from applications side of view. The next block diagram will illustrate OCS H.W. components:
Figure (7-1): OCS Hardware Block Diagram. Our design is to separate the hardware into two categories: - OCS H.W. Core. - Extensions. Mainly for our project, we will focus on the main parts of OCS or what we called OCS H.W. core.

This core contents are: Processor, GPS receiver, interfaces, memory, and power supply unit. In other chapters we will review two applications on OCS which use OCS interfaces and implement some functions based on a modular platform concept. This provides the modularity concept to apply many applications such as car navigation, mapping, surveying and so on. Now we will review core elements one by one:
7.4.1.CPU
As a high-performance processor for enhanced digital media, DM37x/AM37xemploys TI 45nm advanced industrial technology; this architecture has the advantage of low power consumption at the same time of being designed for ARM and graphical demonstration. The Texas Instruments DM3730 DaVinci digital media processor is powered by up to 1-GHz (also supports 300, 600, and 800-MHz operation) ARM CortexA8 and 800-MHz (also supports 250, 520 and 660-MHz operation) C64x+ DSP core, and has integrated 3D graphics processor, imaging and video accelerator (IVA), USB 2.0, MMC/SD memory card, UART and many more. DaVinci DM3730 video processor is pin-to-pin compatible with Sitara AM37x devices and software compatible with the OMAP35x processors. The C64x+ DSP and hardware video accelerator enable audio and HD 720p video decoding and encoding independent of the ARM processor. The programmable DSP engine allows multiple signal processing tasks such as image processing and analysis, digital filtering, and math functions. DaVinci DM3730 video processor is suitable for 720p HD (High De inition) video applications which require large amount of data processing.
7.4.1.2 CPU Features

Clock The CPU clock includessys_32k, sys_altclk, sys_clkout1, sys_clkout2, sys_xtalout, sys_xtalin, sys_clkreq. The sys_32k 32-kHz clock is used for low frequency operation. It supplies the wake-up domain signals for operating in lowest power mode (off mode). This clock is provided through the sys_32k pin. The 32-kHz is generated by power management.

The sys_xtalin / sys_xtalout system input clock (26 MHz) is used to generate the main
Reset The functionof reset is decided by the SYS_NRESPWRON signal on the CPU, Reset is enabled when LOW levelsignal (high to low) is given. General-Purpose Interface The general-purpose interface combines six general-purpose input/output (GPIO) banks. Each GPIO bank provides 32 dedicated general-purpose pins with input and output capabilities; thus, it supports up to 192 (6 x 32) general-purpose interface pins. These pins can be configured for the following applications: Data input (capture)/output (drive) Keyboard interface with a debounce cell Interrupt generation in active mode when external events are detected. Display Subsystem The display subsystem provides the logic to display a video frame from the memory frame buffer (either SDRAM or SRAM) on a liquid-crystal display (LCD) panel or a TV set. The display subsystem integrates the following elements: Display controller (DISPC) module Remote frame buffer interface (RFBI) module Display serial interface (DSI) complex I/O module and a DSI protocol engine DSI PLL controller that drives a DSI PLL and high-speed (HS) divider. NTSC/PAL video encoder

The display controller and the DSI protocol engine are connected to the L3 and L4 interconnect; the RFBI and the TV out encoder modules are connected to the L4 interconnect. 2D/3D Graphics Accelerator The 2D/3D graphics accelerator (SGX) subsystem accelerates 2-dimensional (2D) and 3-dimensional (3D) graphics applications. The SGX subsystem is based on the POWERVR SGX core from Imagination Technologies. SGX is a new generation of programmable POWERVR graphic cores. The POWERVR SGX530 v1.2.5 architecture is scalable and can target all market segments from mainstream mobile devices to high-end desktop graphics. Targeted applications include feature phone, PDA, and hand-held games. (see Figure 72)
Figure 7-2 The SGX graphics accelerator can simultaneously process various multimedia data types: Pixel data Vertex data Video data General-purpose processing This is achieved through a multithreaded architecture using two levels of scheduling and data partitioning enabling zero-overhead task switching.

7.4.2.GPS Receiver
In a GPS receiver the signal is processed to obtain the required information, which in turn is used to calculate the users position. Therefore, at least two areas of discipline, receiver technology and navigation scheme, are employed in a GPS receiver. This book covers both areas. In the case of GPS signals, there are two sets of information: the civilian code, referred to as the coarse/ acquisition (C/A) code, and the classified military code, referred to as the P(Y) code. This book concentrates only on the civilian C/A code. This is the information used by commercial GPS receivers to obtain the user position. GPS receivers must solve two fundamental problems, first is the receiver itself, which gets the raw data, the other is the manipulation and computations done on that data to calculate the user position. The idea of GPS is not only about the physical position of the user and satellites. Although, GPS is really time-dependent. In other words GPS is predominately a very complex system of clocks.
7.4.2.1.SiRF chipset
SiRFstarII makes it easy and economical to add high-performance SiRFstarII technology to systems that are based on many popular processors and operating systems. The SiRF starII solution allows GPS function to be added at minimal cost in components and circuit board area, by sharing the host system's processor and memory resources. The chipset acquires and tracks satellites, then sends raw measurements to the host processor running the SiRFNav software in parallel with the host applications. <<The SiRFNav software module computes position time and velocity. For enhanced accuracy and navigation reliability, WAAS corrections can be applied or GPS measurements can be combined with dead reckoning data and processed by SiRFDRive software.>>
Figure (7-3): SiRF Chipset Block Diagram The chipset consists of the GSP2t highly integrated digital chip, GRF2i integrated RF receiver. The SiRFstarII is designed to be embedded into large volume applications that use multi-thread processors and real time operating systems. The SiRFstarII hardware can be added to the host Motherboard is within an area as small as two square centimeters, and with minimal increment in bill of material. The accurate positioning and built in dead reckoning support provide optimum performance for automotive navigation and entertainment systems. Small size and low cost also make the SiRFstarII the solution for portable devices such as hand-held navigators and Personal Digital Assistants where space and cost are critical. One part that all GPS receivers have in common is the antenna, whose jobs to receive the signal from the satellites and pass that signal on for processing. The signal the antenna picks up is a UHF signal with a frequency of 1575.2MHz (this is the civilian, unencrypted frequency; the military sign uses 1227.6 MHz).This frequency offers all-weather navigation capability but is blocked by walls, ceilings and even trees.
7.4.2.2.NMEA standard
The National Marine Electronics Association (NMEA) developed a standard over 20 years ago that defnes the interface between various pieces of marine electronic equipment and navigational computers, allowing them to talk together and share vital information.

The NMEA 0183 standard slowly became the common method by which marine electronics devices could talk to one another. The standard specifes both the electrical connections that make up an NMEA system, the communications method of transmitting the data, and the format of the data sentences that carry the NMEA information .The NMEA 0183 standard is a purely digital data transmission scheme, using 1s and 0s in a binary format, to communicate a digital representation of the required information (depth, speed etc.) to a connected device .The need for NMEA 0183 evolved from the earlier NMEA 0180 and NMEA 0182 standards. Because they differ in baud rate and transmission parameters from NMEA 0183, they are completely incompatible with NMEA 0183. communication specification: The data communication specification for NMEA version 1, 2 and 3 is essentially the same as RS232 with the settings: 800 baud, 1 start bit, 1 stop bit and No Parity. Output message: NMEA output messages provided by SiRF chipset. Message Description GGA Time, position and fix type data GLL Latitude, longitude, UTC time of position fix and status GSA GPS receiver operating mode, satellites used in the position solution, and DOP values GSV Number of GPS satellites in view satellite ID numbers, elevation, azimuth, & SNR values MSS Signal-to-noise ratio, signal strength, frequency, and bit rate from a radio-beacon receiver RMC Time, date, position, course and speed data VTG Course and speed information relative to the ground ZDA PPS timing message (synchronized to PPS) 150 OK to send message 151 GPS Data and Extended Ephemeris Mask 152 Extended Ephemeris Integrity

154 Extended Ephemeris ACK Table (7-1)
7.4.3.Interfaces This point is the most vital point in the OCS which can provide the sense of modularity and the ability of connecting multiple hardware extensions. The serial interfaces is the most appropriate solution for this issue also considered the mandatory interfaces for OCS - HDQ - I2C - SmartReflex - McBSP LP - McSPI S - McSPI - UARTs - USB OCS also provide some peripherals as: Video Interfaces TV - Video Interfaces DSS Signals - Video Interfaces RFBI Audio Interfaces Test interfaces - JTAG - SDTI "Serial data out (System Trace)" - HWDBG "Hardware Debug Signal" Removable Media Interfaces - MMC/SDIO MULTIMEDIA MEMORY CARD/SECURE DIGITAL IO
7.4.4.Power Supply

The power supply circuit is one of the most important part in the full product design and it strongly affects the product overall performances. Power Supply Requirements After calculations and researches about the appropriate hardware the OCS power requirements are: Nominal Supply Voltage Max Supply Voltage Supply voltage range Max Peak current consumption (impulsive) Max Average current consumption during GPRS transmission Max Average current consumption during VOICE/CSD transmission Average current during Power Saving (CFUN=5) Average current during idle (Power Saving disabled) GPS Max Peak current consumption GPS Max Average current consumption during Tracking GPS Average current during Power Saving GPS antenna consumption (external active antenna) Electrical Design The electrical design of the power supply depends on the power source where this power is drained. We will distinguish them into four categories: - +5V input (typical PC internal regulator output) - +12V input (typical automotive) 3.8 V 4.2 V 3.4 V - 4.2 V 1.9 A
400 mA
270 mA 4 mA 17 mA 80 mA 60 mA 1 mA 20 m

- Battery - 110~220 V Ac (typical adaptor) + 5V input Source Power Supply Design The desired output for the power supply is 3.8V, hence there's no big difference between the input source and the desired output and a linear regulator can be used. A switching power supply will not be suitable because of the low drop out requirements. When using a linear regulator, a proper heat sink shall be provided in order to dissipate the power generated. Also protection diode should be inserted close to the power input, in order to save the OCS from power polarity inversion. + 12V Input Source Power Supply Design The desired output for the power supply is 3.8 V; hence due to the big difference between the input source and the desired output, a linear regulator is not suitable and shall not be used. A switching power supply will be preferable because of its better efficiency especially with the 2A peak current load needed by the OCS. When using a switching regulator, a 500 kHz or more switching frequency regulator is preferable because of its smaller inductor size and its faster transient response. This allows the regulator to respond quickly to the current peaks absorption. For car battery the input voltage can rise up to 15,8V and this should be kept in mind when choosing components: all components in the power supply must withstand this voltage. A Bypass low ESR capacitor of adequate capacity must be provided in order to cut the current absorption peaks, a 100F tantalum capacitor is usually suitable. For Car applications a spike protection diode should be inserted close to the power input, in order to clean the supply from spikes. Also protection diode should be inserted close to the power input, in order to save the OCS from power polarity inversion. This can be the same diode as for spike protection. Battery Source Power Supply Design

The desired nominal output for the power supply is 3.8V and the maximum voltage allowed is 4.2V, hence a single 3.7V Li-Ion cell battery type is suitable for supplying the power to OCS. The three cells Ni/Cd or Ni/MH 3,6 V Nominal. Battery types or 4V PB types must not be used directly since their maximum voltage can rise over the absolute maximum voltage for the OCS and damage it. A Bypass low ESR capacitor of adequate capacity must be provided in order to cut the current absorption peaks, a 100F tantalum capacitor is usually suited. Also protection diode should be inserted close to the power input, in order to save the OCS from power polarity inversion. Otherwise the battery connector should be done in a way to avoid polarity inversions when connecting the battery. The battery capacity must be at least 500mAh in order to withstand the current peaks of 2A; the suggested capacity is from 500mAh to 1000mAh. Battery Charge control Circuitry Design The charging process for Li-Ion Batteries can be divided into 4 phases: - Qualification and trickle charging - Fast charge - constant current - Final charge - constant voltage or pulsed charging - Maintenance charge The qualification process consists in a battery voltage measure, indicating roughly its chargestatus. If the battery is deeply discharged, that means its voltage is lower than the trickle charging threshold, then the charge must start slowly possibly with a current limited precharging process where the current is kept very low with respect to the fast charge value: the trickle charging. During the trickle charging the voltage across the battery terminals rises; when it reaches the fast charge threshold level the charging process goes into fast charge phase. During the fast charge phase the process proceeds with a current limited charging; this current limit depends on the required time for the complete charge and from the battery pack capacity. During this phase the voltage across the battery terminals still raises but at a

lower rate. Once the battery voltage reaches its maximum voltage then the process goes into its third state: Final charging. The voltage measure to change the process status into final charge is very important. It must be ensured that the maximum battery voltage is never exceeded, otherwise the battery may be damaged and even explode. Moreover for the constant voltage final chargers, the constant voltage phase (final charge) must not start before the battery voltage has reached its maximum values. Otherwise the battery capacity will be highly reduced. The final charge can be of two different types: constant voltage or pulsed. The constant voltage charge proceeds with a fixed voltage regulator (very accurately set to the maximum battery voltage) and hence the current will decrease while the battery is becoming charged. When the charging current falls below a certain fraction of the fast charge current value, then the battery is considered fully charged, the final charge stops and eventually starts the maintenance. The pulsed charge process has no voltage regulation, instead the charge continues with pulses. Usually the pulse charge works in the following manner: the charge is stopped for some time, just few hundreds of mS, then the battery voltage will be measured and when it drops below its maximum value a fixed time length charging pulse is issued. As the battery approaches its full charge the off time will become longer, hence the dutycycle of the pulses will decrease. The battery is considered fully charged when the pulse duty-cycle is less than a threshold value, typically 10%, the pulse charge stops and eventually the maintenance starts. The last phase is not properly acharging phase, since the battery at this point is fully charged and the process may stop after the final charge. The maintenance charge provides an additional charging process to compensate for the charge leak typical of a Li-Ion battery. It is done by issuing pulses with a fixed time length, again few hundreds of mS, and a duty-cycle around 5% or less. The charging process is not a trivial task to be done. All of these operations

should start if and only if battery temperature is inside a charging range, usually 5C - 45C. The OCS must measures the temperature of its internal component, in order to satisfy this last requirement. It is not exactly the same as the battery temperature but in common application the two temperatures should not differ too much and the charging temperature range should be guaranteed.
7.5. Prototype
It is mandatory to have a development hardware kit to make a reality development on your platform neither then emulation and simulation. In other words it will add the practical sense. For our system we put this criteis when we think about the development kit. It is the answer for the question which is meet our needs.
7.5.1. Selection criteria:

- Software related: o Operating Systems Hardware drivers - General features - Processor o Speed o Cash o Fan-less - Interface o Audio interface o Repeat button o External keyboard connector o GPIOs - Portability

o Battery life o Unit weight o Waterproof o Overall size - Display o Display size o Brightness o 3D map display o Color o Display resolution o Night view mode o Touch capability - System Memory o Built-in system memory o Internal hard drive - Connectivity o Wi-Fi/Wi-Max o USB o Bluetooth o Multimedia headphone jack o Infrared connector o Zig-bee o Serial interfaces o Parallel interfaces o GPRS/GSM interface o 3G Comm. interface
- Expansion memory format o SD card

o Compact flash - Local distributor availability - Brand reliability - Manufacturing Future - Technical Support - Warranty - Cost
7.5.2. Selected Evaluation Kit for Prototyping

After applying those criterias on the existed products and after depth researches on Internet we choose the beagle board as development tool and prototype, in fact beagle board is the best development tool for our project because it is meet our specs by the criterias applying. Unfortunately it is not on the stock! So we think to buy the China Colon, which is DevKit8500D it is approximately the same of beagle board. DevKit8500D Speci ications: Attribute Processor Qt y 1 Description TI DM3730 DaVinci Digital Media Processor (pinto-pin compatible with TI AM3715) - Up to 1-GHz ARM Cortex-A8 Core, also supports 300, 600, and 800MHz operation - Up to 800Type Manufacture
Texas Instrument
DM3730

MHz TMS320C64x+ DSP Core, Also supports 260, 520 and 660-MHz operation - NEON SIMD Coprocessor (DM3730 only) - POWERVR SGX Graphics Accelerator - ARM: 32KB ICache; 32KB DCache; 256KB L2 Cache - Onchip 32KB ROM and 64KB Shared SDRAM 512MByte DDR MT29C4G96MAZAPCJA Micron SDRAM, -5 Technology, 512MByte Inc. NAND Flash A 4 line SVIDEO interface An HDMI interface TPS65930 BB - Texas (High Instruments Definition Multimedia Interface) A audio input interface A twochannel audio output
Memory
Audio/Vide o Interfaces

LCD/Touch screen interface Low-Voltage I/O TOUCH SCREEN CONTROLLER 1 x 3 line serial port, RS232 voltage 1 x 5 line serial port, TTL voltage 1 x USB2.0 OTG, High speed, 480Mbps 1 x USB2.0 HOST, High-speed, 480Mbps 1 channel SD/MMC port, support 3.3V and 1.8V logic voltage 1 channel SD/MMC port, support 1.8V logic voltage Ethernet Ethernet Controller with General Processor interface McSPI Interface BB - Texas Instrument
TSC2046
Serial port
MAX3218
Maxim Integrated Products
USB port
ISP1504
NXP Semiconductor s
SD/MMC port
Etherne
DM9000A
DAVICOM Semiconductor, Inc.
McSPI

Interface (Multichannel Serial Port Interface). McBSP interface (MultiChannel Buffered Serial Port). I2C interface HDQ interface (HDQ/1Wire) Dual Buffer/Driver with Open-Drain Output Panel Bus flat panel display
McBSP interface
l I2C interface HDQ interface Buffer
SN74LVC2G07
Texas Instrument
DVI
tfp410
Texas Instruments
Additional modules - Touch screen - 3G module
7.5.3. Selected GPS Receiver for Prototyping

GPS8100 receiver uses the latest surface mount and advanced integrated circuit technology which not only obtain the best performance, but also reduce the product size and power consumption, high-performance hardware and high intelligence software.

Features - High accuracy - All-weather - High efficiency Technical Specifications - L1 band (1575.42MHz) Receive - 20-channel parallel receive - Chipset: SiRF Star III, GSC3f/LP - Operating Temperature: -40 C to +85 C - Storage Temperature: -40 C to +85 C - Storage Humidity: <95% - Output data format: NMEA0183V3.0 - Localization accuracy: 10 meters (without SA) - Operating Voltage: 1.8V/3.3V - Data Update cycle: One second - Length: 5 M - Measurement: 26.3mm*42.8mm - Acquisition Time o Hot Start (approximately): 1 second o Warm boot (approximately): 35 seconds o Cold start (approximately): 42 seconds. - Serial interface operate with RS232 level Pin configuration and wiring 1. TX(RS232) 2. VCC(3.3-5.2V) 3. TX(TTL) 4. GND 5. RX(RS232) 6. RX(TTL) Connected to extension pins 1, 11, 12, 13, 28, 37, 38 and 40. Pin 1 GND. Pin 11 UART1_RX UART1 receives data. Pin 12 UART1_TX UART1 transmits data.

Pin 13 GND. Pin 28 GND. Pin 37 VDD 3.3V. Pin 38 VDD 1.8V. Pin 40 VDD 5V.

This page is left intentionally
Chapter8:Operating System Porting:

8.1:introduction
Our prototype uses an Arm-Based Development kit called "DevKit 8500" , Development kits provide a complete, high-quality design environment for engineers. It helps simplifying the design process and reducing time-to-market. A development kit includes software, reference designs, schematics, cables, and programmable hardware . Devkit8500 is an evaluation kit issued by Embest Technic Inc. Embest DevKit8500D Evalua on Board takes full features of the 1GHz Texas Instruments' DM3730 ARM Cortex-A8 DaVinci digital media processor and supports up to 512MByte DDR SDRAM and 512MByte NAND Flash as well as a reserved iNAND design to expand the flash storage capabilities. The board has exposed many other hardware interfaces including serial ports, LCD/TSP, DVI-D, S-Video, Ethernet, USB, TF, keyboard, camera, SPI, I2C and JTAG. The board is able to support for Linux 2.6.32 and WinCE 6.0 opera ng systems. It has two methods to boot Linux and WinCE systems from either TF card or NAND flash. Besides, it is provided with Android 2.2 demo with driver source code. Embest gives instructions on how to boot Android demo image from NAND flash with TF card. The board supports using XDS100v2 USB JTAG Emulator for debugging which is available from Embest. Embest also oers 4.3-inch or 7-inch LCD with touch screen and various modules for options including VGA, Wi-Fi, Analog Camera, GPS, GPRS, 3G and Digital Camera modules which greatly extends the func ons of the board and would be flexible for customer selection to meet their own needs. The TI's DM3730 processor is pin-to-pin compa ble with TI's AM3715 processor, Embest also supplies the board with the AM3715 CPU and this board is called DevKit8500A. in our pla orm we are going to use android froyo 2.2 running on linux kernel 2.6.32 In the next revisions of our pla orm we intend to use Android 4.1 (Jelly Bean) Based on Linux kernel 3.0.31

A complete platform consists of four parts: x-loader, u-boot, kernel and the root file system. The Figure shows the structure of the system in the NAND flash:
1. X-Loader: is the first level bootstrap program. After the system start-up, the ROM inside the CPU will copy the x-loader to internal RAM and perform work. Its main function is to initialize the CPU, copy the u-boot into the memory and give the control power to u-boot. 2. U-Boot: (Universal-Bootloader) is the second bootstrap program for a number of different architectures. Though there are quite a few other boot-loaders, U-Boot is arguably the richest, most flexible, and most actively developed open source bootloader. U-Boot is used for interacting with users and updating images and leading the kernel.
3. Kernel: Linux kernel 2.6.32 employed and customized based on Devkit8500. Android needs the Linux kernel to interact and handle the variant hardware devices. Linux Kernel is an Open Source Project started by Linus Torvalds in 1991 and released under GNU/GPLv2 license.
4. Roo s: (Root File System) is Android Root File System customized based on Devkit8500 too. We discuss the kernel and rootfs in the following sections. * As platform developers we will mainly focus in this chapter on:

Flashing and customizing a new boot-loader (U-Boot). Getting the latest source code of Linux Kernel and Android File System. Adding the needed device drivers and modules to the Linux kernel. Customizing the Linux kernel congura on to t Devkit8500. Porting the Linux kernel to our architecture. Implementing shared libraries for some devices to let android know how to talk the devices such as libgps. Building and Por ng the Android Root File System to Devkit8500.
8.2:Android :
Android is described as a mobile operating system, initially developed by Android Inc. Android was sold to Google in 2005. Android is based on a modied Linux 2.6 kernel. Google, as well as other members of the Open Handset Alliance (OHA) collaborated on Android (design, development, distribution). Currently, the Android Open Source Project (AOSP) is governing the Android maintenance and development cycle . To reiterate, the Android opera ng system is based on a modied Linux 2.6 kernel . Compared to a Linux 2.6 environment though, several drivers and libraries have been either modified or newly developed to allow Android to run as efficiently and as effectively as possible on mobile devices (such as smart phones or internet tablets). Some of these libraries have their roots in open source projects. Due to some licensing issues, the Android community decided to implement their own c library (Bionic), and to develop an Android specific Java runtime engine (Dalvik Virtual Machine DVM). With Android, the focus has always been on optimizing the infrastructure based on the limited resources available on mobile devices . To complement the operating environment, an Android specific application framework was designed and implemented. Therefore, Android can best be described as a complete solution stack, incorporating the OS, middlewear components, and

applica ons. In Android, the modied Linux 2.6 kernel acts as the hardware abstraction layer (HAL). To summarize, the Android operating environment can be labeled as: An open platform for mobile development A hardware reference design for mobile devices A system powered by a modied Linux 2.6 kernel A run time environment An application and user interface (UI) framework
8.3 Android features :

Handset layouts The pla orm is adaptable to larger, VGA, 2D graphics library, 3D graphics library based on OpenGL ES 2.0 specica ons, and tradi onal smart phone layouts. Storage SQLite, a lightweight relational database, is used for data storage purposes. Connectivity Android supports connectivity technologies including GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, NFC and WiMAX. Messaging SMS and MMS are available forms of messaging, including threaded text messaging and Android Cloud To Device Messaging (C2DM) and now enhanced version of C2DM, Android Google Cloud Messaging (GCM) is also a part of Android Push Messaging service.
Multiple language support Android supports 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 thirdparty applications. Media support Android supports the following audio/video/s ll media formats: WebM, H.263, H.264, AAC, HE-AAC (in 3GP or MP4 container), MPEG-4 SP, AMR, AMR-WB (in 3GP container), MP3, MIDI, Ogg Vorbis, FLAC, WAV, JPEG, PNG, GIF, BMP, WebP. Streaming media support RTP/RTSP streaming (3GPP PSS, ISMA), HTML progressive download (HTML5 <video> tag). Adobe Flash Streaming (RTMP) and HTTP Dynamic Streaming are supported by the Flash plug-in. Apple HTTP Live Streaming is supported by RealPlayer for Android ,and by the opera ng system in Android 3.0 (Honeycomb). 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 orienta on, scaling, pixel format conversion) and accelerated 3D graphics. 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. Bluetooth Supports A2DP, AVRCP, sending les (OPP), accessing the phone book (PBAP), voice dialing and sending contacts between phones. Keyboard, mouse and joystick (HID) support is available in Android 3.1+, and in earlier versions through manufacturer customizations and third-party applications. Video calling Android does not support native video calling, but some handsets have a customized version of the operating system that supports it, either via the UMTS network (like the Samsung Galaxy S) or over IP. Video calling through Google Talk is available in Android 2.3.4 and later. Gingerbread allows Nexus S to place Internet calls with a SIP account. This allows for enhanced VoIP dialing to other SIP accounts and even phone numbers. Skype 2.1 oers video calling in Android 2.3, including front camera support. Users with the Google+ android app can video chat with other google+ users through hangouts. Multitasking Multitasking of applications, with unique handling of memory allocation, is available Accessibility Built in text to speech is provided by Talk back for people with low or no vision. Enhancements for people with hearing disabilities is available as is other aids. Voice based features Google search through voice has been available since initial release. Voice ac ons for calling, tex ng, naviga on, etc. are supported on Android 2.2 onwards. As of Android 4.1, Google has expanded Voice Ac ons with the ability to talk back

and read answers from Google's Knowledge Graph when queried with specific commands. The ability to control hardware has not yet been implemented. Tethering Android supports tethering, which allows a phone to be used as a wireless/wired Wi-Fi hotspot. Before Android 2.2 this was supported by thirdparty applications or manufacturer customizations. Screen capture Android supports capturing a screenshot by pressing the power and volumedown buttons at the same time. Prior to Android 4.0, the only methods of capturing a screenshot were through manufacturer and third-party customizations or otherwise by using a PC connection (DDMS developer's tool). These alternative methods are still available with the latest Android. External storage Most Android devices include microSD slot and can read microSD cards forma ed with FAT32, Ext3 or Ext4 le system. To allow use of high-capacity storage media such as USB flash drives and USB HDDs, many Android tablets also include USB 'A' receptacle. Storage forma ed with FAT32 is handled by Linux Kernel VFAT driver, while 3rd party solu ons are required to handle other popular file systems such as NTFS, HFS Plus and exFAT.
8.4 Android Architecture :

Figure 1 outlines the current (layered) Android Architecture. The modified Linux kernel operates as the HAL, and provides device driver, memory management, process management, as well as networking functionalities, respectively. The library layer is interfaced through Java (which deviates from the traditional Linux design). It is in this layer that the Android specific libc (Bionic) is located. The surface manager handles the user interface (UI) windows. The Android runtime layer holds the Dalvik Virtual Machine (DVM) and the core libraries (such as Java or IO) Most of the functionalities available in Android are provided via the core libraries.
Figure 1: Android Architecture Note: Figure 1 courtesy of the OHA The application framework houses the API interface. In this layer, the activity manager governs the application life cycle. The content providers enable applications to either access data from other applications or to share their own data. The resource manager provides access to non-code resources (such as graphics), while the notification manager enables applications to display custom alerts. On top of the application framework are the built-in, as well as the user applications, respectively. It has to be pointed out that a user application can replace a built-in application, and that each Android application runs in its own process space, within its own DVM instance. Most of these major Android components are further discussed (in more detail) in the next few sections of this report.
1. Dalvik Virtual Machine

Android based systems utilize their own virtual machine (VM), which is known as the Dalvik Virtual Machine (DVM) [4]. The DVM uses special bytecode, hence native Java byte-code cannot directly be executed on Android systems. The Android community provides a tool (dx) that allows converting Java class files into Dalvik executables (dex). The DVM implementation is highly optimized in order to perform as efficiently and as effectively as possible on mobile devices that are normally equipped with a rather slow (single) CPU, limited memory resources, no OS swap space, and limited battery capacity. The DVM has been implemented in a way that allows a device to execute multiple VMs in a rather efficient manner. It also has to be pointed out that the DVM relies on the modified Linux kernel for any potential threading and low-level memory management functionalities. With Android 2.2, some major changes to the JVM infrastructure were implemented. Up to version 2.2, the JVM was an actual interpreter, similar to the original JVM solu on deployed with Java 1.0. While the Android solu on always reflected a very efficient interpreter, it was still an interpreter and hence, no native code was generated. With the release of Android 2.2, a just-in-time (JIT) compiler has been incorporated into the solution stack, which translates the Dalvik byte-code into much more efficient machine code (similar to a C compiler). Down the road, additional JIT and garbage collection (GC) features will be deployed with Android, further busting (potential) aggregate systems performance.
2. Target Platform - Instruction Set

To simplify the discussion, the statement made here is that most of the Linux 2.6 based devices are x86 based systems, whereas most mobile phones are ARM based products.

While ARM represents a 32-bit reduced instruction set computer (RISC) instruc on set architecture, x86 systems are primarily based on the complicated instruction set computer (CISC) architecture. In general, the statement can be made that ARM (RISC) is executing simpler (but more) instruc ons compared to an x86 (CISC) system. As already discussed, memory is at a premium in mobile devices due to size, cost, and power constraints. ARM addresses these issues by providing a 2nd 16-bit instruction set (labeled thumb) that can be interleaved with regular 32-bit ARM instructions. This additional instruction set can reduce the code size by up to 30% (at the expense of some performance limitations). Ergo, from an overall systems perspective, the incorporation of the thumb instruction set can be considered as an exercise in compromises. Compared to x86 processors, the ARM design reveals a strong focus on lower power consumption, which again makes it suitable for mobile devices .
3. Kernel and Startup Process

It is paramount to reiterate that while Android is based on Linux 2.6, Android does not utilize a standard Linux kernel . Hence, an Android device should not be labeled a Linux solution per se. Some of the Android specific kernel enhancements include:
alarm driver (provides timers to wakeup devices) shared memory driver (ashmem) binder (for inter-process communication), power management (which takes a more aggressive approach than the Linux PM solution) low memory killer kernel debugger and logger

During the Android boot process, the Android Linux kernel component first calls the init process (compared to standard Linux, nothing unusual there). The init process accesses the files init.rc and init.device.rc (init.device.rc is device specific). Out of the init.rc file, a process labeled zygote is started. The zygote process loads the core Java classes, and performs the initial processing steps. These Java classes can be reused by Android applications and hence, this step expedites the overall startup process. After the initial load process, zygote idles on a socket and waits for further requests. Every Android application runs in its own process environment. A special driver labeled the binder allows for (efficient) inter-process communications (IPC). Actual objects are stored in shared memory. By utilizing shared memory, IPC is being optimized, as less data has to be transferred. Compared to most Linux or UNIX environments, Android does not provide any swap space. Hence, the amount of virtual memory is governed by the amount of physical memory available on the device
4. The Bionic Library

Compared to Linux, Androids incorporates its own c library (Bionic). The Bionic library is not compatible with the Linux glibc. Compared to glibc, the Bionic library has a smaller memory footprint. To illustrate, the Bionic library contains a special thread implementa on that 1st, optimizes the memory consump on of each thread and 2nd, reduces the startup time of a new thread. Android provides run-time access to kernel primitives .

Hence, user-space components can dynamically alter the kernel behavior. Only processes/threads though that do have the appropriate permissions are allowed to modify these settings. Security is maintained by assigning a unique user ID (UID) and group ID (GID) pair to each application. As mobile devices are normally intended to be used by a single user only (compared to most Linux systems), the UNIX/Linux /etc/passwd and /etc/group settings have been removed. In addition (to boost security), /etc/services was replaced by a list of services (maintained inside the executable itself). To summarize, the Android c library is especially suited to operate under the limited CPU and memory conditions common to the target Android platforms .Further, special security provisions were designed and implemented to ensure the integrity of the system.
5. Media & File System Storage

When it comes to configuring and setting-up mobile devices, traditional hard drives are in general too big (size), too fragile, and consume too much power to be useful. In contrast, flash memory devices normally provide a (relative) fast read access behavior as well as better (kinetic) shock resistance compared to hard drives. Fundamentally, two different types of flash memory devices are common, labeled as NAND and NOR based solutions. While in general, NOR based solutions provide low density, they are characterized as (relative) slow write and fast read components. On the other hand, NAND based solutions offer low cost, high density, and are labeled as (relative) fast write and slow read IO solutions. Some embedded systems are utilizing NAND flash devices for data storage, and NOR based components for the code (the execution environment). From a file system perspective, as of Android version 2.3, the (well-known) Linux ext4 le system is being used .

Prior to the ext4 le system, Android normally used YAFFS (yet another ash file system). The YAFFS solution is known as the first NAND optimized Linux flash file system. Some Android product providers (such as Archos with ext3 in Android 2.2) replaced the standard Archos file system with another file system solution of their choice. As of the writing of this report, the maximum size of any Android applica on equals to a low 2-digit MB number, which compared to actual Linux based systems has to be considered as being very small. This implies that the memory and file system requirements (from a size perspective not from a data integrity perspective) are vastly different for Android based devices compared to most Linux systems.
6. Power Management
In the mobile device arena, power management is obviously paramount. That does not imply though that power management should be neglected on any other system. Hence, power management in any IT system, with any operating system, is considered a necessity due to the ever increasing power demand of todays computer systems. To illustrate, to reduce and manage power consumption, Linux based systems provide power-saving features such as clock gating, voltage scaling, activating sleep modes, or disabling memory cache. Each of these features reduces the system's power consumption (normally at the expense of an increased latency behavior) . Most Linux based systems manage power consumption via the Advanced Configuration and Power Interface (ACPI). Android based systems provide their own power management infrastructure (labeled Power Manager) that was designed based on the premise that a processor should not consume any power if no applications or services actually require power. Android demands that applications and services request CPU resources via wake locks through the Android application

framework and native Linux libraries. If there are no active wake locks, Android will shutdown the processor.
8.5 Ini alizing a Build Environment:

This section describes how to set up your local work environment, how to use Repo to get the Android files, and how to build the files on your machine. To build the Android source files, you will need to use Linux or Mac OS. Building under Windows is not currently supported. Note: The source download is approximately 8.5GB in size. You will need over 30GB free to complete a single build, and up to 100GB (or more) for a full set of builds. For an overview of the entire code-review and code-update process, see Life of a Patch.
8.5.1 Se ng up a Linux build environment:

The Android build is routinely tested in house on recent versions of Ubuntu LTS (12.04), CENTOS (6.3) and REDHAT (6.3) For Gingerbread (2.3.x) and newer versions, including the master branch, a 64-bit environment is required. Older versions can be compiled on 32-bit systems. Note: It is also possible to build Android in a virtual machine. If you are running Linux in a virtual machine, you will need at least 16GB of RAM/swap and 30GB or more of disk space in order to build the Android tree.detailed instructions for Ubuntu follow. In general you will need: 1. Python 2.6 -- 2.7, which you can download from python.org. 2. GNU Make 3.81 -- 3.82, which you can download from gnu.org, 3. JDK 5 for Froyo or older.You can download both from java.sun.com.

4. Git 1.7 or newer. You can nd it at git-scm.com. Installing required packages (Ubuntu 12.04) Building on Ubuntu 12.04 is currently only experimentally supported and is not guaranteed to work on branches other than master.
$ sudo apt-get install git gnupg flex bison gperf build-essential \ zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \ libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \ libgl1-mesa-dev g++-multilib mingw32 tofrodos \ python-markdown libxml2-utils xsltproc zlib1g-dev:i386 $ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linuxgnu/libGL.so
8.6 Getting Linux Kernel Source Code:

In order to get Android working you have to get Linux kernel to run Android on top of it. Android froyo (2.2) uses Linux Kernel 2.6.32. Instead of reinventing the wheel we are developing our platform on a customized Linux Kernel for Devkit8500 you can get it from a direct link here "not recommend " http://www.general- iles.com/download/gs60011452h32i0/linux-2.6.32devkit8500.tar.bz2.html or the best source of the kernel is from the attached DVD " in the devkit8500 package" if you want to download the Linux Kernel from another source you can use GIT such as this " example "
$ git clone git://gitorious.org/0xlab-kernel/kernel.git
Now you will have the Linux kernel source code in kernel folder. The same instructions apply if you want to download the Linux Kernel from another source. Just replace the <git-repository> in the second command with the git repository of the Linux Kernel and the <branch-name> with the branch you want to check as follows:
$ cd .. $ git clone <git-repository>

$ cd kerne $ git checkout -b <branch-name>
8.7 Con iguring and Building Linux Kernel:

The Linux kernel build system is quite complex and since the platform is Loosely Linux Based (i.e. all the platform runs on top of the Dalvik VM and the Linux kernel is used only for managing the hardware), we will not discuss the kernel issues. For more information about the Linux build system, we recommend reading the documentation which could be found in the Documentation/ folder in the source code we downloaded. Before building the kernel, we have to configure it for DevKit8500. A preset configuration For Android system, the iutput operation is as follows:
$ cd linux-2.6.32-devkit8500 $ make distclean $ make devkit8500_android_defconfig $ make menuconfig
If an error occurs in the system when make menuconfig is input, it is necessary to install ncurse in the Ubuntu system; ncurse library is a character graphic library, used for make menuconfig of kernel; the specific installation instruction is:
$ sudo apt-get install ncurses-dev
Enter the kernel customize menu now, enter PANEL_TYPE according to the following pointing paths:
Select under PANEL_TYPE according to actually displayed screen size:
After determining PANEL_TYPE, jump to parent directory, select Exit to exit, until the following picture appears, then select Yes:
After configuring the kernel you may build it using the following commands:
$ make ARCH=arm CROSS_COMPILE=<tool-chain-path>/bin/arm-android-eabi- uImage $ make ARCH=arm CROSS_COMPILE=<tool-chain-path>/bin/arm-android-eabi- modules
The <tool-chain-path> in the previous commands have to be replaced with the path of the toolchain The toolchain contains a cross compiler, a linker to

transform the code into an executable code for Arm architecture, libraries to provide interfaces and a debugger. After building the kernel successfully, the kernel compiled image could be found in the following path: arch/arm/boot/uImage
8.9 Getting Android Source Code

8.9.1 in General:
Since Google released the Android source code, variant open source projects started porting Android for different platforms. Downloading and working with Android source code requires installing both repo and git tools. Repo is a tool that Google built on top of Git to help developers managing multiple Git repositories. It does the uploads to the revision control system, and automates parts of the Android development workflow. Repo is NOT meant to replace Git, only to make it easier to work with Git in the context of Android. The repo tool is an executable Python script that you can put anywhere in your path.In this context we will not discuss using Repo and Git. We only mention how to use it to download the Android source code. To download Android official source code from Google, we first create an empty directory for the source code. Then, we initialize the Repo inside it. Finally, we synchronize the folder with the server as follows:
$mkdir mydroid $cd mydroid $repo init -u git://android.git.kernel.org/platform/manifest.git -b <branch>
Of course, you will replace the <branch> in the command with the name of the branch you want to check out, which is FROYO in our project.
8.9.2 For devkit8500:

you can get the source code from the attached DVD , found in /media/cd/linux/demo/android/source/rowboat-android-froyo-devkit8500.tar you can excute this command at this directory:
tar -xvf rowboat-android-froyo-devkit8500.tar
8.10 Android Build System:

8.10.1 in General "customizable mode "
Android uses a custom build system to generate tools, binaries, and documentation that differ from Linux Kernel Build System. Android's build system is making based and requires a recent version of GNU Make (note that Android uses advanced features of GNU Make that may not yet appear on the GNU Make web site). Before continuing, check your version of make by running :
$ make -v
If you don't have version 3.80 or greater, you will need to upgrade your version of make
Understanding the makefile:

A makefile defines how to build a particular application. Makefiles typically include all of the following elements: 1. Name: Give your build a name (LOCAL_MODULE := <build_name>). 2. Local Variables: $(CLEAR_VARS)). Clear local variables with CLEAR_VARS (include
3. Files: Determine which les your applica on depends upon (LOCAL_SRC_FILES := main.c). 4. Tags: Define tags, as necessary (LOCAL_MODULE_TAGS := eng development). 5. Libraries: Dene whether your applica on links with other libraries

(LOCAL_SHARED_LIBRARIES := cutils) 6. Template le: Include a template le to dene underlining make tools for a particular target (include $(BUILD_EXECUTABLE)). The following snippet illustrates a typical makefile. LOCAL_PATH := $(my-dir) include $(CLEAR_VARS) LOCAL_MODULE := <buil_name> LOCAL_SRC_FILES := main.c LOCAL_MODULE_TAGS := eng development LOCAL_SHARED_LIBRARIES := cutils The directions below describe how to configure make files for new mobile devices and products. 1. Create a company directory in //device/partner.
$ mkdir device/partner/<company_name>
2. Create a products directory beneath the company directory you created in step 1.
$ mkdir device/partner/<company_name>/products/
3. Create a product-specific make file, called device/partner/<company_name>/products/<first_produ ct_name>.mk, that includes the following code:
$(call inherit-product, target/product/generic.mk) # # Overrides PRODUCT_NAME := <first_product_name> PRODUCT_DEVICE := <board_name>

4. In the products directory, create an AndroidProducts.mk file that point to (and is responsible for finding) the individual product make files.
# This file should set PRODUCT_MAKEFILES to a list of product makefiles # to expose to the build system. LOCAL_DIR will already be set to # the directory containing this file. # # This file may not rely on the value of any variable other than # LOCAL_DIR; do not use any conditionals, and do not look up the # value of any variable that isn't set in this file or in a file that # it includes. # PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/first_product_name.mk \
5. Create a board-specific directory beneath your company directory that matches the PRODUCT_DEVICE variable <board_name> referenced in the product-specific make file above. This will include a make file that gets accessed by any product using this board.
$ mkdir device/partner/<company_name>/<board_name>
6. Create a product_config.mk file in the directory created in the previous step(device/partner/<company_name>/<board_name>).If this directory does not include a product_config.mk file, the build will fail. # These definitions override the defaultsin config/config.make for <board_name>
# # TARGET_NO_BOOTLOADER := false # TARGET_HARDWARE_3D := false # TARGET_USE_GENERIC_AUDIO := true
7. If you wish to modify system properties, create asystem.prop file in your <board_name> directory(device/partner/<company_name>/<board_name>).
# system.prop for # This overrides settings in the products/generic/system.prop file # # rild.libpath=/system/lib/libreference-ril.so

# rild.libargs=-d /dev/ttyS0
8. Add a pointer to <second_product_name>.mk products/AndroidProducts.mk.

PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/first_product_name.mk \ $(LOCAL_DIR)/second_product_name.mk
within
9. device/partner/<company_name>/<board_name> include an Android.mk file with at least the following code:
must
# make file for new hardware from # LOCAL_PATH := $(call my-dir) # # this is here to use the pre-built kernel ifeq ($(TARGET_PREBUILT_KERNEL),) TARGET_PREBUILT_KERNEL := $(LOCAL_PATH)/kernel endif # file := $(INSTALLED_KERNEL_TARGET) ALL_PREBUILT += $(file) $(file): $(TARGET_PREBUILT_KERNEL) | $(ACP) $(transform-prebuilt-to-target) # # no boot loader, so we don't need any of that stuff.. # LOCAL_PATH := partner/<company_name>/<board_name> # include $(CLEAR_VARS) # # include more board specific stuff here? Such as Audio parameters. #
10. To create a second product for the same board, create a second product-specific make file called device/partner/company_name/products/<second_product_name>.m k that includes:
$(call inherit-product, partner/google/products/generic.mk) # # Overrides PRODUCT_NAME := <second_product_name> PRODUCT_DEVICE := <board_name>
By now, you should have two new products, called <first_product_name> and <second_product_name> associated with <company_name>. To verify that a

product is properly configured (<first_product_name>, for example), execute the following:
cd device . ./envsetup.sh partner_setup <first_product_name> make PRODUCT-<first_product_name>-user
You should find new build device/out/target/product/<board_name>. New Product File Tree
binaries
located
in
The file tree below illustrates what your own system should look like after completing the steps above.
<company_name> o <board_name> Android.mk product_config.mk system.prop o products AndroidProducts.mk <first_product_name>.mk <second_product_name>.mk
8.10.2 for devkit8500:

1)Input the following commands to compile Android:
cd rowboat-android-froyo-devkit8500 make
2) Modied script le build_ubi.sh:

vi build_ubi.sh Changed /home/embest as $HOME: MKFSUBI=/home/embest/tools/mkfs.ubifs MKFSUBI_ARG="-r ${ROOT_DIR} -m 2048 -e 129024 -c 4063 -o temp/ubifs.img" UBINIZE=/home/embest/tools/ubinize

UBINIZECFG=/home/embest/tools/ubinize.cfg UBINIZE_ARG="-o ubi.img -m 2048 -p 128KiB -s 512 ${UBINIZECFG}" Modified as: MKFSUBI=$HOME/tools/mkfs.ubifs MKFSUBI_ARG="-r ${ROOT_DIR} -m 2048 -e 129024 -c 4063 -o temp/ubifs.img" UBINIZE=$HOME/tools/ubinize UBINIZECFG=$HOME/tools/ubinize.cfg UBINIZE_ARG="-o ubi.img -m 2048 -p 128KiB -s 512 ${UBINIZECFG}"
3) Input the following commands to build le system:

sudo ./build_ubi.sh
File ubi.img will output under the folder temp/.
8.11 Building the Android File System

Getting Android File System built is quite simple task. Navigate to the folder containing the Android source code. First, you have to make sure to install the packages mentioned "git , python , java , ...etc ". Then, we have to setup Devkit8500 specica on congura ons and enabled components. These configuration were set by Embest in the froyo source code found on the package's DVD . You may check these configuration in rowboat-android-froyodevkit8500"/media/cd/linux/demo/source/rowboat-android-froyo-devkit8500. Setup the configuration by executing the following command:
$ echo "TARGET_PRODUCT := devkit8500 > buildspec.mk $ echo INSTALL_PREBUILT_DEMO_APKS := true >> buildspec.mk
The commands simply overwrite the file buildspec.mk and write the following settings in it:
TARGET_PRODUCT := devkit8500

INSTALL_PREBUILT_DEMO_APKS := true
Finally, as expected you will build the source code using the command
$ make
It will take a while to get the source code compiled. If you have a multi-core processor, you may use the command as
$ make -jN
where N is twice the number of cores you have. That will let you compile the source code faster. You may use this option while building the Linux Kernel too. After the building process finish successfully, the generated root file system could be found here: out/target/product/devkit8500/root/ out/target/product/devkit8500/system/ Also, a UBI file system image -for NAND flash- could be found in the following directory: out/target/product/devkit8500/system.img We will discuss later how to flash the UBIFS image to the NAND flash of our development kit Devkit8500
OR
You can simply execute the following :
cd $HOME/work sudo $HOME/tools/mkfs.ubifs -r rootfs -m 2048 -e 129024 -c 1996 -o ubifs.img sudo $HOME/tools/ubinize -o ubi.img -m 2048 -p 128KiB -s 512
$HOME/tools/ubinize.cfg

After above operations are executed, the required ubi.img file will be generated under the current directory.
8.12 U-boot image generation:

$cd u-boot-03.00.02.07 $make distclean $make omap3_devkit8500_config make
When the above steps are finished, the current directory will generate the file uboot.bin which we need.
8.13 X-loader image generation:

DevKit8500 supports TF Card boot or NAND boot. The burned x-loader image files are different with the different boot modes, and the corresponding methods for mapping are different too. We will introduce the generation of x-loader image file under different boot modes.
1) To generate x-loader image file MLO used for SD card start-up

cd x-loader-03.00.02.07 make distclean make omap3devkit8500_config make signGP x-load.bin mv x-load.bin.ift MLO
When the above steps are finished, the current directory will generate the file MLO which we need.

2) To generate the x-load.bin.ift_for_NAND start-up To alter the file x-loader03.00.02.07/include/congs/omap3devkit8500.h and annotate the following:
vi x-loader-03.00.02.07/include/configs/omap3devkit8500.h 35 // #define CONFIG_MMC Cross compilation: cd x-loader-03.00.02.07 make distclean make omap3devkit8500_config make signGP x-load.bin mv x-load.bin.ift x-load.bin.ift_for_NAND 1
When the above steps are finished, the current directory will generate the file x-load.bin.ift_for_NAND which we need.
8.14 Android system demonstra on:

DevKit8500D/A provides Android system demonstra on, please follow below steps: 1) Copy all les uImage_xx , MLO , x-load.bin.ift_for_NAND , UBI.img , flashuboot.bin , u-boot.bin , select according to the size of LCD you have bought, and rename uImage_xx as uImage; 2) Put the TF card in the development card, and directly power it on; the debugging tool will display the following information:
60 Texas Instruments X-Loader 1.47 (Sep 20 2011 - 16:18:31) 76

DevKit8500 xM Rev A Starting X-loader on MMC Reading boot sector 1153712 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader... U-Boot 2010.06-rc1-svn (Sep 27 2011 - 14:57:19) OMAP34xx/35xx-GP ES2.1, CPU-OPP2 L3-165MHz OMAP3 DevKit8500 board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 512 MiB *** Warning - bad CRC or NAND, using default environment In: serial
Out: serial Err: serial DevKit8500 xM Rev A Die ID #3a7e00229e3800000168263d0402302f NAND erase: device 0 whole chip Erasing at 0x1e0000 -- 100% complete. OK mmc1 is available

reading x-load.bin.ift_for_NAND 77 10892 bytes read HW ECC selected NAND write: device 0 oset 0x0, size 0x2a8c 12288 bytes wri en: OK reading flash-uboot.bin 1152260 bytes read SW ECC selected NAND write: device 0 oset 0x80000, size 0x119504 1153024 bytes wri en: OK reading uImage 2572792 bytes read SW ECC selected NAND write: device 0 oset 0x280000, size 0x2741f8 2574336 bytes wri en: OK reading ubi.img 79036416 bytes read SW ECC selected NAND write: device 0 oset 0x680000, size 0x4b60000 79036416 bytes wri en: OK

3) LED lamp sys on the board will icker to prompt a er programming is nished, at this time, please pull the TF card out. 4) Power it on again and boot to enter the android opera ng system.

Chapter 9 : Online Cars System PART A :Android programming

9.A.1.Android Develop tools
To develop apps for Android devices, you use a set of tools that are included in the Android SDK. Once you've downloaded and installed the SDK, you can access these tools right from your Eclipse IDE, through the ADT plugin, or from the command line. Developing with Eclipse is the preferred method because it can directly invoke the tools that you need while developing applications. However, you may choose to develop with another IDE or a simple text editor and invoke the tools on the command line or with scripts. This is a less streamlined way to develop because you will sometimes have to call command line tools manually, but you will have access to the same number of features that you would have in Eclipse. The basic steps for developing applications (with or without Eclipse) are shown in figure . The development steps encompass four development phases, which include:
Setup During this phase you install and set up your development environment. You also create Android Virtual Devices (AVDs) and connect hardware devices on which you can install your applications. During this phase you set up and develop your Android project, which contains all of the source code and resource files for your application. Debugging and Testing

During this phase you build your project into a debuggable .apk package that you can install and run on the emulator or an Android-powered device. If you are using Eclipse, builds are generated each time you project is saved. If you're using another IDE, you can build your project using Ant and install it on a device using adb. Next, you debug your application using a JDWP-compliant debugger along with the debugging and logging tools that are provided with the Android SDK. Eclipse already comes packaged with a compatible debugger. Last, you test your application using various Android SDK testing tools. For more information, see Test your application with the Testing and Instrumentation framework. Publishing During this phase you configure and build your application for release and distribute your application to users. For more information,
9.A.2Essential command line tools

When developing in IDEs or editors other than Eclipse, be familiar with all of the tools below, because you will have to run them from the command line. android Create and update Android projects and create, move, and delete AVDs. Android Emulator Run your Android applications on an emulated Android platform. Android Debug Bridge Interface with your emulator or connected device (install apps, shell the device, issue commands, etc.). In addition to the above tools that are included with the SDK, you need the following open source and third-party tools:

-Ant To compile and build your Android project into an installable .apk file. -Keytool To generate a keystore and private key, used to sign your .apk file. Keytool is part of the JDK. -Jarsigner (or similar signing tool) To sign your .apk file with a private key generated by Keytool. Jarsigner is part of the JDK. If you are using Eclipse and ADT, tools such as adb and android are automatically called by Eclipse and ADT so you don't have to manually invoke these tools. You need to be familiar with adb, however, because certain functions are not accessible from Eclipse, such as the adb shell commands. You might also need to call Keytool and Jarsigner to sign your applications, but you can set up Eclipse to do this automatically as well.
9.A,3.Other Third-Party Development Tools

The tools described in this section are not developed by the Android SDK team. The Android Dev Guide does not provide documentation for these tools. Please refer to the linked documents in each section for documentation.

Developing in IntelliJ IDEA IntelliJ IDEA is a powerful Java IDE from JetBrains that provides full-cycle Android development support in both the free Community Edition and the Ultimate edition. The IDE ensures compatibility with the latest Android SDK and offers a smart code editor with completion, quick navigation between code and resources, a graphical debugger, unit testing support using Android Testing Framework, and the ability to run applications in either the emulator or a USB-connected device.
Managing Virtual Devices

An Android Virtual Device (AVD) is an emulator configuration that lets you model an actual device by defining hardware and software options to be emulated by the Android Emulator. The easiest way to create an AVD is to use the graphical AVD Manager, which you launch from Eclipse by clicking Window > AVD Manager. You can also start the AVD Manager from the command line by calling the android tool with the avdoptions, from the <sdk>/tools/ directory. You can also create AVDs on the command line by passing the android tool options. For more information on how to create AVDs in this manner, see Managing Virtual Devices from the Command Line. An AVD consists of:
A hardware profile: Defines the hardware features of the virtual device. For example, you can define whether the device has a camera, whether it uses a physical QWERTY keyboard or a dialing pad, how much memory it has, and so on. A mapping to a system image: You can define what version of the Android platform will run on the virtual device. You can choose a version of the standard Android platform or the system image packaged with an SDK addon. Other options: You can specify the emulator skin you want to use with the AVD, which lets you control the screen dimensions, appearance, and so on. You can also specify the emulated SD card to use with the AVD.
A dedicated storage area on your development machine: the device's user data (installed applications, settings, and so on) and emulated SD card are stored in this area. You can create as many AVDs as you need, based on the types of device you want to model. To thoroughly test your application, you should create an AVD for each general device configuration (for example, different screen sizes and platform versions) with which your application is compatible and test your application on each one. Keep these points in mind when you are selecting a system image target for your AVD:
The API Level of the target is important, because your application will not be able to run on a system image whose API Level is less than that required by your application, as specified in the minSdkVersion attribute of the application's manifest file. For more information about the relationship between system API Level and application minSdkVersion, see Specifying Minimum System API Version. You should create at least one AVD that uses a target whose API Level is greater than that required by your application, because it allows you to test the forward-compatibility of your application. Forward-compatibility testing ensures that, when users who have downloaded your application receive a system update, your application will continue to function normally. If your application declares a uses-library element in its manifest file, the application can only run on a system image in which that external library is present. If you want to run your application on an emulator, create an AVD that includes the required library. Usually, you must create such an AVD using an Add-on component for the AVD's platform (for example, the Google APIs Add-on contains the Google Maps library).
To learn how to manage AVDs using a graphical tool, read Managing AVDs with AVD Manager. To learn how to manage AVDs on the command line, read Managing AVDs from the Command Line.
9.A.4Managing Projects
Projects act as containers for storing things such as code and resource files. The SDK tools expect your projects to follow a specific structure so it can compile and package your application correctly, so it is highly recommended that you create them with Eclipse and ADT or with the android tool on the command line. There are three types of projects, and they all share the same general structure but differ in function: Android Projects An Android project is the container for your application's source code, resource files, and files such as the Ant build and Android Manifest file. An application project is the main type of project and the contents are eventually built into an .apk file that you install on a device. Test Projects These projects contain code to test your application projects and are built into applications that run on a device. Library Projects These projects contain shareable Android source code and resources that you can reference in Android projects. This is useful when you have common code that you want to reuse. Library projects cannot be installed onto a device, however, they are pulled into the .apk file at build time. When you use the Android development tools to create a new project, the essential files and folders will be created for you. There are only a handful of files and folders generated for you, and some of them depend on whether you use the Eclipse plugin or the android tool to generate your project. As your application grows in complexity, you might require new kinds of resources, directories, and files.
Android Projects
Android projects are the projects that eventually get built into an .apk file that you install onto a device. They contain things such as application source code and resource files. Some are generated for you by default, while others should be created if required. The following directories and files comprise an Android project: src/ Contains your stub Activity file, which is stored at src/your/package/namespace/ActivityName.java. All other source code files (such as .java or .aidl files) go here as well. bin/ Output directory of the build. This is where you can find the final .apk file and other compiled resources. jni/ Contains native code sources developed using the Android NDK. For more information, see the Android NDK documentation. gen/ Contains the Java files generated by ADT, such as your R.java file and interfaces created from AIDL files. assets/ This is empty. You can use it to store raw asset files. Files that you save here are compiled into an .apk file as-is, and the original filename is preserved. You can navigate this directory in the same way as a typical file system using URIs and read files as a stream of bytes using the AssetManager. For example, this is a good location for textures and game data. res/ Contains application resources, such as drawable files, layout files, and string values. See Application Resources for more information.

anim/ For XML files that are compiled into animation objects. See the Animation resource type. color/ For XML files that describe colors. See the Color Values resource type. drawable/ For bitmap iles (PNG, JPEG, or GIF), 9-Patch image files, and XML files that describe Drawable shapes or Drawable objects that contain multiple states (normal, pressed, or focused). See the Drawable resource type. layout/ XML files that are compiled into screen layouts (or part of a screen). See the Layout resource type. menu/ For XML files that define application menus. See the Menus resource type. raw/ For arbitrary raw asset files. Saving asset files here instead of in the assets/ directory only differs in the way that you access them. These files are processed by aapt and must be referenced from the application using a resource identifier in the R class. For example, this is a good place for media, such as MP3 or Ogg iles. values/ For XML files that are compiled into many kinds of resource. Unlike other resources in the res/ directory, resources written to XML files in this folder are not referenced by the file name. Instead, the XML element type controls how the resources is defined within them are placed into the R class. xml/ For miscellaneous XML files that configure application components. For example, an XML file that defines aPreferenceScreen, AppWidgetProviderInfo, or Searchability Metadata. See Application Resources for more information about configuring these application components. libs/

Contains private libraries. AndroidManifest.xml The control file that describes the nature of the application and each of its components. For instance, it describes: certain qualities about the activities, services, intent receivers, and content providers; what permissions are requested; what external libraries are needed; what device features are required, what API Levels are supported or required; and others. See the AndroidManifest.xml documentation for more information project.properties This file contains project settings, such as the build target. This file is integral to the project, so maintain it in a source revision control system. To edit project properties in Eclipse, right-click the project folder and selectProperties. local.properties Customizable computer-specific properties for the build system. If you use Ant to build the project, this contains the path to the SDK installation. Because the content of the file is specific to the local installation of the SDK, thelocal.properties should not be maintained in a source revision control system. If you use Eclipse, this file is not used. ant.properties Customizable properties for the build system. You can edit this file to override default build settings used by Ant and also provide the location of your keystore and key alias so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system. If you use Eclipse, this file is not used. build.xml The Ant build file for your project. This is only applicable for projects that you build with Ant.
9.A.5.Library Projects

An Android library project is a development project that holds shared Android source code and resources. Other Android application projects can reference the library project and, at build time, include its compiled sources in their.apk files. Multiple application projects can reference the same library project and any single application project can reference multiple library projects. Note: You need SDK Tools r14 or newer to use the new library project feature that generates each library project into its own JAR file. You can download the tools and platforms using the Android SDK Manager, as described in Exploring the SDK. If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
If you are developing multiple related applications that use some of the same components, you move the redundant components out of their respective application projects and create a single, reuseable set of the same components in a library project. If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions. Structurally, a library project is similar to a standard Android application project. For example, it includes a manifest file at the project root, as well as src/, res/ and similar directories. The project can contain the same types of source code and resources as a standard Android project, stored in the same way. For example, source code in the library project can access its own resources through its R class.
However, a library project differs from a standard Android application project in that you cannot compile it directly to its own .apk and run it on an Android device. Similarly, you cannot export the library project to a self-contained JAR file, as you would do for a true library. Instead, you must compile the library indirectly, by referencing the library in the dependent application and building that application.
When you build an application that depends on a library project, the SDK tools compile the library into a temporary JAR file and uses it in the main project, then uses the result to generate the .apk. In cases where a resource ID is defined in both the application and the library, the tools ensure that the resource declared in the application gets priority and that the resource in the library project is not compiled into the application .apk. This gives your application the flexibility to either use or redefine any resource behaviors or values that are defined in any library. To organize your code further, your application can add references to multiple library projects, then specify the relative priority of the resources in each library. This lets you build up the resources actually used in your application in a cumulative manner. When two libraries referenced from an application define the same resource ID, the tools select the resource from the library with higher priority and discard the other. Once you have added references to library projects to your Android project, you can set their relative priority. At build time, the libraries are merged with the application one at a time, starting from the lowest priority to the highest. Library projects can reference other library projects and can import an external library (JAR) in the normal way.
9.A.6Development considerations
As you develop your library project and dependent applications, keep the points listed below in mind:
Resource conflicts Since the tools merge the resources of a library project with those of a dependent application project, a given resource ID might be defined in both projects. In this case, the tools select the resource from the application, or the library with highest priority, and discard the other resource. As you develop your applications, be aware that common resource IDs are likely to be defined in more than one project and will be merged, with the resource from the application or highest-priority library taking precedence.
Use prefixes to avoid resource conflicts To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the project (or is unique across all projects). You cannot export a library project to a JAR file A library cannot be distributed as a binary file (such as a JAR file). This will be added in a future version of the SDK Tools. A library project can include a JAR library You can develop a library project that itself includes a JAR library, however you need to manually edit the dependent application project's build path and add a path to the JAR file. A library project can depend on an external JAR library You can develop a library project that depends on an external library (for example, the Maps external library). In this case, the dependent application must build against a target that includes the external library (for example, the Google APIs Add-On). Note also that both the library project and the dependent application must declare the external library in their manifest files, in a <uses-library> element. Library projects cannot include raw assets The tools do not support the use of raw asset files (saved in the assets/ directory) in a library project. Any asset resources used by an application must be stored in the assets/ directory of the application project itself. However, resource files saved in the res/ directory are supported. Platform version must be lower than or equal to the Android project A library is compiled as part of the dependent application project, so the API used in the library project must be compatible with the version of the Android library used to compile the application project. In general, the library project should use an API level that is the same as or lower than that used by the application. If the library project uses an API level that is higher than that of the application, the application project will not compile. It is perfectly acceptable to have a library that uses the Android 1.5 API (API level 3) and that is used in an Android 1.6 (API level 4) or Android 2.1 (API level 7) project, for instance. No restriction on library package names There is no requirement for the package name of a library to be the same as that of applications that use it.
Each library project creates its own R class When you build the dependent application project, library projects are compiled and merged with the application project. Each library has its own R class, named according to the library's package name. The R class generated from main project and the library project is created in all the packages that are needed including the main project's package and the libraries' packages. Library project storage location There are no specific requirements on where you should store a library project, relative to a dependent application project, as long as the application project can reference the library project by a relative link. What is important is that the main project can reference the library project through a relative link.
9.A.7.Test Projects
Test projects contain Android applications that you write using the Testing and Instrumentation framework. The framework is an extension of the JUnit test framework and adds access to Android system objects. The file structure of a test project is the same as an Android project. src/ Includes your test source files. Test projects do not require an Activity .java file, but can include one. gen/ This contains the Java files generated by ADT, such as your R.java file and interfaces created from AIDL files. assets/ This is empty. You can use it to store raw asset files. res/ A folder for your application resources, such as drawable files, layout files, string values, etc. See Application Resources. AndroidManifest.xml

The Android Manifest for your project. See The AndroidManifest.xml File. Test Projects have a special<instrumentation> element that connects the test project with the application project. project.properties This file contains project settings, such as the build target and links to the project being tested. This file is integral to the project, so maintain it in a source revision control system. To edit project properties in Eclipse, right-click the project folder and select Properties. local.properties Customizable computer-specific properties for the build system. If you use Ant to build the project, this contains the path to the SDK installation. Because the content of the file is specific to the local installation of the SDK, it should not be maintained in a Source Revision Control system. If you use Eclipse, this file is not used. ant.properties Customizable properties for the build system. You can edit this file to override default build settings used by Ant and provide the location to your keystore and key alias, so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system. If you use Eclipse, this file is not used. build.xml The Ant build file for your project. This is only applicable for projects that you build with Ant. For more information, see the Testing section.
9.A.8.Testing a Library Project

There are two recommended ways of setting up testing on code and resources in a library project:
You can set up a test project that instruments an application project that depends on the library project. You can then add tests to the project for library-specific features.
You can set up a standard application project that depends on the library and put the instrumentation in that project. This lets you create a selfcontained project that contains both the tests/instrumentations and the code to test.
9.A.9Building and Running

During the build process, your Android projects are compiled and packaged into an .apk file, the container for your application binary. It contains all of the information necessary to run your application on a device or emulator, such as compiled .dex files (.class files converted to Dalvik byte code), a binary version of the AndroidManifest.xml file, compiled resources (resources.arsc) and uncompiled resource files for your application. If you are developing in Eclipse, the ADT plugin incrementally builds your project as you make changes to the source code. Eclipse outputs an .apk file automatically to the bin folder of the project, so you do not have to do anything extra to generate the .apk. If you are developing in a non-Eclipse environment, you can build your project with the generated build.xml Ant file that is in the project directory. The Ant file calls targets that automatically call the build tools for you. To run an application on an emulator or device, the application must be signed using debug or release mode. You typically want to sign your application in debug mode when you develop and test your application, because the build tools use a debug key with a known password so you do not have to enter it every time you build. When you are ready to release the application to Google Play, you must sign the application in release mode, using your own private key. Fortunately, Eclipse or your Ant build script signs the application for you in debug mode when you build your application. You can also easily setup Eclipse or your Ant build to sign your application in release mode as well. The following diagram depicts the components involved in building and running an application:
9.A.10.A Detailed Look at the Build Process

The build process involves many tools and processes that generate intermediate files on the way to producing an .apk. If you are developing in Eclipse, the complete build process is automatically done periodically as you develop and save your code changes. If you are using other IDEs, this build process is done every time you run the generated Ant build script for your project. It is useful, however, to understand what is happening under the hood since much of the tools and processes are masked from you. The following diagram depicts the different tools and processes that are involved in a build:
Online Cars System 2013 9.A.11Debugging

9.A.11.1Debugging Environment
.
Figure 1 shows how the various debugging tools work together in a typical debugging environment.
Additional Debugging Tools In addition to the main debugging tools, the Android SDK provides additional tools to help you debug and profile your applications:
9.A.11.2Heirarchy Viewer and layoutopt

Graphical programs that let you debug and profile user interfaces. Traceview A graphical viewer that displays trace file data for method calls and times saved by your application, which can help you profile the performance of your application.

Dev Tools Android application The Dev Tools application included in the emulator system image exposes several settings that provide useful information such as CPU usage and frame rate. You can also transfer the application to a hardware device. Debugging Tips
While debugging, keep these helpful tips in mind to help you figure out common problems with your applications: Dump the stack trace To obtain a stack dump from emulator, you can log in with adb shell, use ps to find the process you want, and thenkill -3. The stack trace appears in the log file. Display useful info on the emulator screen The device can display useful information such as CPU usage or highlights around redrawn areas. Turn these features on and off in the developer settings window as described in Debugging with the Dev Tools App. Get application and system state information from the emulator You can access dumpstate information from the adb shell commands. See dumpsys and dumpstate on the adb topic page. Get wireless connectivity information You can get information about wireless connectivity using DDMS. From the Device menu, select Dump radio state. Log trace data You can log method calls and other tracing data in an activity by calling startMethodTracing(). See Profiling with Traceview and dmtracedump for details. Log radio data By default, radio information is not logged to the system (it is a lot of data). However, you can enable radio logging using the following commands:

adb shell logcat -b radio Capture screenshots The Dalvik Debug Monitor Server (DDMS) can capture screenshots from the emulator. Select Device > Screen capture. Use debugging helper classes Android provides debug helper classes such as util.Log and Debug for your convenience. Garbage collection The debugger and garbage collector are currently loosely integrated. The VM guarantees that any object the debugger is aware of is not garbage collected until after the debugger disconnects. This can result in a buildup of objects over time while the debugger is connected. For example, if the debugger sees a running thread, the associated Thread object is not garbage collected even after the thread terminates.
9.A.12.Google Maps
Maps View It is responsible for viewing the map, move controllers and zoom controllers. It also has an option for displaying bookmarks at their locations on the currently viewed map. Classes related to the Map View There is one class Map View. Google provides via Google play a library for using Google Maps in your application. The following description is based on the Google Maps Android API v1 which provides signi icant improvements to the older API version.

The library provides the com.google.android.gms.maps.MapFragment class and the MapView class for displaying the map component.
Map animated to our desired location
We have provided latitude = 30 and longitude = 71, zooming level =7. The map will center at the provided coordinates at the provided zooming level. I may have forgotten to explain some details so i am attaching the complete code the 3 main iles for this project.
9.A.12.1Location Services
Android gives your applications access to the location services supported by the device through classes in theandroid.location package. The central component of the location framework is the LocationManagersystem service, which provides APIs to determine location and bearing of the underlying device (if available). As with other system services, you do not instantiate a LocationManager directly. Rather, you request an instance from the system by calling getSystemService(Context.LOCATION_SERVICE). The method returns a handle to a new LocationManager instance. Once your application has a LocationManager, your application is able to do three things:

Query for the list of all LocationProviders for the last known user location. Register/unregister for periodic updates of the user's current location from a location provider (specified either by criteria or name). Register/unregister for a given Intent to be fired if the device comes within a given proximity (specified by radius in meters) of a given lat/long.
Flow for obtaining user location Here's the typical flow of procedures for obtaining the user location: 1. Start application. 2. Sometime later, start listening for updates from desired location providers. 3. Maintain a "current best estimate" of location by filtering out new, but less accurate fixes. 4. Stop listening for location updates. 5. Take advantage of the last best location estimate.

Figure 1 demonstrates this model in a timeline that visualizes the period in which an application is listening for location updates and the events that occur during that time.
A timeline representing the window in which an application listens for location updates.
This model of a windowduring which location updates are received frames many of the decisions you need to make when adding location-based services to your application.
Deciding when to start listening for updates
You might want to start listening for location updates as soon as your application starts, or only after users activate a certain feature. Be aware that long windows of listening for location fixes can consume a lot of battery power, but short periods might not allow for sufficient accuracy. As demonstrated above, you can begin listening for updates by calling requestLocationUpdates(): String locationProvider = LocationManager.NETWORK_PROVIDER; // Or, use GPS location data: // String locationProvider = LocationManager.GPS_PROVIDER; locationManager.requestLocationUpdates(locationProvider, 0, 0, locationListener);

Using DDMS With the DDMS tool, you can simulate location data a few different ways: Manually send individual longitude/latitude coordinates to the device. Use a GPX file describing a route for playback to the device. Use a KML file describing individual place marks for sequenced playback to the device. For more information on using DDMS to spoof location data, see Using DDMS.
Using the "geo" command in the emulator console To send mock location data from the command line: 1. Launch your application in the Android emulator and open a terminal/console in your SDK's /toolsdirectory. 2. Connect to the emulator console: telnet localhost <console-port> 3. Send the location data: o geo fix to send a fixed geo-location. This command accepts a longitude and latitude in decimal degrees, and an optional altitude in meters. For example: geo fix -121.45356 46.51119 4392
o
geo nmea to send an NMEA 0183 sentence. This command accepts a single NMEA sentence of type '$GPGGA' (fix data) or '$GPRMC' (transit data). For example: geo nmea $GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62
For information about how to connect to the emulator console, see Using the Emulator Console.

9.A.12.2Navigator
Obtaining API KEY Google requires a different Map API key for each certificate that signs an Android application. What this means for you, is one API key when developing your application and one when you build the production version. API Keys can be obtained without a fee from Google. For more a more in depth overview, read the Google Maps External Library overview. > Note: We hope to provide additional tooling in the future to help with API Key generation and management. There are just a few steps required and while it may look complicated, it's very straight-forward. You should create a document/spreadsheet where you maintain a list of applications and their certi icate hash (MD5) with the corresponding API key. If you decided not to, Google will return you the same API key for the same certificate hash. Process Summary Here are the basic steps. 1. Obtain the MD5 hash of the certi icate 2. While you're logged in to Google(Gmail) paste the MD5 of the certi icate into the appropriate form, agree to the license, and submit. 3. Copy the Map API key that Google creates and save it. (if it's lost simply repeat the process with the same MD5) 4. Put it in tiapp.xml in the property ti.android.google.map.api.key 5. Verify your Android Virtual Device uses the Google APIs system image. <property name="ti.android.google.map.api.key">Your Key Here</property> Obtaining the MD5 Google uses the MD5 ingerprint of the certi icate that signs your mobile application to generate a Maps API Key. This API Key is needed by Titanium when constructing the MapView. When your mobile application is run on the emulator or on a device, the underlying Maps implementation verifies that the

API key used to pull map data matches the certificate which signed your application. To obtain the MD5 you need: 1. The path to the keystore 2. The keystore password 3. The key alias (name) Most likely you generated your production key after referencing HowTo: Package for the Android Market. So the information is only known by you and you just need to fill in the blanks. However, every Titanium Developer installation has a debug key that ships with the mobilesdk so we can use that for our example. The Path to the Keystore This path varies per OS and in the case of Windows, per OS Version. The general pattern is as follows: <pre>OS SPECIFIC ROOT/Titanium/mobilesdk/OS CODE/SDK VERSION/android/dev_keystore</pre> OS X

OS SPECIFIC ROOT: /Library/Application Support/Titanium OS CODE: osx Linux
OS SPECIFIC ROOT: ~/.titanium or /opt/titanium OS CODE: linux Windows - XP >Note: You can always search your drive using dir /s/b titanium from the root of your C drive.
OS SPECIFIC ROOT: C:Documents and SettingsAllUsersApplicationDataTitanium OS CODE: win32 Windows - Vista
OS SPECIFIC ROOT: C:UsersYOURACCOUNTAppDataRoamingTitanium OS CODE: win32 Windows - 7

OS SPECIFIC ROOT: C:ProgramDataTitanium OS CODE: win32 SDK VERSION is usually a string like 0.8.0. The Keystore Password The password for the development key is android The Key Alias The alias for the development key is android; Obtaining the Key <pre>keytool -list -keystore PATH_TO/dev_keystore -alias tidev storepasstirocks</pre> Keytool will output a few lines. The important one is: <pre> Certi icate ingerprint (MD5): 66:5E:D1:7F:C4:2C:B9:73:AD:7F:4D:DD:29:12:56:56</pre>
Google's form wants the information shown in bold, (i.e. just the fingerprint).
Obtaining a Key From Google Once you have the MD5 ingerprint, log in with your Google(Gmail) account and visit the Maps API Key Signup form.
Paste in your fingerprint and agree to the terms then press Generate API Key. You should see a result similar to the image below.

Modify tiapp.xml The final step in this process involves adding a single element to your tiapp.xml. Using your favorite text editor go to your project folder and open your tiapp.xml. Navigate to the bottom of the page and insert the following fragment after the </windows> tag and before the </ti:app> tag.
Verify your AVD Target Google Maps are an add-on and are not part of the open source platform. Most Android devices have shipped with some proprietary Google applications like Maps. However, there are no requirements that a device manufacturer ship a Google Phone. If you do want to run on a non-Google device or emulator system image, you will need to have a different version of your app that doesn't require maps. >Note: The current, 0.8.0, Android mobilesdk ships with embedded Map support. You will need a Google capable device and AVD until we complete the modularization of the SDK. >Note: If you're still on the old Android SDK 1.5 or 1.6 instead of the SDK Kit, you should move up to the new tooling. Future documentation will feature the tools. Specifically the android GUI. Open a command window or terminal and run the following command android list avd The result is a list of all of your AVDs. Titanium Developer uses the AVD named titanium. Look for it in the list.

Odin01:androiddthorp$ android list avd Available Android Virtual Devices: Name: Test1 Path: /Users/dthorp/.android/avd/Test1.avd Target: Android 1.6 (API level 4) Skin: HVGA Sdcard: /Users/dthorp/.titanium/android.sdcard --------Name: titanium Path: /Users/dthorp/.android/avd/titanium.avd Target: Google APIs (Google Inc.) Based on Android 1.5 (API level 3) Skin: HVGA Sdcard: /Users/dthorp/.titanium/android.sdcard Notice there are two devices list. One uses the non-Google aware Android 1.6 (API level 4) target and the other one, titanium, uses the Google APIs (Google Inc.) Based on Android 1.5 (API level 3). If your titanium AVD doesn't use a Google image, you'll need to covert it. The easiest method is to delete the image and let Titanium Developer re-create it. To delete the image run the following command. android delete avd -n titanium Tips
Create a document or spreadsheet where you maintain a list of applications, their certi icate hash (MD5) with the corresponding API key. If you decided not to, Google will return you the same API key for the same certificate hash. The MD5 ingerprint of the debug key is the same, you can just copy the following MD5 ingerprint and use it on the form. The resulting API Key can be used during development for all of your projects. <pre> Certi icate ingerprint (MD5): 66:5E:D1:7F:C4:2C:B9:73:AD:7F:4D:DD:29:12:56:56</pre>
9.A.13Parsing the XML response

This is the third part of the Android Full Application Tutorial series. The complete application aims to provide an easy way of performing

movies/actors searching over the internet. In the first part of the series (Main Activity UI), we created the Eclipse project and set up a basic interface for the main activity of the application. In the second part (Using the HTTP API), we used the Apache HTTP client library in order to consume an external HTTP API and integrate the APIs searching capabilities into our application. In this part we are going to see how to parse the XML response using Androids builtin XML parsing capabilities. The responses are typical XML documents that can be parsed using the standard procedures either using SAX or DOM. The SAX specification defines an event-based approach where the implemented parsers scan through XML data and they use call-back handlers whenever certain parts of the document have been reached. On the other hand, the DOM specification defines a treebased approach to navigating an XML document. In general, SAXs usage is more challenging, because the API requires development of callback functions that handle the events, while the DOM approach requires a bigger memory footprint. For that reason, we are going to choose SAX for our XML parsers implementation, since our application will leave in a rather resource-constrained environment such as a mobile device. we first retrieve a reference of the SAX parser factory class using the newInstance static method of theSAXParserFactory. That method returns the appropriate Android implementation. Then, a SAXParser object is created using thenewSAXParser method, which creates a new instance of a SAXParser using the currently configured factory parameters. The SAXParser class defines the API that wraps an XMLReader implementation class. XMLReader is an interface for reading an XML document using callbacks. The callbacks are defined usually via classes that extend the DefaultHandler class, which is the default base class for SAX2 event handlers.
Speech Input API for Android

People love their mobile phones because they can stay in touch wherever they are. That means not just talking, but e-mailing, texting, microblogging, and so on. So, in addition to search by voice and voice shortcuts like "Navigate to", we included avoice-enabled keyboard in Android 2.1, which makes it even easier

to stay connected. Now you can dictate your message instead of typing it. Just tap the new microphone button on the keyboard, and you can speak just about anywhere you would normally type. We believe speech can fundamentally change the mobile experience. We would like to invite every Android application developer to consider integrating speech input capabilities via the Android SDK. One of my favorite apps in the Market that integrates speech input is Handcent SMS, because you can dictate a reply to any SMS with a quick tap on the SMS popup window. Google's Voice Search application, which is pre-installed on many Android devices, responds to a RecognizerIntent by displaying the "Speak now" dialog and streaming audio to Google's serversthe same servers used when a user taps the microphone button on the search widget or the voice-enabled keyboard. (You can check if Voice Search is installed in Settings Applications Manage applications.) One important tip: for speech input to be as accurate as possible, it's helpful to have an idea of what words are likely to be spoken. While a message like "Mom, I'm writing you this message with my voice!" might be appropriate for an email or SMS message, you're probably more likely to say something like "weather in Mountain View" if you're using Google Search. You can make sure your users have the best experience possible by requesting the appropriate language model: "free_form" for dictation, or "web_search" for shorter, search-like phrases. We developed the "free form" model to improve dictation accuracy for the voice keyboard on the Nexus One, while the "web search" model is used when users want to search by voice. Google's servers currently support English, Mandarin Chinese, and Japanese. The web search model is available in all three languages, while free-form has primarily been optimized for English. As we work hard to support more models in more languages, and to improve the accuracy of the speech recognition technology we use in our products, Android developers who integrate speech capabilities directly into their applications can reap the benefits as well.
PART B :Server Programming :

The server side is responsible for : -collecting feedbacks from the cars for each road. -Analyzing feedbacks and sending the status for any road when requested from a car. -Selecting the best route between a source & destination and sending it when requested from a car. We have executed these functions using PHP scripts and MySQL databases.
9.B,1-collecting feedback from the cars for each road:

When a user sends a feedback to the server,it is inserted into the table called "Status" and stored in the database.
9.B.2-Analyzing feedbacks and Sending the status for any road when requested from a car:
When a user requests the status of a road,we calculate the average status for all feedbacks stored for this road.In addition to that we calculate the standard deviation for these feedback values and hence we can decide either the average value is a right indication for the status of the road or not.This is performed by selecting a threshold value for the standard deviation,if the standard deviation is less than the threshold value, the average is accepted otherwise it will be refused.finally,we respond to the user with the average value which represents the status of the road.
9.B.3-Selecting the best route between a source & destination and sending it when requested from a car:

When a user requests the best route between a source and a destination , we calculate the average status between each 2 connected nodes between the source and the destination.The standard deviation is calculated too between each 2 connected nodes. Hence we can decide either the average value is a right indication for the status of the road or not.This is performed by selecting a threshold value for the standard deviation,if the standard deviation is less than the threshold value, the average is accepted otherwise it will be refused.Then we get the road length between each 2 connected nodes from the Roadlength table. The next step is calculating the weight for each 2 connected nodes.This is performed by multiplying the Average status value by the Roadlength.These weights are used to update the values of the Dijkstra table. Now we create new dijkstra nodes to be used in the algorithm,these nodes are selected from the coordinates table.Then the weights between nodes are provided to the algorithm and finally,the best route is found.

The last step is replying to the user with this best road.

Chapter 10: Documentation

10.1. Reporting system
10.1.1. Project proposal
Project proposal is an abstract for the project that contains information such as: - Project name. - Sponsors name. - Team members. - Supervisor professor. - Small introduction of the problem definition. Describes the current issue(s) or problem(s) that our team intended to solve. - Problem solution as seen by the team members. How are we going to solve the problem? What would improve the present situation? What improvements will result from the implementation of this project? Tell what it is and what it does, NOT HOW IT WORKS (non-technical)] - Business expected customers. Show the market segments that will be interested in our product/service. What are the needs that our project addresses? Why will they buy it? - Market and competition Who are the current competitors? How do we intend to compete ? what is the best market strategy to introduce our product ? Will it be a new product or a product that solves a current problem? - Detailed technical description about the project. Describes our overall design and the underlying technology of our project. Shows also our anticipated plan to finalize the prototype. Will it be pure H/W or pure S/W or mixed? Using appropriate diagrams if needed. - Required hardware and software tools for our project. The needed software/hardware tools to accomplish the project stating: - Company Name - Part number - Count - Of all needed tools An example of a proposal can be found in appendix.

10.1.2 MOMs
A MOM means Minutes of Meeting which is a document that describes a meeting session. A typical MOM contains the following information: - Document properties o Document title. o Author. o Meetings date. - Meeting summary o Attendees from sponsors side. o Attendees from teams side. o Meeting agenda. o General comments and discussion points. o Decision, assignments and action items. o Next meeting time and tentative agenda. MOMs are very helpful for keeping track for our progress, Logging and further documentations. A sample of a MOM can be found the appendix.
10.2. Information-sharing channels

This section describes the tools and methods used by team members to communicate and facilitate the working.
10.2.1. Facebook group

Its a free web based tool . where all members in the team can connect and sharing its work . Ease distribution of tasks (especially documentation-related tasks) between more than one team members.

Appendix A: Sample Documents

A.1. Online forms used in information gathering
Customer: xxxxxxxxx Interviewers: Mohamed Nada Mohamed Eissa Date: 6/28/2013 11:08 Car user Email: xxx@yahoo.com Answer Yes , always - Delay appointments - Loss of time - Increase the pressure nervous Of course 500 EGP
Address: Damietta Telephone: 010 xxxxxxx Type of user: traveler Question Are you suffering from traffic congestion ? Whats hurting you as a result of this ?
After illustrating our solution , do you think our device will help you ? What is the average price you can pay per unit?
A.2. Survey used in organizing needs into a hierarchy
A.3. An Example of a proposal

Mansoura University
Faculty Of Engineering
Communication and Electronics Dep.
Online Cars
Presented By:
1-Mohamed Nada 2-Mohamed Eissa 3-Ahmed El-Emam 4-Amr salah 5-Mohamed Aiad 6-Omar belal 7-Amr El-shame Under Supervision of: Dr. Elsaed Marzouk
Introduction (Problem definition)
Nowadays, technology helps in solving the most complicated problems ever existed in the world helping people to communicate and collaborate. One of the useful technologies that can serve in many applications is the GPS technology. GPS devices can be used in vehicles, navigation, tracking, guiding people, military applications ... etc

Issues or problems that our team intends to solve: - Traffic congestion problem Objectives (Problem Solution) we intended to develop a system which help to solve the traffic problems . we use two main factors in our project . 1- GPS technology 2- users Feedback about the roads GPS: - Global Navigation Satellite Systems (GNSS) is the standard generic term for satellite navigation systems (sat nav) that provide autonomous geo-spatial positioning with global coverage. - GNSS allows small electronic receivers to determine their location (longitude, latitude, and altitude) to within a few meters using time signals transmitted along a line-of-sight by radio from satellites. Receivers calculate the precise time as well as position, which can be used as a reference for scientific experiments. - The Global Positioning System (GPS) is a space-based global navigation satellite system that provides reliable location and time information in all weather and at all times and anywhere on or near the Earth when and where there is an unobstructed line of sight to four or more GPS satellites: o It is maintained by the United States government and is freely accessible by anyone with a GPS receiver. o The Egyptian market has increasing needs for GPS solutions since Egypt has lifted the ban on importing GPS receivers; the countrys National Telecommunication Regulatory Authority is now allowing the importation of devices with civilian applications provided that NTRA authorizes the type of machines based on its criteria and procedures .
Users Feedback about roads :

while the user is driving to reach his destination in a road , we ask him to leave his feedback about road traffic situation , is this road stable ? is it crowded with cars ? , is there any accident ? and then we can use users feedbacks to inform the other users about the roads they

intend to use to reach their destination . and then using the data collected we can select the suitable road to every user to use to reach his destination in a short time . Customers needs as interpreted from the market research - knowing data about the locations and services . - Downloadable on-demand data about the traffic. - Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information - Accurate maps. - Notifications in case of arrival to some pre-defined places. - Downloadable on-demand data about the traffic. - Downloadable on-demand data about the weather. - Pre-defined locations on the map saved along with touristic information - Accurate maps. - Notifications in case of arrival to some pre-defined places. - Implementing an efficient algorithm to find best routes. - Authentication programs in the device. - In Case of Emergency Service. - Connectivity and control with car security system. - TV receiver / Radio receiver. - Extra accessories At 1st of August the prototype should be completed: o The prototype will be based on DevKit8500 development kit provided with 3G and GPS modules. o The presented prototype will be running Android OS The Google OS for mobile platforms-. o Functions will be GPS capabilities, Packet switching capabilities in 3G, storage capabilities in SD card. o Interfacing will be using touch screen. Market and Competition

Market segment will be car drivers and youths. Our project addresses the need of location detection and finding the best paths. Targeted customers buy it because: o Drivers will find it useful to find their current location besides the ability to find their best routes. Our major competitors are the foreigner GPS companies like Navking , Mio Moov and Supernav besides the GPS-enabled mobile manufacturers such as Nokia and SonyEricson. also mobile application based on android OS like wasalny and by2olak - Our competitive edge is to introduce the first made-in-Egypt GPS device which can be as reliable and efficient as imported products with fewer prices. - Our competitors have the strengths of their old repetition in the market and their support. Detailed Technical Description We want to design an Android based hand-held computer/device that is modular enough to operate in different applications (i.e. It can work standalone, can be integrated with car computer, can interface easily with computers ... etc). Our device will be based on a group of libraries that will manage the runtime of applications (launch and terminate) installed on the platform, and also will handle the interaction between the software and the input/output hardware. The system design will allow attaching many types of hardware modules through the system interfaces, and so installed applications can make use of this hardware as input or output. This design will allow modularity. For example, you can attach GSM module then you can write an application that runs under our platform and uses the GSM module to send it through the GSM module to a certain destination (can be considered a tracking device). In the same way you can attach different modules that will allow our device/platform to function in a different way introducing new services (i.e. entertainment, sharing locations, collaborating etc). System architecture: ARM9

System components: e.g. main chipsets, sensors, actuators, devices, 3rd party software....etc. o Development Kit: Devkit8500
GPS Module. o GPRS/GSM Module. o Android OS -Google OS for mobile platforms-. System interfaces, inputs and outputs: o o o o USB. 6.4 Touch Screen. Keypad. Voice Recognition.
Software/Hardware Development Tools Components Components Number of Description name required items Development Devkit8500D 1 kit GPS module GPS8000-S 1 3G module CDMA800-U 1 Touch screen N/A 1 SD card N/A 1 Components Components Number of Description name required items Operating Android 1 System SDK Android SDK 1 IDE Eclipse IDE 1 Company Embest Embest Embest Embest Embest Price US$329 US$59 US$79 Included Included
Company Google Google VisualAge
Price Free Free Free

APPENDIX B:Source Codes

Navigation
package com.onlinecars.Navigation; import java.io.BufferedWriter; importjava.io.OutputStreamWriter; importjava.net.HttpURLConnection; import java.net.URL; importjava.util.List; importjavax.xml.parsers.SAXParser; importjavax.xml.parsers.SAXParserFactory; importorg.xml.sax.Attributes; importorg.xml.sax.SAXException; importorg.xml.sax.helpers.DefaultHandler; importandroid.app.AlertDialog; importandroid.content.DialogInterface; importandroid.graphics.Canvas; importandroid.graphics.Color; importandroid.graphics.Paint; importandroid.graphics.Point; importandroid.graphics.drawable.Drawable; importandroid.os.Bundle; importandroid.util.Log; importandroid.view.MotionEvent; importandroid.widget.Toast; importcom.google.android.maps.GeoPoint; importcom.google.android.maps.MapActivity; importcom.google.android.maps.MapController; importcom.google.android.maps.MapView; importcom.google.android.maps.MyLocationOverlay; importcom.google.android.maps.Overlay; importcom.google.android.maps.OverlayItem;

importcom.google.android.maps.Projection; publicclass Routing extendsMapActivity { MyToastmt = newMyToast(); // variables finalstatic String RoutingUrl = "http://www.onlinecars2013.com/Dijkstra.class.php"; long start, stop; booleansrcdone = false, destdone = false; // MapViewourstismap; MyOverlaymovly; List<Overlay>overlist; MapControllercontmap; // GeoPointtouchedPoint, x, y; GeoPointsrcpoint, destpoint; Drawabledsrc, ddest, more; booleanIN_Road = false; // onCreate Method // publicvoidonCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.routing); ourstismap = (MapView) findViewById(R.id.mapvrout); ourstismap.setBuiltInZoomControls(true); // movly = newMyOverlay(); // MyOverlay Class Object overlist = ourstismap.getOverlays(); // List of Overlays on the map overlist.add(movly); //

contmap = ourstismap.getController();// get Controller contmap.setZoom(5); // set Default Zoom // // dsrc = getResources().getDrawable(R.drawable. asrc); ddest = getResources().getDrawable(R.drawable. bdest); more = getResources().getDrawable(R.drawable. more); x = newGeoPoint((int) (31.25485869712114 * 1E6), (int) (31.65892816378453 * 1E6)); contmap.animateTo(x); contmap.setZoom(12); // /////// ourstismap.setSatellite(false); } @Override protectedbooleanisRouteDisplayed() { // TODO Auto-generated method stub returnfalse; }
classMyOverlayextends Overlay { AlertDialogmyalert;

publicbooleanonTouchEvent(MotionEvent me1, MapView mv1) { int action = me1.getAction(); if (action == MotionEvent.ACTION_DOWN) { start = me1.getEventTime(); // get where I touch in myoverlay int x = (int) me1.getX(); int y = (int) me1.getY(); // convert myoverlay coordinates to mymap coordinates touchedPoint = ourstismap.getProjection().fromPixels(x, y); } if (action == MotionEvent.ACTION_UP) { stop = me1.getEventTime(); } if (stop - start > 2000) { myalert = newAlertDialog.Builder(Routing.this).create(); myalert.setTitle("Routeyourway"); myalert.setButton("Set start", new DialogInterface.OnClickListener() { publicvoidonClick(DialogInterface arg0, int arg1) { if (srcdone == false) { srcpoint = touchedPoint; overlist.clear(); overlist.add(movly); OverlayItem item = newOverlayItem(

touchedPoint, "Start", ""); SimpleItemizedOverlay x = newSimpleItemizedOverlay( dsrc, ourstismap, true); x.addOverlay(item); overlist.add(x); srcdone = true; if (srcdone&&destdone) { getNodenums(RoutingUrl, srcpoint,destpoint); srcdone = false; destdone = false; } } else { Toast tsrcd = Toast.makeText(getBaseContext(),"Only one Source",Toast.LENGTH_LONG); tsrcd.show(); } } }); myalert.setButton3("Set dest.",newDialogInterface.OnClickListener() { publicvoidonClick(DialogInterface arg0, int arg1) { if (destdone == false) { destpoint = touchedPoint;

OverlayItem item = newOverlayItem(touchedPoint, "End", ""); SimpleItemizedOverlay x = newSimpleItemizedOverlay(ddest, ourstismap, true); x.addOverlay(item); overlist.add(x); destdone = true; if (srcdone&&destdone) {getNodenums(RoutingUrl, srcpoint,destpoint); srcdone = false; destdone = false; } } else { Toast tdestd = Toast.makeText(getBaseContext(),"Only one Destination",Toast.LENGTH_LONG); tdestd.show(); } } }); myalert.setButton2("Cancel",newDialogInterface.OnClickL istener() {publicvoidonClick(DialogInterface arg0, int arg1) { myalert.dismiss(); } }); myalert.show();

} returnsuper.onTouchEvent(me1, mv1); } } privatevoidgetNodenums(String url, finalGeoPointsP, finalGeoPointdP) { HttpURLConnectionurlConnection = null; double slat = sP.getLatitudeE6() / 1E6; doubleslng = sP.getLongitudeE6() / 1E6; doubledlat = dP.getLatitudeE6() / 1E6; doubledlng = dP.getLongitudeE6() / 1E6; try { String data = "src_lat=" + slng + "&src_lng=" + slat + "&dst_lat="+ dlng + "&dst_lng=" + dlat; URL urlt = newURL(url); urlConnection = (HttpURLConnection) urlt.openConnection(); urlConnection.setRequestMethod("POST"); urlConnection.setDoOutput(true); urlConnection.setDoInput(true); urlConnection.connect(); SAXParserFactory factory = SAXParserFactory.newInstance(); SAXParsersaxParserno = factory.newSAXParser(); BufferedWriterwr = newBufferedWriter(newOutputStreamWriter(urlConnection.g etOutputStream())); wr.write(data); wr.flush(); wr.close();

DefaultHandlerhandlerno = newDefaultHandler() { String num = null, t_dist; intnumint = 0; String time; double timed, t_distd; // String src,deti; publicvoidstartElement(String uri, String localName, String qName, Attributes attributes) throwsSAXException { if (qName.equalsIgnoreCase("nodes_num_time")) { num = attributes.getValue("nodes_num"); numint = Integer.parseInt(num); time = attributes.getValue("time"); t_dist = attributes.getValue("distance"); timed = Double.parseDouble(time); t_distd = Double.parseDouble(t_dist); Log.d("nodenum", "num=" + numint); Log.d("time", "t=" + timed); if (timed != 0 & timed != -1) { ParsingXml(RoutingUrl, numint, timed, t_distd, sP dP); } else { Toast t = Toast.makeText(getApplicationContext(), "Not Supported !!!", Toast.LENGTH_LONG); t.show();

} } } };
saxParserno.parse(urlConnection.getInputStream(), handlerno);
} catch (Exception e) { Toast t = Toast.makeText(getApplicationContext(),"Not Supported !!!", Toast.LENGTH_LONG); t.show(); overlist.clear(); overlist.add(movly); } } privatevoidParsingXml(String url, finalintnumint, finaldoubletimed,finaldoublet_distd, finalGeoPoint sP1, finalGeoPoint eP1) { HttpURLConnectionurlConnection = null; double slat = sP1.getLatitudeE6() / 1E6; doubleslng = sP1.getLongitudeE6() / 1E6; doubledlat = eP1.getLatitudeE6() / 1E6; doubledlng = eP1.getLongitudeE6() / 1E6; try { overlist.clear(); overlist.add(movly); String data = "src_lat=" + slng + "&src_lng=" + slat + "&dst_lat=" + dlng + "&dst_lng=" + dlat;

URL urlt = newURL(url); urlConnection = (HttpURLConnection)urlt.openConnection( urlConnection.setRequestMethod("POST"); urlConnection.setDoOutput(true); urlConnection.setDoInput(true); urlConnection.connect(); SAXParserFactory factory = SAXParserFactory.newInstance(); SAXParsersaxParser = factory.newSAXParser(); BufferedWriterwr = newBufferedWriter(newOutputStreamWriter( urlConnection.getOutputStream())); wr.write(data); wr.flush(); wr.close(); DefaultHandler handler = newDefaultHandler() { intnums = numint; publicvoidstartElement(String uri, String localName, String qName, Attributes attributes) throwsSAXException { String pathsr = null, speeds = null; String[] pairsr = null; String[] lngLatr; GeoPoint gp1r = null; GeoPoint gp2r = null; inttrafficcolorr = 0; intspeedsintr; String names, times = null, distances;

doubledistd = 0; GeoPointstartGPr = null, ENDGPr = null; for (inti = 1; i<= nums; i++) { if (qName.equalsIgnoreCase("node" + i)) { pathsr = attributes.getValue("coordinates"); names = attributes.getValue("name"); times = attributes.getValue("time"); distances = attributes.getValue("distance"); Log.d("pattth", "path=" + pathsr); speeds = attributes.getValue("speed"); distd = Double.parseDouble(distances); Log.d("speeed", "speeed=" + speeds); speedsintr = Integer.parseInt(speeds); trafficcolorr = getTrafficColor(speedsintr); pairsr = pathsr.split(" , "); lngLatr = pairsr[0].split(","); startGPr = newGeoPoint( (int) (Double.parseDouble(lngLatr[1]) * 1E6), (int) (Double.parseDouble(lngLatr[0]) * 1E6));

String[] lngLatre = pairsr[pairsr.length - 1] .split(","); ENDGPr = newGeoPoint( (int) (Double.parseDouble(lngLatre[1]) * 1E6), (int) (Double.parseDouble(lngLatre[0]) * 1E6)); if (i == 1) { OverlayItem item = newOverlayItem(startGPr, "Start", ""); SimpleItemizedOverlay x = newSimpleItemizedOverlay( dsrc, ourstismap, true); x.addOverlay(item); overlist.add(x); } if (i == nums) { OverlayItem item = newOverlayItem(ENDGPr, "End", ""); SimpleItemizedOverlay x = newSimpleItemizedOverlay( ddest, ourstismap, true); x.addOverlay(item); overlist.add(x); } gp2r = startGPr; for (int j = 1; j <pairsr.length; j++) {

lngLatr = pairsr[j].split(","); gp1r = gp2r; gp2r = newGeoPoint( (int) (Double.parseDouble(lngLatr[1]) * 1E6), (int) (Double.parseDouble(lngLatr[0]) * 1E6)); overlist.add(newnOverlay(gp1r, gp2r, trafficcolorr)); if (j == (int) (pairsr.length / 2)) { OverlayItem item = newOverlayItem(gp2r, names, "Speed = " + speeds + " Km/h" + "\n" + "Takes about " + times + " min." + "\n" + "Distance = " + distd / 1000 + " Km"); SimpleItemizedOverlay x = newSimpleItemizedOverlay( more, ourstismap); x.addOverlay(item); overlist.add(x); }

contmap.animateTo(gp1r); contmap.setZoom(11); } } } if (qName.equalsIgnoreCase("nodes_num_time")) { mt.mytoastlong(getBaseContext(), "This road has a total distance about " + t_distd / 1000 + " Km" + "\n" + "and takes about" + timed + " min."); } } };
saxParser.parse(urlConnection.getInputStream(), handler); } catch (Exception e) { e.printStackTrace(); } } privateintgetTrafficColor(intspdint) { if (spdint<= 10) { returnColor.rgb(0, 0, 0); } elseif (spdint> 10 &&spdint<= 40) {

returnColor.rgb(139, 26, 26); } elseif (spdint> 40 &&spdint<= 85) { returnColor.rgb(255, 127, 36); } else { returnColor.rgb(124, 252, 0); } } classnOverlayextends Overlay { privateGeoPoint gp1; privateGeoPoint gp2; privateinttrafficcolor; publicnOverlay(GeoPoint gp1, GeoPoint gp2, inttrafficcolor) { this.gp1 = gp1; this.gp2 = gp2; this.trafficcolor = trafficcolor; } publicboolean draw(Canvas canvas, MapViewmapv, boolean shadow, long when) { Projection projection = ourstismap.getProjection(); if (shadow == false) { Paint paint = newPaint(); paint.setColor(trafficcolor); paint.setAntiAlias(true); Point point = newPoint(); projection.toPixels(gp1, point); Point point2 = newPoint(); projection.toPixels(gp2, point2); paint.setStrokeWidth(2); paint.setAlpha(215); canvas.drawLine(point.x, point.y, point2.x, point2.y, paint);

} returntrue; } } }
Main activity
package com.onlinecars.aiad;
importandroid.content.Intent; importandroid.location.Location; importandroid.location.LocationManager; importandroid.os.Bundle; importandroid.view.Menu; importandroid.view.View; importandroid.view.View.OnClickListener; importandroid.widget.Button; importandroid.widget.TextView; importcom.google.android.maps.GeoPoint; importcom.google.android.maps.MapActivity; importcom.google.android.maps.MapController; importcom.google.android.maps.MapView;
publicclassMainActivityextendsMapActivityimplementsOnCl ickListener { GeoPoint x; Button buttonfb; intuo ; MapControllercon ; privateLocationManagermyLocationManager; TextView text;
@Override protectedvoidonCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); MapView map =(MapView) findViewById(R.id.mapView); map.setBuiltInZoomControls(true); map.setClickable(true); map.getController().setZoom(12); MapController con =map.getController(); x = newGeoPoint((int) (31.25485869712114 * 1E6), (int) (31.65892816378453 * 1E6)); con.animateTo(x); //Button fbButton = (Button) findViewById(R.id.button1); //fbButton.setOnClickListener(this); }
@Override publicbooleanonCreateOptionsMenu(Menu menu) { // Inflate the menu; this adds items to the action bar if it is present. getMenuInflater().inflate(R.menu.main, menu); returntrue; } @Override protectedbooleanisRouteDisplayed() { // TODO Auto-generated method stub returnfalse; }

@Override publicvoidonClick(View v) { // TODO Auto-generated method stub startActivity(new Intent(this, Radio.class));
} publicvoid location(GeoPointmylocation){ Location initLocation=myLocationManager.getLastKnownLocation(Loc ationManager.GPS_PROVIDER); if(initLocation != null) { GeoPointinitGeoPoint = newGeoPoint( (int)(initLocation.getLatitude()*1000000), (int)(initLocation.getLongitude()*1000000)); } }
Radio Group class

package com.onlinecars.aiad; importandroid.app.Activity; importandroid.content.DialogInterface; importandroid.os.Bundle; importandroid.view.View;

importandroid.view.View.OnClickListener; importandroid.widget.Button; importandroid.widget.RadioGroup; importandroid.widget.RadioGroup.OnCheckedChangeListener ; importandroid.widget.TextView; publicclass Radio extends Activity implements OnCheckedChangeListener { int arg1 ; Button returnButton; RadioGrouprg; TextView text; @Override protectedvoidonCreate(Bundle savedInstanceState) { // TODO Auto-generated method stub super.onCreate(savedInstanceState); setContentView(R.layout.radio); intitilaize(); }
privatevoidintitilaize(){ rg = (RadioGroup) findViewById(R.id.radiogroup); rg.setOnCheckedChangeListener(this); }
@Override publicvoidonCheckedChanged(RadioGroup arg0, int arg1) { // TODO Auto-generated method stub switch(arg1){ caseR.id.za7ma:

arg1 =5 ; break; caseR.id.radioButton4: arg1 = 4 ; break; caseR.id.nosnos: arg1 = 3 ; break; caseR.id.radioButton2: arg1 = 2 ; break; caseR.id.fady: arg1 = 1 ; break; } }
Android Mainfaist
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/andro id"

package="com.onlinecars.aiad" android:versionCode="1" android:versionName="1.0" > <uses-sdkandroid:minSdkVersion="8" android:targetSdkVersion="8" />
<uses-permission android:name="android.permission.INTERNET" /> <usespermissionandroid:name="android.permission.ACCESS_COARS E_LOCATION"/> <usespermissionandroid:name="android.permission.ACCESS_FINE_ LOCATION"/> <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <uses-library android:name="com.google.android.maps" /> <activity android:name="com.onlinecars.aiad.MainActivity" android:label="@string/app_name" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="com.onlinecars.aiad.Radio" android:label="@string/app_name" > <intent-filter> <action android:name="com.onlinecars.aiad.Radio" />

<category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity> </application> </manifest>
Activity_main
<RelativeLayoutxmlns:android="http://schemas.android.co m/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" tools:context=".MainActivity"> <com.google.android.maps.MapView android:id="@+id/mapView" android:layout_width="fill_parent" android:layout_height="fill_parent" android:apiKey="0qr9OrCyW4vbBZTUXTwHjAKMMXffN59z59KJuQ" android:clickable="true" android:enabled="true" />
</RelativeLayout>
Radio xml
<?xml version="1.0" encoding="utf-8"?>

<RadioGroupxmlns:android="http://schemas.android.com/ap k/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:id="@+id/radiogroup"> <RadioButton android:id="@+id/za7ma" android:layout_width="match_parent" android:layout_height="wrap_content" android:checked="true" android:text="Za7ma gedan" /> <RadioButton android:id="@+id/radioButton4" android:layout_width="wrap_content" android:layout_height="wrap_content" android:checked="true" android:text="za7ma" /> <RadioButton android:id="@+id/nosnos" android:layout_width="wrap_content" android:layout_height="wrap_content" android:checked="true" android:text="nosnos" /> <RadioButton android:id="@+id/radioButton2" android:layout_width="wrap_content" android:layout_height="wrap_content" android:checked="true" android:text="fady" /> <RadioButton android:id="@+id/fady" android:layout_width="wrap_content" android:layout_height="wrap_content" android:checked="true"

android:text="fadygedan" /> <Button android:id="@+id/returnb" android:layout_width="130dp" android:layout_height="wrap_content" android:text="return" /> </RadioGroup>

AB2:Server Side Code: Important Note :
This is not the final code.
<?php /** * Dijkstra algorithm node class * * @author Mallory Dessaintes - hide@address.com */ class DijkstraNode { const IMPOSSIBLE_DIST = -1; //Eissa protected is used in class and inhirited classes or called protected $_id; protected $_neighbours = array(); protected $_distToSource = self::IMPOSSIBLE_DIST; //Eissa Use $this to refer to the current object. Use self to refer to the current class. In other words, use $this->member for nonstatic members, use self::$member for static members. protected static $_nodes = array(); public function __construct($id,$links = array()) { $this->_id = $id; $this->_neighbours = $links; static::$_nodes[] = $this; } /** * Return all the nodes created */ public static function getNodes() { return static::$_nodes; } /** * Add a neighbour to the node, specifying the distance between it and the current node

* * @param bool $reciprocally Current node is also add as a neighbour of the given node */ public function addNeighbour(DijkstraNode $node,$dist = 1,$reciprocally = true) { if(!isset($this->_neighbours[$node->_id])) { $this->_neighbours[$node->_id] = array('node' => $node, 'dist' => $dist); if($reciprocally) { $node->_neighbours[$this->_id] = array('node' => $this, 'dist' => $dist); } } else { trigger_error('Neighbour already exists'); } } /** * Return the neighbours of the node */ public function getNeighbours() { return array_values($this->_neighbours); } /** * Return the distance between the current node and another node (normally a neighbour node) */ public function getNeighbourDist(DijkstraNode $node) { if($node == $this) { return 0; } else { if(isset($this->_neighbours[$node->_id])) { return $this->_neighbours[$node->_id]['dist']; } else { // Node is not a neighbour return self::IMPOSSIBLE_DIST; } }

} public function getId() { return $this->_id; } public function getDistToSource() { return $this->_distToSource; } public function setDistToSource($val) { $this->_distToSource = $val; } } /** * Main Dijkstra algorithm class * * @author Mallory Dessaintes - hide@address.com */ class Dijkstra { protected static $_preds; // predecessors of the nodes protected static $_toVisit; // nodes to visit protected static $_visited; // nodes already visited protected static $_source; // Source node /** * Use Dijkstra algorithm to find the best route between source and all the nodes * * @param array $nodes All the nodes, including the source * @param DijkstraNode $source The source node * (we just use it to set the distance between it and "source" to 0, of course) and get a starting point * * @return */ public static function findRoute($nodes,DijkstraNode $source) { static::$_toVisit = $nodes; static::$_source = $source; static::_init(); while(count(static::$_toVisit)) {

static::_sortNodes(); $node = static::$_toVisit[0]; // Remove the current node from nodes to visit unset(static::$_toVisit[array_search($node,static::$_toVisit)]); // Test if have already found a path to this this which must be done ewcept if there iq no path if($node->getDistToSource() != DijkstraNode::IMPOSSIBLE_DIST) { // Foreach neighbours of the current node foreach($node->getNeighbours() as $neighbourData) { $neighbour = $neighbourData['node']; // $neighbourData['dist'] = the distance between the node and this neighbour // Only if we doesn't already visited it (because if we had, the last past was necessarily shorter) if(in_array($neighbour,static::$_toVisit)) { // This is the current shortest distance between the neighbour in the loop and the source $neighbourDistSource = $neighbour>getDistToSource(); // This is the current shortest distance between the current node and the // source + the distance between the current node and the neighbour $neighbourDistCurrent = ($node>getDistToSource() + $node->getNeighbourDist($neighbour)); // Checking if it is faster to go to the neighbour by the current node (or if the neighbour hasn't been reached yet (IMPOSSIBLE_DIST)) if($neighbourDistSource == DijkstraNode::IMPOSSIBLE_DIST OR ($neighbourDistCurrent < $neighbourDistSource)) { // Set the new shortest distance between the neighbour and the source

$neighbour>setDistToSource($neighbourDistCurrent); // Set the new predecessor of the neighbour in the path to the source static::$_preds[$neighbour>getId()] = $node->getId(); } } } } // Add the current node to the visited nodes static::$_visited[] = $node; } $arrNodesDistsToSource = array(); // Setting an array having key => nodeId, value => min distance to this node from the source foreach(static::$_visited as $node) { $arrNodesDistsToSource[$node->getId()] = $node>getDistToSource(); } $ret = array( 'paths' => static::$_preds, // key => node id, value => predecessor (node id) in the shortest path to the source 'pathsCosts' => $arrNodesDistsToSource // Look at the last loop ); return $ret; } private static function _init() { // Setting all predecessors of the nodes to null because default, they are unreachable foreach(static::$_toVisit as $node) { static::$_preds[$node->getId()] = null; }

// Setting the distance between the source and itself to 0 to get // a starting point in the algorithm (see sortNodes) static::$_source->setDistToSource(0); } /** * This sort the nodes to visit by their current shortest distances to the source * This method pay attention to IMPOSSIBLE_DIST which is set to 1 */ private static function _sortNodes() { usort(static::$_toVisit, function ($a,$b) { $aDistToSource = $a->getDistToSource(); $bDistToSource = $b->getDistToSource(); if($aDistToSource == DijkstraNode::IMPOSSIBLE_DIST AND $bDistToSource == DijkstraNode::IMPOSSIBLE_DIST) { return 0; } elseif($aDistToSource == DijkstraNode::IMPOSSIBLE_DIST) { return 1; } elseif($bDistToSource == DijkstraNode::IMPOSSIBLE_DIST) { return -1; } elseif($aDistToSource > $bDistToSource) { return 1; } else if($aDistToSource < $bDistToSource) { return -1; } else { return 0; } } ); } }
$con = mysql_connect("localhost","root",""); $db = mysql_select_db("online cars");
$query11 = 'SELECT * FROM dijkstra '; $result11 = mysql_query($query11); while($row11=mysql_fetch_assoc($result11)){ $source=$row11["from"]; $destination=$row11["to"];
echo $source; echo "<hr>"; echo $destination; echo "<hr>";
$row1 =mysql_fetch_array(mysql_query("SELECT AVG(status) FROM status WHERE source = '$source' and destination = '$destination'")); //echo $row1['result']; //echo "<hr>";
AS result
$avg = $row1['result']; echo $avg ; echo "<hr>";
$row2 =mysql_fetch_array(mysql_query("SELECT STDDEV(status) FROM status WHERE source = '$source' and destination = '$destination'")); //echo $row2['result'];
AS result

//echo "<hr>"; $sd = $row2['result']; echo $sd ; echo "<hr>"; if ($sd<=1) {echo "rrrrr"; echo"<hr>"; } else { $avg = 2.5 ; echo $avg ; echo"<hr>"; }
$query = "SELECT * FROM `roadlength` WHERE `from` = '$source' and `to` = '$destination' "; $result = mysql_query($query); $row=mysql_fetch_assoc($result); $len=$row["length"]; echo "$len"; echo"<hr>";
$weight = $avg * $len ; echo "$weight" ; echo"<hr>";
$query = "UPDATE `dijkstra` SET `weight`= '$weight' WHERE `from`= '$source' and `to` = '$destination' " ; $mmm = mysql_query($query);
$query11 = 'SELECT * FROM coordinates '; $result11 = mysql_query($query11); while($row11=mysql_fetch_assoc($result11)){ $i=$row11["point"]; $$i=new DijkstraNode ("$i"); } /* //
// check for required fields if (isset($_POST['srclong']) && isset($_POST['srclat']) && isset($_POST['dstlong']) && isset($_POST['dstlat'])) { $srclong = $_POST['srclong']; $srclat = $_POST['srclat']; $dstlong = $_POST['dstlong']; $dstlat = $_POST['dstlat'];
} * * */
$srclong = 31.036168 ; $srclat = 31.365559 ; $dstlong = $dstlat = 31.373284 ;
31.031553;
$query = "SELECT * FROM `coordinates` WHERE `long` = and `lat` = $srclat "; $result = mysql_query($query); $row=mysql_fetch_assoc($result); $src=$row["point"];
$srclong
$query1 = "SELECT * FROM coordinates WHERE `long` =$dstlong and `lat` = $dstlat"; $result1 = mysql_query($query1); $row1=mysql_fetch_assoc($result1); $dst=$row1["point"];

echo $src ; echo " "; echo $dst ; echo " ";
$query2="SELECT * FROM dijkstra"; $result2=mysql_query($query2); while($row2=mysql_fetch_assoc($result2)){ $X=$row2["from"]; $Y=$row2["to"]; $Z=$row2["weight"]; $$X->addNeighbour($$Y,$Z); } $nodes = DijkstraNode::getNodes(); $dijkstra = Dijkstra::findRoute($nodes,$$src); // This contains an array which has as key the id of the nodes and for value // the predecessor of the node in the shortest path to the source $paths = $dijkstra['paths']; // This contains the shortest path cost foreach node (indexed by node id) $pathsCosts = $dijkstra['pathsCosts']; foreach($paths as $nodeId => $nodePred) { $pred = $nodePred; $cPath = array($nodeId); while($pred) { $cPath[] = $pred; $pred = $paths[$pred]; } $cPath = array_reverse($cPath);

if ($nodeId==$dst){ echo 'Shortest path to '.$nodeId.' : '.implode('-',$cPath).' ('.$pathsCosts[$nodeId].') '; } } ?>

About Online Cars Team members

Mohamed Saad Nada
Project Participations Team Leader. low level Programming. public relations algorithm planning Documentation Academic Achievements Last grade: Very Good. Non-Academic Achievements Exhibitor at EED 2012 CAT Member. CAT scope 12 speaker . Trainings CCNA CCNP CCNA security MCSA RHCSA VB programming Damie a port summer Training 2011 and 2012 . NU100 2013 Training.
Mohamed El-saed Eissa

Project Participations PHP programming managing MSQL database college relations competitions contact person documentation. Academic Achievements Last grade: Fair Non-Academic Achievements

Exhibitor at EED 2012 YIA ambassador , Mansura university Nozom (for IT and entrepreneurship ) member Trainings CCNA Micro controller Telecom Egypt summer training NU100 2013 Training.
Mohamed Mohamed Aiad

Project participations Android Developing. GUI Programming. Academic achievements Last grade: Very Good. Technical knowledge Programming: Java,VB.
Ahmed Adel El-Emam

Project Participations low level Programming. algorithm planning Documentation Academic Achievements Last grade: Very Good. Trainings CCNA CCNP CCNA security RHCSA / RHCSE Damie a port summer Training 2011 and 2012 .

Amr Salah El-behede

Project Participations Android Developing. GUI Programming Academic Achievements Last grade: Very Good. Non-Academic Achievements IEEE Member. Trainings CCNA GSM Damie a port summer Training 2012 .
Amr El-shamy
Project Participations Android Developing. GUI Programming Academic Achievements Last grade: Good. Non-Academic Achievements IEEE Member. Trainings CCNA GSM
Omar Mohamed Belel

Project Participations Android Developing. PHP programming low level programing Academic Achievements

Last grade: Good. Non-Academic Achievements IEEE Member. Trainings CCNA GSM
Refrences:
- Android Porting Guide,(2012),http://pdk.android.com,accessed Oct 2012 Android Source, (2012),http://source.android.com, accessed Oct 2012 - Android the OS Wikipedia http://en.wikipedia.org/wiki/Android_(operating_system), (2012) accessed - Dalvik VM Wikipedia,(2012): (http://en.wikipedia.org/wiki/Dalvik_(software accessed - Apress - Pro Android 2, ISBN-13/EAN: 9781430226598 - by Sayed Y. Hashimi Satya Komatineni and Dave MacLean. - DevKit8500 Manuals - JENKOV, (2010), http://tutorials.jenkov.com/java-reflection/dynamicclassloading-reloading.html, accessed February 2013. - Dijekstra Algorithm, (2013) http://en.wikipedia.org/wiki/ Dijekstra_Algorithm - Apress.Android.Essentials By Chris Haseman - Product Design and Development - third edition by Karl T. Ulrich Steven D Eppinge - Beginning Android by Mark Murphy - RENAULD WALDURA, (2007), /http://renaud.waldura.com/doc/java/dijkstra and

- online Java tutorials http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/
- Java How to Program, 6th Ed 2004 By H. M. Deitel - Deitel & Associates, Inc., P. J . Deitel - Deitel & Associates, Inc. - PANYAM, (2008), http://panyam.wordpress.com/2008/03/07/androidhackparcellable-in-eclipse/, accessed Dec 2009 - Android developers Guide, (2013),http://developer.android.com/reference - Android developers Group,(2013), http://groups.google.com/group/androiddevelopers - writing c code for android,(2010),http://www.linuxmag.com/id/7697,accessed Modular GPS Platform 2010 by - Android gestures http://developer.android.com/reference/android/gesture/package summary.html - "android-serial port API",(2013),"http://code.google.com/p/androidserialportapi/" - Beginning Android 2 by By Mark L Murphy - Professional Android programming by Reto Meier - Java, XML, and JAXP by Arthur Griffith - Android Application Development By Rick Rogers, John Lombardo, Zigurd

- Mednieks, G. Blake Meike

Online Cars System

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Online Cars System

Încărcat de

Drepturi de autor:

Formate disponibile

MANSOURA UNIVERSITY FACULTY OF ENGINEERING Electronics and communications

DESIGN AND IMPLMENTATION OF

Online Cars System

Dr. El-saeid Marzouk

Online Cars System

3.3. Market Plan ____________________________________________________ 16 3.3.1. Compe ve Strategy __________________________________________________ 16

Online Cars System 2013

About GPS Technology

Receiver Clock Error

Online Cars System 2013

Online Cars System 2013

Online Cars System 2013

Online Cars System 2013

the page left intentionally..........

Online Cars System 2013

Chapter 1:Team Building, Mission Zero and Project

1.2. Project Selection

Online Cars System 2013

Online Cars System 2013

Online Cars System 2013

Online Cars System 2013

Users Feedback about roads :

2.3.Customers needs as interpreted from the market research

Online Cars System 2013

2.4.Business Objectives of the Project

2.5. Market and Competition

Online Cars System 2013

2.6. Breakdown Structure

Online Cars System 2013 Our Mind Map

Online Cars System 2013

Online Cars System 2013

Chapter 3:Market Research

3.2. Identifying Opportunities

Online Cars System 2013

3.3. Market Plan

Online Cars System 2013

3.4.3. Product Platform Planning

3.4.Allocate Pre-Project Resources and Time Planning

Online Cars System 2013

3.5.Complete Pre-Project Planning

Online Cars System 2013

3.6.Identifying Customer needs

Online Cars System 2013

3.7. Software and Hardware Tools

Development kit GPS module 3G module Touch screen SD card

Devkit8500D GPS8000-S CDMA800-U N/A N/A

Embest Embest Embest Embest Embest

US$329 US$59 US$79 Included Included

Operating System SDK IDE

Android Android SDK Eclipse IDE

Google Google VisualAge

Free Free Free

Online Cars System 2013

the page left intentionally..........

Online Cars System 2013

Chapter 4: Vision Scope and Project Plan

4.1.2. Usage Scenarios

4.1.2.1. Present Scenarios

Online Cars System 2013

4.1.2.2. Future Scenarios

Scenario 2 Each Road is a community :

Online Cars System 2013

4.2.1.Feature / Function List

3.3. Market Plan __ 16 3.3.1. Compe ve Strategy 16