With the rise of the Internet of Things, Android phones with its unique advantage of being open for us to provide more quality and convenient technological achievements. The research is based on the Android mobile phone Bluetooth controlled smart car design, based on mobile platforms, by means of Bluetooth technology, design and implementation of a wireless remote control car new solutions. Control platform designed for mobile phones, Bluetooth communication module, motor drive modules and other hardware modules remote control car. Realize the car forward, backward, turn left in front, front right turn after turn left, turn right after the other real-time control functions. For the remote control toy car design presents a new way of thinking, and can for the future smart home remote control designed to provide some reference value.
Describes one kind of walking through the phone's Bluetooth remote control car software and hardware design. Bluetooth mobile phone as a client, a small car Bluetooth Module HC-06 as a server. Clients using the Eclipse development environment, JAVA programming, client services using micro-controller. The two sides communicate through the serial port, the microcontroller drive DC motor control car action. Experimental results show that the car can receive mobile phone remote control signals and the flexibility to move forward, backward, turn left, turn right and stop functions.
Introduces the based on Andrews's the Bluetooth intelligent trolley control want to achieve the function is trolley be able to forward, backward, turn left, turn right, then expounded that the system circuit design and principle of description, including the program design, it is important components introduction, circuit design Description of (, including SCM control circuit, the motor drive circuit) Andrews mobile phone software interface design, software design flow as well as system debugging. Finally summed up the based on Andrews's the Bluetooth intelligent trolley control design is completed the task of, analysis system appear deficiencies.
【Key words】Andriod Bluetooth Intelligent car Smartphone AT89C52 SCM
[17]Jeff Six ，Application Security for the Android Platform: Processes,
Permissions, and Other Safeguards，2011：460-462 [18]Godfrey Nolan ，Decompiling Android，2012：158
[19]雷明剑. Java Applet技术在网络管理中的研究及应用[D]. 重庆：重庆
大学，2007.
[20]张桂珠,刘丽,陈爱国.Java面向对象程序设计[M].北京邮电大学出版社
（第2版）
[21]Ken Dunham ，Mobile Malware Attacks and Defense，2008：162 [22]Graham J. Lee ，Professional Cocoa Application Security，2010：117-119 [23]毕广吉.Java程序设计实例教程[M]. 北京：冶金工业出版社，2007 年[24]李宁Android开发权威指南.北京：人民邮电出版社，2011.9 第一版：27-32 [25]郭天祥.新概念51单片机C语言教程.北京：电子工程出版社，2009.1：
98-103
45
附录
一、英文原文
Application Fundamentals
Android applications are written in the Java programming language. The compiled Java code —along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. This file is the vehicle for distributing the application and installing it on mobile devices; it's the file users download to their devices. All the code in a single .apk file is considered to be one application.
In many ways, each Android application lives in its own world:
1. By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications.
2. Each process has its own virtual machine (VM), so application code runs in isolation from the code of all other applications.
3. By default, each application is assigned a unique Linux user ID. Permissions are set so that the application's files are visible only to that user and only to the application itself — although there are ways to export them to other applications as well.
It's possible to arrange for two applications to share the same user ID, in which case they will be able to see each other's files. To conserve system resources, applications with the same ID can also arrange to run in the same Linux process, sharing the same VM.
Application Components
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that
46
scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
For this to work, the system must be able to start an application process when any part of it is needed, and instantiate the Java objects for that part. Therefore, unlike applications on most other systems, Android applications don't have a single entry point for everything in the application (no main() function, for example). Rather, they have essential components that the system can instantiate and run as needed. There are four types of components:
Activities
An activity presents a visual user interface for one focused endeavor the user can undertake. For example, an activity might present a list of menu items users can choose from or it might display photographs along with their captions. A text messaging application might have one activity that shows a list of contacts to send messages to, a second activity to write the message to the chosen contact, and other activities to review old messages or change settings. Though they work together to form a cohesive user interface, each activity is independent of the others. Each one is implemented as a subclass of the Activity base class.
An application might consist of just one activity or, like the text messaging application just mentioned, it may contain several. What the activities are, and how many there are depends, of course, on the application and its design. Typically, one of the activities is marked as the first one that should be presented to the user when the application is launched. Moving from one activity to another is accomplished by having the current activity start the next one.
Each activity is given a default window to draw in. Typically, the window fills the screen, but it might be smaller than the screen and float on top of other windows. An activity can also make use of additional windows —for example, a pop-up dialog that calls for a user response in the midst of the activity, or a window that presents users with vital information when they select a particular item on-screen.
The visual content of the window is provided by a hierarchy of views —objects derived from the base View class. Each view controls a particular rectangular space within the window. Parent views contain and organize the layout of their children. Leaf views (those at the bottom of the hierarchy) draw in the
47
rectangles they control and respond to user actions directed at that space. Thus, views are where the activity's interaction with the user takes place.
For example, a view might display a small image and initiate an action when the user taps that image. Android has a number of ready-made views that you can use —including buttons, text fields, scroll bars, menu items, check boxes, and more.
A view hierarchy is placed within an activity's window by the Activity.setContentView() method. The content view is the View object at the root of the hierarchy. (See the separate User Interface document for more information on views and the hierarchy.)
Services
A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.
A prime example is a media player playing songs from a play list. The player application would probably have one or more activities that allow the user to choose songs and start playing them. However, the music playback itself would not be handled by an activity because users will expect the music to keep playing even after they leave the player and begin something different. To keep the music going, the media player activity could start a service to run in the background. The system would then keep the music playback service running even after the activity that started it leaves the screen.
It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). While connected, you can communicate with the service through an interface that the service exposes. For the music service, this interface might allow users to pause, rewind, stop, and restart the playback.
Like activities and the other components, services run in the main thread of the application process. So that they won't block other components or the user interface, they often spawn another thread for time-consuming tasks (like music playback). See Processes and Threads, later.
Broadcast receivers
48
A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many broadcasts originate in system code —for example, announcements that the timezone has changed, that the battery is low, that a picture has been taken, or that the user changed a language preference. Applications can also initiate broadcasts —for example, to let other applications know that some data has been downloaded to the device and is available for them to use.
An application can have any number of broadcast receivers to respond to any announcements it considers important. All receivers extend the Broadcast Receiver base class.
Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the Notification Manager to alert the user. Notifications can get the user's attention in various ways — flashing the backlight, vibrating the device, playing a sound, and so on. They typically place a persistent icon in the status bar, which users can open to get the message.
Content providers
A content provider makes a specific set of the application's data available to other applications. The data can be stored in the file system, in an SQLite database, or in any other manner that makes sense. The content provider extends the Content Provider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls. However, applications do not call these methods directly. Rather they use a Content Resolver object and call its methods instead. A Content Resolver can talk to any content provider; it cooperates with the provider to manage any interprocess communication that's involved.
See the separate Content Providers document for more information on using content providers.
Whenever there's a request that should be handled by a particular component, Android makes sure that the application process of the component is running, starting it if necessary, and that an appropriate instance of the component is available, creating the instance if necessary.
Activating components: intents
49
Content providers are activated when they're targeted by a request from a Content Resolver. The other three components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents. An intent is an Intent object that holds the content of the message. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. For example, it might convey a request for an activity to present an image to the user or let the user edit some text. For broadcast receivers, the
Intent object names the action being announced. For example, it might announce to interested parties that the camera button has been pressed.
There are separate methods for activating each type of component:
1. An activity is launched (or given something new to do) by passing an Intent object to
Context.start Activity() or Activity .start Activity For Result(). The responding activity can look at the initial intent that caused it to be launched by calling its get Intent() method. Android calls the activity's on New Intent() method to pass it any subsequent intents. One activity often starts the next one. If it expects a result back from the activity it's starting, it calls start Activity For Result() instead of start Activity(). For example, if it starts an activity that lets the user pick a photo, it might expect to be returned the chosen photo. The result is returned in an Intent object that's passed to the calling activity's on Activity Result() method.
2. A service is started (or new instructions are given to an ongoing service) by passing an Intent object to Context. Start Service(). Android calls the service's on Start() method and passes it the Intent object. Similarly, an intent can be passed to Context. Bind Service() to establish an ongoing connection between the calling component and a target service. The service receives the Intent object in an on Bind() call. (If the service is not already running, bind Service() can optionally start it.) For example, an activity might establish a connection with the music playback service mentioned earlier so that it can provide the user with the means (a user interface) for controlling the playback. The activity would call bind Service() to set up that connection, and then call methods defined by the service to affect the playback.
A later section, Remote procedure calls, has more details about binding to a service.
50
3. An application can initiate a broadcast by passing an Intent object to methods like Context. Send Broadcast(), Context. Send Ordered Broadcast(), and Context. Send Sticky Broadcast() in any of their variations.
Android delivers the intent to all interested broadcast receivers by calling their on Receive() methods. For more on intent messages, see the separate article, Intents and Intent Filters.
Shutting down components
A content provider is active only while it's responding to a request from a Content Resolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
1. An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with start Activity For Result()) by calling finish Activity().
2. A service can be stopped by calling its stop Self() method, or by calling Context .stop Service().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components. A later section, Component Lifecycles, discusses this possibility and its ramifications in more detail.
The manifest file
Before Android can start an application component, it must learn that the component exists. Therefore, applications declare their components in a manifest file that's bundled into the Android package, the .apk file that also holds the application's code, files, and resources.
The manifest is a structured XML file and is always named AndroidManifest.xml for all applications. It does a number of things in addition to declaring the application's components, such as naming any libraries the application
51
needs to be linked against (besides the default Android library) and identifying any permissions the application expects to be granted.
But the principal task of the manifest is to inform Android about the application's components. For example, an activity might be declared as follows:
The name attribute of the element names the Activity subclass that implements the activity. The icon and label attributes point to resource files containing an icon and label that can be displayed to users to represent the activity.
The other components are declared in a similar way — elements for services, elements for broadcast receivers, and elements for content providers. Activities, services, and content providers that are not declared in the manifest are not visible to the system and are consequently never run. However, broadcast receivers can either be declared in the manifest, or they can be created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling Context.registerReceiver().
For more on how to structure a manifest file for your application, see The Android Manifest.xml File.
Intent filters
An Intent object can explicitly name a target component. If it does, Android finds that component (based on the declarations in the manifest file) and activates it. But if a target is not explicitly named, Android must locate the best component to respond to the intent. It does so by comparing the Intent object to the intent filters of potential targets. A component's intent filters inform Android of the kinds of intents the component is able to handle. Like other essential information about the component, they're declared in the manifest file. Here's an extension of the previous example that adds two intent filters to the activity:
The first filter in the example —the combination of the action "android.intent.action.MAIN" and the category
"android.intent.category.LAUNCHER" —is a common one. It marks the activity as one that should be represented in the application launcher, the screen listing applications users can launch on the device. In other words, the activity is the
52
entry point for the application, the initial one users would see when they choose the application in the launcher.
The second filter declares an action that the activity can perform on a particular type of data.
A component can have any number of intent filters, each one declaring a different set of capabilities. If it doesn't have any filters, it can be activated only by intents that explicitly name the component as the target.
For a broadcast receiver that's created and registered in code, the intent filter is instantiated directly as an IntentFilter object. All other filters are set up in the manifest.
For more on intent filters, see a separate document, Intents and Intent Filters.