Android外文文献翻译
Android Application Fundamentals
Android applications are written in the Java programming language. The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file that Android-powered devices use to install the application.
Once installed on a device, each Android application lives in its own security sandbox:
The Android operating system is a multi-user Linux system in which each application is a different user.
By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications.
By default, every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other applications. In this way, the Android system implements the principle of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an application cannot access parts of the system for which it is not given permission.
However, there are ways for an application to share data with other applications and for an application to access system services:
It's possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each other's files. To conserve system resources, applications with the same user ID can also arrange to run in the same Linux process and share the same VM (the applications must also be signed with the same certificate).
An application can request permission to access device data such as the user's contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All application permissions must be granted by the user at install time.
That covers the basics regarding how an Android application exists within the system. The rest of this document introduces you to:
1、The core framework components that define your application.
2、The manifest file in which you declare components and required device features for your application.
3、Resources that are separate from the application code and allow your application to gracefully optimize its behavior for a variety of device configurations.
Application Components
Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your application's overall behavior.
There are four different types of application components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of application components:
Activities
An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email application, each one is independent of the others. As such, a different application can start any one of these activities (if the email application allows it). For example, a camera application can start the activity in the email application that composes new mail, in order for the user to share a picture.
An activity is implemented as a subclass of Activity and you can learn more about it in the Activities developer guide.
Services
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For
example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.
A service is implemented as a subclass of Service and you can learn more about it in the Services developer guide.
Content providers
A content provider manages a shared set of application data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the user's contact information. As such, any application with the proper permissions can query part of the content provider (such as ContactsContract.Data) to read and write information about a particular person.
Content providers are also useful for reading and writing data that is private to your application and not shared. For example, the Note Pad sample application uses a content provider to save notes.
A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other applications to perform transactions. For more information, see the Content Providers developer guide.
Broadcast receivers
A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. 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. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.
A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is delivered as an Intent object. For more information, see the BroadcastReceiver class.
A unique aspect of the Android system design is that any application can start another application’s component. For example, if you want the user to capture a photo with the device camera, there's probably another application that does that and your application can use it, instead of developing an activity to capture a photo yourself. You don't need to incorporate or even link to the code from the camera application. Instead, you can simply start the activity in the camera application that captures a photo. When complete, the photo is even returned to your application so you can use it. To the user, it seems as if the camera is actually a part of your application.
When the system starts a component, it starts the process for that application (if it's not already running) and instantiates the classes needed for the component. For example, if your application starts the activity in the camera application that captures a photo, that activity runs in the process that belongs to the camera application, not in your application's process. Therefore, unlike applications on most other systems, Android applications don't have a single entry point (there's no main()function, for example).
Because the system runs each application in a separate process with file permissions that restrict access to other applications, your application cannot directly activate a component from another application. The Android system, however, can. So, to activate a component in another application, you must deliver a message to the system that specifies your intent to start a particular component. The system then activates the component for you.
Activating Components
Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called an intent. Intents bind individual components to each other at runtime (you can think of them as the messengers that request an action from other components), whether the component belongs to your application or another.
An intent is created with an Intent object, which defines a message to activate either a specific component or a specific type of component—an intent can be either explicit or implicit, respectively.
For activities and services, an intent defines the action to perform (for example, to "view" or "send" something) and may specify the URI of the data to act on (among other things that the component being started might need to know). For example, an intent might convey a request for an activity to show an image or to open a web page. In some cases, you can start an activity to receive a result, in which case, the activity also returns the result in an Intent (for example, you can issue an intent to let the user pick a personal contact and have it returned to you—the return intent includes a URI pointing to the chosen contact).
For broadcast receivers, the intent simply defines the announcement being broadcast (for example, a broadcast to indicate the device battery is low includes only a known action string that indicates "battery is low").
The other component type, content provider, is not activated by intents. Rather, it is activated when targeted by a request from a ContentResolver. T he content resolver handles all direct transactions with the content provider so that the component that's performing transactions with the provider doesn't need to and instead calls methods on
the ContentResolver object. This leaves a layer of abstraction between the content provider and the component requesting information (for security).
There are separate methods for activating each type of component:
You can start an activity (or give it something new to do) by passing
an Intent to startActivity() or startActivityForResult() (when you want the activity to return a result).
You can start a service (or give new instructions to an ongoing service) by passing
an Intent to startService(). Or you can bind to the service by passing an Intent to bindService().
You can initiate a broadcast by passing an Intent to methods
like sendBroadcast(), sendOrderedBroadcast(), or sendStickyBroadcast().
You can perform a query to a content provider by calling query() on a ContentResolver.
For more information about using intents, see the Intents and Intent Filters document. More information about activating specific components is also provided in the following documents: Activities, Services, BroadcastReceiver and Content Providers.
Declaring components
The primary task of the manifest is to inform the system about the application's components. For example, a manifest file can declare an activity as follows:
In the
In the
You must declare all application components this way:
1、
2、
3、
4、
Activities, services, and content providers that you include in your source but do not declare in the manifest are not visible to the system and, consequently, can never run. However, broadcast receivers can be either declared in the manifest or created dynamically in code (as BroadcastReceiver objects) and registered with the system by
calling registerReceiver().
Declaring component capabilities
As discussed above, in Activating Components, you can use an Intent to start activities, services, and broadcast receivers. You can do so by explicitly naming the target component (using the component class name) in the intent. However, the real power of intents lies in the concept of intent actions. With intent actions, you simply describe the type of action you want to perform (and optionally, the data upon which you’d like to perform the action) and allow the system to find a component on the device that can perform the action and start it. If there are multiple components that can perform the action described by the intent, then the user selects which one to use.
The way the system identifies the components that can respond to an intent is by comparing the intent received to the intent filters provided in the manifest file of other applications on the device.
When you declare a component in your application's manifest, you can optionally include intent filters that declare the capabilities of the component so it can respond to intents from other applications. You can declare an intent filter for your component by adding
an
For example, an email application with an activity for composing a new email might declare an intent filter in its manifest entry to respond to "send" intents (in order to send email). An activity in your application can then create an intent with the “send” action (ACTION_SEND), which t he system matches to the email application’s “send” activity and launches it when you invoke the intent with startActivity().
For more about creating intent filters, see the Intents and Intent Filters document.
Declaring application requirements
There are a variety of devices powered by Android and not all of them provide the same features and capabilities. In order to prevent your application from being installed on devices that lack features needed by your application, it's important that you clearly define a profile for the types of devices your application supports by declaring device and software requirements in your manifest file. Most of these declarations are informational only and the system does not read them, but external services such as Google Play do read them in order to provide filtering for users when they search for applications from their device.
For example, if your application requires a camera and uses APIs introduced in Android 2.1 (API Level7), you should declare these as requirements in your manifest file. That way, devices that do not have a camera and have an Android version lower than 2.1 cannot install your application from Google Play.
However, you can also declare that your application uses the camera, but does
not require it. In that case, your application must perform a check at runtime to determine if the device has a camera and disable any features that use the camera if one is not available.
Here are some of the important device characteristics that you should consider as you design and develop your application:
Screen size and density
In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical dimensions of the screen) and screen density (the physical density of the pixels on the screen, or dpi—dots per inch). To simplify all the different types of screen configurations, the Android system generalizes them into select groups that make them easier to target.
The screen sizes are: small, normal, large, and extra large.
The screen densities are: low density, medium density, high density, and extra high density.
By default, your application is compatible with all screen sizes and densities, because the Android system makes the appropriate adjustments to your UI layout and image resources. However, you should create specialized layouts for certain screen sizes and provide specialized images for certain densities, using alternative layout resources, and by declaring in your manifest exactly which screen sizes your application supports with
the
For more information, see the Supporting Multiple Screens document.
Input configurations
Many devices provide a different type of user input mechanism, such as a hardware keyboard, a trackball, or a five-way navigation pad. If your application requires a particular kind of input hardware, then you should declare it in your manifest with the
certain input configuration.
Device features
There are many hardware and software features that may or may not exist on a given Android-powered device, such as a camera, a light sensor, bluetooth, a certain version of OpenGL, or the fidelity of the touchscreen. You should never assume that a certain feature is available on all Android-powered devices (other than the availability of the standard Android library), so you should declare any features used by your application with the
Platform Version
Different Android-powered devices often run different versions of the Android platform, such as Android 1.6 or Android 2.3. Each successive version often includes additional APIs not available in the previous version. In order to indicate which set of APIs are available, each platform version specifies an API Level (for example, Android 1.0 is API Level 1 and Android 2.3 is API Level 9). If you use any APIs that were added to the platform after version 1.0, you should declare the minimum API Level in which those APIs were introduced using the
It's important that you declare all such requirements for your application, because, when you distribute your application on Google Play, the store uses these declarations to filter which applications are available on each device. As such, your application should be available only to devices that meet all your application requirements.
For more information about how Google Play filters applications based on these (and other) requirements, see the Filters on Google Play document.
Application Resources
An Android application is composed of more than just code—it requires resources that are separate from the source code, such as images, audio files, and anything relating to the visual presentation of the application. For example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using application resources makes it easy to update various characteristics of your application without modifying code and—by providing sets of alternative resources—enables you to optimize
your application for a variety of device configurations (such as different languages and screen sizes).
For every resource that you include in your Android project, the SDK build tools define a unique integer ID, which you can use to reference the resource from your application code or from other resources defined in XML. For example, if your application c ontains an image file named logo.png (saved in the res/drawable/ directory), the SDK tools generate a resource ID named R.drawable.logo, which you can use to reference the image and insert it in your user interface.
One of the most important aspects of providing resources separate from your source code is the ability for you to provide alternative resources for different device configurations. For example, by defining UI strings in XML, you can translate the strings into other languages and save those strings in separate files. Then, based on a language qualifier that you append to the resource directory's name (such as res/values-fr/ for French string values) and the user's language setting, the Android system applies the appropriate language strings to your UI.
Android supports many different qualifiers for your alternative resources. The qualifier is a short string that you include in the name of your resource directories in order to define the device configuration for which those resources should be used. As another example, you should often create different layouts for your activities, depending on the device's screen orientation and size. For example, when the device screen is in portrait orientation (tall), you might want a layout with buttons to be vertical, but when the screen is in landscape orientation (wide), the buttons should be aligned horizontally. To change the layout depending on the orientation, you can define two different layouts and apply the appropriate qualifier to each layout's directory name. Then, the system automatically applies the appropriate layout depending on the current device orientation.
For more about the different kinds of resources you can include in your application and how to create alternative resources for various device configurations, see theApplication Resources developer guide.
安卓应用基础
在Java编程语言编写的Android应用程序的Android的SDK工具编译代码以及与任何数据和到一个Android的包，一个归档文件档案资源的.apk后缀，所有的在一个单一的代码.apk文件被认为是一个应用程序，是Android的文件，供电设备来安装应用程序。
一旦安装在设备上，每个Android应用程序的生命在它自己的安全沙箱：
而Android操作系统是一个多用户Linux系统中，每个应用程序是一个不同的用户。
默认情况下，每个应用程序的系统分配一个唯一的Linux用户ID（该ID仅用于由系统是未知的应用程序），系统设置所有的应用程序中的文件权限，以便只有用户ID 分配给该应用程序可以访问它们。
每个进程都有它自己的虚拟机（VM），因此应用程序的代码在从其他应用程序隔离运行。
默认情况下，每个应用程序运行在它自己的Linux进程。Android的启动过程时，应用程序的任何组件需要被执行，然后关闭该进程时，它不再需要或恢复时，系统必须为其他应用程序的内存。
这样一来，Android系统实现了最小特权原则，也就是说，每个应用程序，默认情况下，只能访问的组件，它需要做的工作，没有更多，这将创建一个非常安全的环境，使应用程序无法访问的，这就是它没有给予许可制度的部分。
但是，有一个应用程序的方法与其他应用程序和应用程序访问系统服务的数据：这有可能为两个应用程序安排共享相同的Linux用户ID，在这种情况下，它们能够相互访问的文件。为了节约使用相同的用户ID系统资源，应用程序还可以安排运行在相同的Linux进程和共享同一个VM（应用也必须使用相同的证书签名）。
应用程序可以请求访问权限，如用户的联系人，短信，可安装存储（SD卡），摄像头，蓝牙等设备的数据，所有应用程序的权限必须由用户在安装时授予。
这涵盖了基本就如何Android应用程序在系统中存在这个文件的其余部分向您介绍：
1、框架的核心组件定义应用程序。
2、清单文件中声明组件和应用程序所需的设备功能。
3、资源是从应用程序代码分开，并允许您的应用程序正常优化的设备配置各种其行为。
Android的核心功能之一就是一个应用程序可以使用其它应用程序的元素（如果那个应用程序允许的话）。比如说，如果你的应用程序需要一个图片卷动列表，而另一个应用程序已经开发了一个合用的而又允许别人使用的话，你可以直接调用那个卷动列表来完成工作，而不用自己再开发一个。你的应用程序并没有吸纳或链接其它应用程序的代码，它只是在有需求的时候启动了其它应用程序的那个功能部分。
为达到这个目的，系统必须在一个应用程序的一部分被需要时启动这个应用程序，并将那个部分的Java对象实例化。与在其它系统上的应用程序不同，Android应用程序没有为应用准备一个单独的程序入口（比如说，没有main()方法），而是为系统依照需求实例化提供了基本的组件。共有四种组件类型：
活动(Activities)
一个 activity代表用户界面的一个独立屏幕。例如，一个邮件应用程序应该有一个activity 用于显示新邮件列表，另一个activity 用于撰写一封邮件，还有一个activity 用于读取邮件。尽管所有activitie 协同工作以构成邮件应用程序的用户体验，但彼此之间相对独立。应次，不同的应用程序能够从任何一个activity 启动(只要邮件应用程序允许)。例如，用户需要分享一张照片，一个拍照应用程序能够启动邮件应用程序的activity 。
activity 是一个实现了 Activity 的子类，你可以在 Activities 开发者指导部分了解更多。
服务(Services)
service是在后台运行，执行长时间操作或者执行远程操作。service 不提供用户界面。例如，当用户在另一个应用程序时，一个service 可在后台播放音乐，或者是从网络上获取数据，而不阻断用户与当前activity 的交互。其他组件，比如一个activity ，为了与该service 互动，可以启动或者绑定它。
service 是一个实现了 Service 的子类，你可以在 Services 开发者指导部分了解更多。广播接收器(Broadcast receivers)
广播接收器是一个专注于接收广播通知信息，并做出对应处理的组件。很多广播是源自于系统代码的──比如，通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以进行广播──比如说，通知其它应用程序一些数据下载完成并处于可用状态。
应用程序可以拥有任意数量的广播接收器以对所有它感兴趣的通知信息予以响应。所有的接收器均继承自BroadcastReceiver基类。
广播接收器没有用户界面。然而，它们可以启动一个activity来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音等等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。
内容提供者(Content providers)
内容提供者将一些特定的应用程序数据供给其它应用程序使用。数据可以存储于文件系统、SQLite数据库或其它方式。内容提供者继承于ContentProvider 基类，为其它应用程序取用和存储它管理的数据实现了一套标准方法。然而，应用程序并不直接调用这些方法，而是使用一个ContentResolver 对象，调用它的方法作为替代。ContentResolver 可以与任意内容提供者进行会话，与其合作来对所有相关交互通讯进行管理。
参阅独立的内容提供者Content Providers 章节获得更多关于使用内容提供者的内容。
每当出现一个需要被特定组件处理的请求时，Android会确保那个组件的应用程序进程处于运行状态，或在必要的时候启动它。并确保那个相应组件的实例的存在，必要时会创建那个实例。
Android系统设计的一个独特方面是任何的一个程序都可以启动另一程序的组件。比如，你想让你的程序可以使用照相机拍照，如果已经有了实现这种功能的程序并且你你的程序能使用它（有权限），那么你就没有再要再写一个新的Activity来实现这个功能。你的程序不需要包含或者链接这个拍照程序。相反，你只需要在你的程序中打开这个拍照程序中的实现拍照功能的Activity。当拍完之后，拍好的照片甚至会自动返回给
你的程序。者对于用户来说，就好像是想拍照功能的程序就是你的这个程序的一部分一样。
当系统启动一个组件之后，如果这个组件所在的程序之前没有运行的话，系统会自动开始这个程序的进程，并初始化这个组件所需要的相关类。比如，你的程序开启了一个拍照功能程序的Activity，这时系统会启动这个Activity所在的程序，所以这个Activity 运行在拍照功能的程序当中，而不是在你的程序中。所以，不像其他操作系统的中的程序一样，Android程序没有一个单独的入口点（比如没有我们常见的main()函数）。
因为系统中的程序运行在自己的独立进程中，并且程序中的文件都有自己的限制其他程序访问的权限，所以，你的程序不能直接激活其他程序中的组件。但是Android系统就可以。具体是这样的实现的，为了激活（activate）其他程序中的组件，你必须向系统发送一个消息来详细说明你要启动其他组件的意图，这样系统才会为你激活这个组件。
激活组件(Activating Components)
四大组件中的三个组件——activities、services和broadcast receiver——是由一种叫intent的异步消息来激活的。这些intents在运行时（runtime）将这些属于你的程序或不同程序的单独的组件绑定在一起（bind），你可以把这些intents看作是需要其他组件的action的messengers。
一个intent就是一个Intent对象，这个intent定义了一种可以激活（activate）某个特定组件或者某种特定类型的组件，这两种情况分别对应两种intent的定义方式或者显示的或者隐式的。
对于activities和services，一个intent定义了要执行的操作（action）(比如，要“view”或者“send”什么)和要操作的数据的URI。比如，一个intent可能会为一个activity传递一个请求来展示一张图片或者打开一个网页。有时，你可以启动一个activity来得到返回的结果，在这个例子中这个activity的返回的结果也是一个Intent（比如，你可以发送一个intent让用户选择一个personal contact并返回给你——这个返回的intent就包含了一个指向用户选择的联系人的URI）。（关于activity和service的启动方式，下面将介绍。）
对于广播接收者来说，intent只是简单的定义了要广播的内容（比如，一个用以表明电池电量很低的广播仅包含了一个表明电池电量很低的字符串）。
最后一种组件类型content provider并不是由intent来激活的（activate）。而是由接收到ContentResolver的请求时激活的。
它们都各自有自己的方法来激活相应的组件：
你可以通过传递一个Intent给startActivity()或startActivityForResult()启动一个activity（或者给他一些新的要做的内容）。使用startActivityForResult()你将得到一个返回结果。
你可以通过传递一个Intent给startService()来start一个service（或者给一个正在运行的service一些新的指令(instructions)）。或者你可以通过把一个Intent传递给bindService()来绑定一个service。
你可以通过传递一个Intent给诸如sendBroadcast()、sendOrderedBroadcast()或者sendStickyBroadcast()等方法来初始化一个广播。
你可以通过调用ContentResolver的query()方法来执行一次content provider的查询操作。
更多的关于intent的内容，可以参看文档中的Intents and Intent Filters。更多的关于激活特定组件的内容可以参看文档中的：Activities、Services、BroadcastReceiver、Content Providers。
关于Manifest文件
在Android系统可以启动一个应用程序组件之前，Android系统必须通过读取这个程序的AndroidManifest.xml（即manifest文件）文件来确定要启动的组件存在。你的程序必须在这个manifest文件声明用到的所有的组件，并且这个manifest文件必须在项目的根目录下。
另外，这个manifest文件还声明一些其他的东西，比如：
确定这个程序需要的所有权限，比如Internet访问权限或者读取用户联系人权限。
声明这个运行这个程序所需要的最低API版本，这个可以根据开发该程序所使用的API版本。
声明该程序所需要的硬件或软件特征（features），比如照相机、蓝牙服务或者多点触屏。
声明该程序需要链接（link against）的API库（不是Andorid的framework APIs），比如Google Maps library。
组件声明
Manifest文件的首要任务就是通知系统关于程序中要使用的组件。比如，一个manifest文件可以用如下的方式来声明一个activity：
[java] view plaincopy
1.
2.
3.
4. 5. android:label="@string/example_label" ... > 6.
7. ...
8.
9.
在
在
你必须要用以下方式来声明你的程序组件：
1、activities：
2、services:
3、broadcast receiver：
4、content providers：
如果程序中用到activities、services和content providers，你没有在manifest文件中声明，那么这些组件将不会被系统知道，结果就是你的程序不能运行。然而，broadcast receiver既可以在manifest文件中声明也可以在代码中动态创建（BroadcastReceiver），并通过调用registerReceiver()在系统中注册。
更多关于怎样为你的程序构建manifest文件，请参看文档The AndroidManifes.xml
文件。
声明组件的能力
正如在上面Activating Components中讨论的那样，你可以使用一个Intent来启动activities、services和broadcast receiver。你可以通过在intent中注明目标组件的名字（使用的是组件的类名）来显示的启动组件。然而，intents真正强大的地方在与关于intent 的actions的概念。通过intent的actions，你可以简单的描述你要执行的操作的类型（并且可以有选择的描述你要处理的数据），可以允许系统在device中找到这个组件并启动它。如果有多个组件可以执行intent中描述的action，这时用户就可以选择一个来执行。
系统可以识别能对某intent做出反应的方式是通过将接收到的intent和设备中其他程序的manifest文件的intent filters进行比较实现的。
当你在程序的manifest文件中声明一个组件之后，你可以有选择包含intent filters，这些intent filters表明了组件对接收自其他程序的intent做出反应的能力（capabilities）。你可以通过添加一个
比如，在一个邮件程序中的一个activity可以编写新的邮件，这样的话你就需要在manifest文件中来声明一个intent filter来对“发送”intent响应（为了发送邮件）。这样，在你的程序中，一个activity就可以创建一个发送intent(ACTION_SEND)，这样当你调用startaActivity()时，系统就会匹配邮件程序中的发送activity并启动它。
更多关于创建intent filters的内容，可以参看Intents and Intent Filter文档。
声明运行程序所需的条件
Andorid系统可以支持很多不同的设备，并且这些设备的性能特征并不相同。为了防止你的程序被安装在不能正常运行你的程序的较低android系统版本上，通过在manifest文件中声明你的程序支持的设备和软件，便变得尤其重要起来。大多数的这些声明仅是一些信息，而系统并不会读取它们，但是其他的服务比如Android Market却会阅读这些声明来帮助通过通过自己的设备搜索软件的用户过滤软件。
比如，你的程序需要照相机，并且使用的Android2.1的APIs，那么你就必须在你的manifest文件中声明这些需要。这样的话，在Android Market上，没有照相机或者Android 系统版本低于2.1将不能安装你的程序。
然而，如果你的程序不需要照相机，你仍可以声明你需要照相机。这种情况下，你的程序必须在运行时做一下检查，来检查这个设备是否含有照相机，如果没有照相机可用，则系统将会使使用照相机的相关程序不能用。
下面是一些你在设计和开发你的程序时，必须要考虑的关于设备的一些重要方面：
屏幕大小和分辨率：
为了根据屏幕的类型进行分类，Android定义了两个特征：屏幕大小和分辨率。
屏幕尺寸有：小，中，大，超大；
屏幕分辨率类型：低分辨率，中分辨率，高分辨率，超高分辨率；
默认情况下，你的程序可以兼容所有的屏幕尺寸和分辨率，因为Android系统对你的程序的UI布局和image资源做了适当的调整。
输入方式：
很多设备有不同类型的输入方式，比如键盘、轨迹球、五位元导航。如果你的程序需要某特定形式的输入方式，则你必须在manifes文件中使用
设备配置：
有许多硬件或软件并不全在Android系统的设备上，比如，一个照相机、光线传感器、某个版本的OpenGL，或者屏幕的保真度（fidelity）。你在任何条件下都不能假定Android设备具备某种特性（feature）（当然得除掉Android标准库的情况），所以如果你的程序使用了某feature，则你必须使用
不同地 Android 平台设备通常运行不同版本的Android ，比如Android 1.6 或者Android 2.3。每个后续版本通常包含之前版本所不支持的新增API。In order to indicate which set of APIs are available, 每个平台版本对应一个 API Level (例如，Android 1.0 对应于API Level 1 ，Android 2.3 对应于API Level 9)。如果你使用任何在 1.0 版之后平台新增的API，你应该使用
为你的应用程序声明所有这些要求至关重要，因为，当你在 Android Market 上发布你的应用程序时，Market 使用这些声明来过滤该应用程序是否对于每台设备可用。这样，你的应用程序仅对能够满足你的应用程序要求的设备可用。
应用程序资源
一个应用程序不仅仅由代码组成——它需要区别于源代码的资源，比如图片，音频文件，以及任何与应用程序视觉呈现相关联的内容。例如，你应该使用 XML 文件定义动画，菜单，风格，颜色，以及activity 用户界面的布局。使用应用程序资源文件，可以更容易地更新你的应用程序的特性而无需修改代码，并且—通过提供多套可替换资源文件—使您能够针对各种设备配置优化你的应用程序(比如不同语言或屏幕大小)。
对于你的安卓工程里面包含的每一项资源， SDK 构建工具定义一个唯一的正整数ID 标识符，你可以使用该标识符从你的应用程序代码中或者从XML文件中定义的其他资源中特指该资源。例如，如果你的应用程序中包含一个名为 logo.png 图片文件(保存在 res/drawable/ 文件夹里)，SDK 工具会生成一个资源ID 命名为 R.drawable.logo，你可以使用该ID 特指这张图片并插入你的用户界面中。
将资源提供工作同你的源代码分隔开来最重要的原因之一是能够使您为不同的设备配置提供可替换的资源文件。例如，在XML 中定义 UI 字符串，你可以将这些字符串翻译成其他语言并保存在特定的文件夹中。然后，基于语言qualifier / 修饰词你添加
资源文件夹名称(比如 res/values-fr/ 对应于法语字符串) 以及用户语言设置，Android 系统会给你的UI 提供适当的语言字符串。
对于你的可替代资源，Android 支持许多不同的qualifiers / 修饰符。修饰符是包含在你的资源文件夹名称中的一个短字符串，以便界定哪些设备配置可使用这些资源。另一个例子，对于不同的设备屏幕和大小，你应当为你的activities 创建不同的布局。例如，当设备屏幕是纵向的(高)，你可能希望一个按钮垂直排列的布局，但当屏幕是横向的(宽)，按钮应当水平排列。为了根据方向调整布局，你可以定义两个不同的布局文件并给每个布局文件夹提供适当的修饰符。这样，系统会根据特定的设备方向自动为其提供适当的布局。
参考文献
[1] 作者Android.developer. 题目Application Fundamentals.
2013年4月14日
外文翻译-基于Android智能家居系统
通信工程学院 毕业设计外文翻译 毕业设计题目基于ANDRIO的智能家居 系统的设计与实现 外文题目UBIQUITOUS SMART HOME SYSTEM USING ANDROID APPLICATION 专业：通信工程 学号： 学生姓名： 指导教师姓名： 指导教师职称：副教授 日期：2015 年 1 月10 日
International Journal of Computer Networks & Communications (IJCNC) V ol.6, No.1, January 2014 基于Android应用的无处不在的智能家居系统 Shiu Kumar Department of Information Electronics Engineering, Mokpo National University, 534-729, Mokpo, South Korea 摘要 本文提出了一种灵活独立的，低成本的智能家居系统，它是基于Android应用与微web服务器通信，不仅仅提供交换功能。Arduino以太网的使用是为了避免使用个人电脑从而保证整个系统成本最低，语音激活时用来实现切换功能的。光开关，电源插头，温度传感器，湿度传感器，电流传感器，入侵检测传感器，烟雾/气体传感器和警报器等这些设备集成在系统中，表明了所提出的智能家居系统的有效性和可行性。经过检测，智能家居应用程序可以成功地进行智能家居操作，例如开关功能，自动环境监测，和入侵监测，在监测到有不法入侵后，系统会自动发送一个邮件，并响警笛。 关键字： Android智能手机，智能家居，物联网（loTs），远程控制 1.引言 随着移动设备受欢迎程度的不断增长和人们日常生活中对无处不在的先进的移动应用的功能需求不断增加，利用Web服务是提供远程访问服务的最开放和可互操作的方式，并且使应用程序能够彼此通信。一个有吸引力的市场产品自动化和网络化是忙碌的家庭和有生理缺陷的个人的代表。 loTs可以被描述为连接智能手机，网络电视，传感器等到互联网，实现人们之间沟通的新形势。过去几年中loTs的发展，创造了一个新层面的世界。这使得人们可以在任何时间，任何地点，联通任何期望的东西。物联网技术可用于为智能家居创建新的概念和广阔的空间，以提供智能，舒适的发展空间和完善生活质量。 智能家居是一个非常有前途的领域，其中有各种好处，如增加提供舒适性，更高安全性，更合理地使用能源和其他资源。这项研究的应用领域非常重要，未来它为帮助和支持有特殊需求老的人和残疾人士提供了强有力的手段。设计一个智能家居系统时需要考虑许多因素，该系统应该是经济实惠的，是可伸缩的，使得新的设备可以容易地集成到系统中，此外，它应该是用户友好的。 随着智能手机用户的急剧增加，智能手机已经逐渐变成了具备所有功能的便携式设备，为人们提供了日常使用。本文介绍了一种低成本的控制和监视家居环境控制的无线智能家居系统。利用Android设备，可以通过一个嵌入式微Web服务器与实际的IP连接，访问和控制电器和远程的其它设备，这可以利用任何支持Android的设备。Arduino Ethernet 用于微Web服务器从
Android系统架构详解
Android系统架构详解 Android系统架构由5部分组成， 分别是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。 1、Linux Kernel Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack. Android基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生了变化不会影响到上层。也就是说各层各尽其职，各层提供固定的SAP（Service Access Point），专业点可以说是高内聚、低耦合。如果你只是做应用开发，就不需要深入了解Linux Kernel层。 2、Android Runtime Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language. Android包括一个核心库的集合，她们提供了Java编程语言的核心库中的绝大多数功能。 Every Android application runs in its own process, with its own instance of the Dalvik virtual
(精品文献)Android外文翻译
本科毕业设计（论文）外文参考文献译文及原文 学院信息工程学院 专业测控技术与仪器 （光机电一体化方向) 年级班别 2011级（1）班 学号 学生姓名 指导教师
目录 1应用程序基础 (1) 1.1应用程序组件 (1) 1.2激活组件：intent (3) 1.3 关闭组件 (4) 1.4manifest文件 (5) 1.5Intent过滤器 (6) 1.6基于XML的布局 (7) 1Application Fundamentals (8) 1.1 Application Components (8) 1.2Activating components:intent (11) 1.3 Shutting down components (12) 1.4 The manifest file (13) 1.5Intent filters (14) 1.6XML-Based Layout (15)
1 应用程序基础 Android应用程序使用Java编程语言开发。aapt工具把编译后的Java代码连同应用程序所需的其他数据和资源文件一起打包到一个Android包文件中，这个文件使用.apk作为扩展名。此文件是分发并安装应用程序到移动设备的载体；是用户下载到他们的设备的文件。单一.apk文件中的所有代码被认为是一个应用程序。 从多个角度来看，每个Android应用程序都存在于它自己的世界之中： 1 默认情况下，每个应用程序均运行于它自己的Linux进程中。当应用程序中的任何代码需要被执行时，Android启动此进程，而当不再需要此进程并且其它应用程序又请求系统资源时，则就关闭了这个进程。 2 每个进程都有其独有的虚拟机（VM），所以应用程序代码与所有其它应用程序代码是隔离运行的。 3 默认情况下，每个应用程序均被赋予一个唯一的Linux用户ID，并加以权限设置，使得应用程序的文件仅对此用户及此应用程序可见——尽管也有其它的方法使得这些文件同样能为其他应用程序所访问。 1.1 应用程序组件 Android的一个核心的特性就是一个应用程序可以使用其它应用程序的元素（如果那个应用程序允许的话）。例如，如果你的应用程序需要显示一个图片卷动列表，而另一个应用程序已经开发了一个合用的而又允许别的应用程序使用的话，你可以直接调用那个卷动列表来完成工作，而不用自己再开发一个。你的应用程序并没有吸纳或链接其它应用程序的代码。它只是在有需求的时候启动了其它应用程序的那个功能部分。 为达到这个目的，系统必须能够在一个应用程序的任何一部分被需要时启动一个此应用程序的进程，并将那个部分的Java对象实例化。因此，不像其它大多数系统上的应用程序，Android应用程序并没有为应用程序提供一个单独的入口点（比如说，没有main()函数），而是为系统提供了可以实例化和运行所需的必备组件。一共有四种组件类型： (1)Activity
Android手机外文翻译---应用程序基础Android Developers
英文原文及译文 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 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
安卓系统简介及如何分区的
android操作系统的分区 对电脑系统了解的朋友都知道，简单来说，电脑分硬件和软件两大块，软件装在硬盘上，比如操作系统windows，使用者通过windows来控制机器硬件，达到使用电脑的目的。 手机也分为硬件和软件两块，软件则是装在闪存（即flash memory，一种存储器）上的，闪存有大小的区别，就像硬盘有大小一样，看手机硬件配置的时候，通常会看到如下介绍：ROM 512M，RAM 512M，ROM就是指的闪存了，相当于电脑上的硬盘，用来存放操作系统和用户数据等信息。相应的，RAM就是指的内存了。 手机出厂时都是装好系统的，这点类似于电脑世界里面的品牌电脑，通过分析手机闪存上的内容可以知道，android操作系统主要有以下几个重要的分区（包括但不限于）： hboot分区----------负责启动。 radio分区----------负责驱动。 recovery分区-------负责恢复。 boot分区-----------系统内核。 system分区---------系统文件。 cache分区----------系统缓存。 userdata分区-------用户数据。 1、hboot（SPL）：这里指的是手机上的启动模块，通俗的说，就是负责手机启动引导的一段程序，类似于电脑主板上的BIOS，都是负责底层操作的。和在电脑上刷新BIOS一样，刷错了，电脑就会开不了机，对手机来说也一样，这部分的内容刷错了，手机就会变砖！
2、radio：这里指的是手机上的通讯模块，又叫做基带。负责手机的无线信号，蓝牙，WIFI等设备的管理，也就是说，相当于电脑系统里面的硬件驱动部分。这样说或许也不是特别的准确，大家明白大概的意思就可以了。通常我们所说的刷radio，刷基带，就是指的刷写这一部分，以便解决通话质量、网络连接质量、蓝牙连接等等问题。 3、recovery：字面意思是恢复，手机上的一个功能分区，有点类似于笔记本电脑上的恢复分区。一般大厂出的笔记本，都会自带一个特殊分区，里面保存着系统的镜像文件，当系统出问题的时候，我们可以通过它来一键恢复系统。这里的recovery功能有些类似。其实，他更像是电脑上的小型winPE系统，可以允许我们通过启动到winPE系统上，去做一些备份、恢复的工作。当然，系统自带的recovery基本没用，所以我们通常会刷入一个第三方的recovery，以便实现更多的功能，例如：备份系统，恢复系统，刷新系统等。但官方自带的recovery 也不是一无是处，在使用OTA方式升级系统时候，会检查此分区内容，如果不是原厂自带的，OTA升级就会失败。 4、fastboot：字面意思是快速启动，在这里，其实是一个特殊的工程模式，通过fastboot界面，连接电脑后，我们可以在电脑端通过特殊的指令来操作手机，例如更新radio，就可以通过fastboot来完成。fastboot的级别又要比recovery 来的要高一些，可以完成更底层的一些操作。后面我们会结合实际，来讲解一些fastboot的用法，更详细的资料，大家可以通过网络来学习，这里不再赘述。 5、ADB：android debug bridge，字面意思就是安卓调试桥接，简单点说，它是android系统提供的一套工具，通过它，我们可以在电脑上建立一个连接到手机的通道，然后可以在电脑上向手机发送一些指令，完成一些我们需要做的工作。ADB的用法我们后面也会作相应的介绍。 6、ROM：read only memory,只读存储器。上面我们讲过的，android系统都是安装在闪存里面的，这个闪存，就是一种只读存储器，断电情况下里面的内容不会消失。刷机，就是刷的ROM。有点类似电脑里的硬盘，ROM里面有很多分区，hboot、boot、system等等，前文介绍过的，还记得吗？说到这里，想到一个好笑的事情，某人问老婆，知道什么是ROM吗？答曰：room？不就是房子吗？晕倒，我说的是R O M ，不是R O O M！！奥，那就是小房子了！狂晕！！
基于安卓的大学生记账管理系统的设计与实现-外文翻译译文和原文
基于安卓的大学生记账管理系统的设计与实现-外文翻译译 文和原文 毕业设计外文文献翻译 院系: 计算机与信息工程学院年级专业: 12软件工程(金融服务)2 姓名: 学号: An Analysis of Personal Financial Lit Among 附件: College Students Among College Students 指导老师评语: 指导教师签名: 年月日 大学生个人理财知识分析 大学生个人理财知识分析 这项研究调查了924名大学生审视自己的个人财务知识;调查了学生的财务知识与学生的特性之间的关系，和理财知识对学生的意见和决定的影响。结果表明，参与者回答问题的正确性为53,。所调查的人包括非经营性专业、妇女、在下层阶级行列的学生、30岁以下并且很少有工作经验的人、知识水平较低者。懂得较少财务知识的学生往往有错误的观点和作出不正确的决定。结论是:大学生不太了解个人理财。低的财务知识水平会限制他们做出明智决策的能力。 I. 介绍 管理个人财务的能力在当今世界已经变得越来越重要。人们必须计划为他们的退休和子女的教育长期投资。他们还必须决定短期储蓄和借贷一个假期，向下支付
房子，汽车贷款和其他大件物品。此外，他们还必须管理自己的医疗保险和人寿保险的需求。 不幸的是，研究表明，美国人有个人认识不足财政(EBRI，1995年，毕马威会计师事务所，1995年; PSRA，1996年，1997年，奥本海默基金/女孩公司，1997年;先锋集团/货币杂志，1997年)。他们未能作出正确决策因为他们还没有收到良好的个人理财教育(HSR，1993年，希拉，1993;奥尼尔，1993年)。 这项研究有三个目的。首先，它提供大学生个人理财素养的证据。其次，它会检查为什么一些大学生相对比别人有更多的理财知识。该分析可以帮助我们识别出大学生所拥有决定能力水平的因素。第三个目的是检查学生的知识如何影响他/她的意见和个人财务问题上的决定。 本文的结构安排如下。第二部分回顾了以前对金融知识的研究。第三部分是讨论方法。第四部分是提出的结果。第五部分总结全文。 II. 文献回顾 大部分以前的研究都是由在金融服务行业的从业人员进行。他们专注于资金管理和投资有关的问题。这个重点与会计师财务策划师的调查结果一致，说明这些问题是个人理财规划的重要领域(NEFE，1993-1996)。这些研究结果表明，参与的调查者回答调查问题的正确率普遍只有不到60,。 此前高中生的研究均发现，他们在个人财务的基本知识上未受到良好的教育，并且知识贫乏(巴肯，1967; CFAJAMEX，1991; HSR，1993; Langrehr，1979; NAEP，1979)。在对来自63所学校的1509高中学生的调查研究中，曼德尔(1997)报告了一个平均正确的比分，57,在收入、资金管理、储蓄、投资和消费等领域。他的结论是:学生们离开学校时没有做出关键决策影响他们生活的能力。 难道成年人对个人理财和投资有一个很好的控制,几个结果研究表明，他们并 1
Android系统架构简介
Android系统架构简介 Android系统架构简介 目前Android的Linuxkernel控制包括安全、存储器管理、进程管理、网络堆叠、驱动程序模型等。下载Android源码之前，先要 安装其构建工具Repo来初始化源码。Repo是Android用来辅助Git 工作的一个工具。 应用程序 Android系统是基于Linux内核开发，使用Java作编程语言， 使界面到功能，都有层出不穷的变化，其中Activity等同于J2ME 的MIDlet，一个Activity类别负责创建视窗，一个活动中的 Activity就是在foreground(前景)模式，背景执行的程序叫做Service。两者之间透过由ServiceConnection和AIDL连结，达到 复数程序同时执行的效果。如果执行中的Activity全部画面被其他Activity取代时，该Activity便被停止，甚至被系统清除。 View等同于J2ME的Displayable，程序人员可以透过View类别与“XMLlayout”档将UI放置在视窗上，并可以利用View打造出所 谓的Widgets，其实Widget只是View的一种，所以可以使用xml 来设计layout。至于ViewGroup是各种layout的基础抽象类别，ViewGroup之内还可以有ViewGroup。View的构造函数不需要在Activity中调用，但是Displayable的是必须的，在Activity中，要通过findViewById()来从XML中获取View，Android的View类 的显示很大程度上是从XML中读取的。View与事件息息相关，两者 之间透过Listener结合在一起，每一个View都可以注册eventlistener，例如：当View要处理用户触碰的事件时，就要向Android框架注册View.OnClickListener。另外还有Image等同于 J2ME的BitMap。 中介软件
Android系统外文翻译
附录1：外文原文 What Is Android? It can be said that, for a while, traditional desktop application developers have beenspoiled. This is not to say that traditional desktop application development is easier thanother forms of development. However, as traditional desktop application developers, wehave had the ability to create almost any kind of application we can imagine. I amincluding myself in this grouping because I got my start in desktop programming. One aspect that has made desktop programming more accessible is that we havehad the ability to interact with the desktop operating system, and thus interact with anyunderlying hardware, pretty freely (or at least with minimal exceptions). This kind offreedom to program independently, however, has never really been available to thesmall group of programmers who dared to venture into the murky waters of cell phonedevelopment. For a long time, cell phone developers comprised a small sect of a slightly larger group of developers known as embedded device developers. Seen as a less “glamorous” sibling to desktop—and later web—development, embedded device development typically got the proverbial short end of the stick as far as hardware and operating system features, because embedded device manufacturers were notoriously stingy on feature support. Embedded device manufacturers typically needed to guard their hardware secrets closely, so they gave embedded device developers few libraries to call when trying to interact with a specific device. Embedded devices differ from desktops in that an embedded device is typically a “computer on a chip.” For example, consider your standard television remote control; it is not really seen as an overwhelming achievement of technological complexity. When any button is pressed, a chip interprets the signal in a way that has been programmed into the device. This allows the device to know what to expect from the input device (key pad), and how to respond to those commands (for example, turn on the television). This is a simple form of embedded device programming. However, believe it or not, simple devices such as these are definitely related to the roots of early cell phone devices and development. Most embedded devices ran (and in some cases still run) proprietary operating systems. The reason for choosing to create a proprietary operating system rather than use any consumer system was really a product of necessity. Simple devices did not need very robust and optimized operating systems. As a product of device evolution, many of the more complex embedded devices, such as early PDAs, household security systems, and GPSs, moved to somewhat standardized operating system platforms about five years ago. Small-footprint
Android系统原理及开发要点详解.
内容简介 本书全面介绍开放的移动电话平台Android系统,包括Android系统中的Linux 驱动、本地框架、Java框架和Java应用4个层次。本书内容以知识性内容为纲,重点关注开发要点,各个部分内容注重相互照应,按照清晰的思路向读者介绍整个Android系统的原理和开发方法。 本书按照Android系统的框架和各个子系统的主线,重点介绍开发Android应用程序和构建硬件抽象层。其内容涵盖了Android应用程序开发和Android系统移植构建手机系统两大方面。 本书既适合从事Android各个层次开发的工程师阅读,也适合通用嵌入式Linux 系统的学习者使用。 本书购买地址:当当网卓越网中国互动出版网 作者简介 梁泉是移动系统开发资深工程师,在Android领域具有完备的知识和前沿的技术,长期从事一线开发工作。 韩超是中国大陆地区较早参与Android系统开发的人员之一,也是中国大陆的Androidin(机锋网开发社区的核心成员和重要组织者之一;也曾经引领大陆各种相关技术人员进入Android领域,并组织参与国内外的相关枝术交流。 前言 Android 是Google历经数年和投资数亿美元开发出来的智能手机系统,Google 也发起了围绕Android的组织——开放手机联盟,其英文全称为“Open Handset Alliance”。
随着各大移动终端生产商大力开发和生产基于Android的移动智能设 备,Android迅速得到业界和社会的认可,并成为整个产业的热点,基于Android平台的各类人才逐渐成为各大企业竞相争夺的焦点。 Android系统是一个开放的系统,任何公司、个人开发者、爱好者都可以参与其中。对于技术工作者,Android不仅是一个智能手机的系统,也可以作为学习嵌入式Linux系统的较完整的软件平台。 Android是一个较新的系统和技术,因此介绍Android的资料和书籍还比较少,尤其简体中文的书籍,相对更少。本书《Android系统原理及开发要点详解》是一本综合介绍Android系统的书,集合了Androidin社区多位专家作者的经验,精心编写而成。 Android 作为一个庞大的系统,包括了Linux操作系统、各种本地程序、虚拟机和运行环境、Java框架和Java应用程序多方面的内容。这对于初学者是一个非常大的挑战,因此对于学习、研究进而开发Android系统来说,掌握系统的脉络和使用恰当的学习方法是非常重要的,这也是本书的组织主旨。 本书特点为了适应Android系统的情况,本书在内容的编排和组织上具有以下一些重要特点。 保持完整性和层次性本书紧紧把握Android系统的4个层次,分章节介绍,并且有重点地介绍了Android整个系统的代码结构、编译系统、相关工具、各部分组织等全局性内容。这将让读者即使只花费较短的时间,也可以获得对Android 系统大致的感性理解。 提供清晰的框架Android是一个有数百兆大小的较大系统,各部分之间是有机联系的,这就要求Android的学习和开发者需要具有一些软件架构方面的知识。本书为Android整体和重点模块绘制了大量的框图,这样非常有利于帮助读者直观地理解系统。本书在讲述每一个部分时,均列出相关代码的路径,帮助读者对应着进行快速、高效地学习。
Android应用架构外文翻译
Android Application Architecture author：Lars V ogel 1、AndroidManifest.xml The components and settings of an Android application are described in the file AndroidManifest.xml. For example all Activities and Services of the application must be declared in this file. It must also contain the required permissions for the application. For example if the application requires network access it must be specified here.
linux内核启动 Android系统启动过程详解
linux内核启动+Android系统启动过程详解 第一部分：汇编部分 Linux启动之 linux-rk3288-tchip/kernel/arch/arm/boot/compressed/ head.S分析这段代码是linux boot后执行的第一个程序，完成的主要工作是解压内核，然后跳转到相关执行地址。这部分代码在做驱动开发时不需要改动，但分析其执行流程对是理解android的第一步 开头有一段宏定义这是gnu arm汇编的宏定义。关于GUN 的汇编和其他编译器，在指令语法上有很大差别，具体可查询相关GUN汇编语法了解 另外此段代码必须不能包括重定位部分。因为这时一开始必须要立即运行的。所谓重定位，比如当编译时某个文件用到外部符号是用动态链接库的方式，那么该文件生成的目标文件将包含重定位信息，在加载时需要重定位该符号，否则执行时将因找不到地址而出错 #ifdef DEBUG//开始是调试用，主要是一些打印输出函数，不用关心 #if defined(CONFIG_DEBUG_ICEDCC)
……具体代码略 #endif 宏定义结束之后定义了一个段， .section ".start", #alloc, #execinstr 这个段的段名是 .start，#alloc表示Section contains allocated data, #execinstr表示Section contains executable instructions. 生成最终映像时，这段代码会放在最开头 .align start: .type start,#function /*.type指定start这个符号是函数类型*/ .rept 8 mov r0, r0 //将此命令重复8次，相当于nop，这里是为中断向量保存空间 .endr b 1f .word 0x016f2818 @ Magic numbers to help the loader
安卓应用开发基础论文中英文对照资料外文翻译文献
安卓应用开发基础论文中英文对照 资料外文翻译文献 中英文对照资料外文翻译文献安卓应用开发基础在Java编程语言编写的Android应用程序的Android的SDK工具编译代码以及与任何数据和到一个Android的包，一个归档文件档案资源的.apk后缀，所有的在一个单一的代码.apk文件被认为是一个应用程序，是Android的文件，供电设备来安装应用程序。一旦安装在设备上，每个Android应用程序的生命在它自己的安全沙箱：而Android操作系统是一个多用户Linux系统中，每个应用程序是一个不同的用户。默认情况下，每个应用程序的系统分配一个唯一的Linux用户ID，系统设置所有的应用程序中的文件权限，以便只有用户ID分配给该应用程序可以访问它们。每个进程都有它自己的虚拟
机，因此应用程序的代码在从其他应用程序隔离运行。默认情况下，每个应用程序运行在它自己的Linux进程。Android的启动过程时，应用程序的任何组件需要被执行，然后关闭该进程时，它不再需要或恢复时，系统必须为其他应用程序的内存。这样一来，Android系统实现了最小特权原则，也就是说，每个应用程序，默认情况下，只能访问的组件，它需要做的工作，没有更多，这将创建一个非常安全的环境，使应用程序无法访问的，这就是它没有给予许可制度的部分。但是，有一个应用程序的方法与其他应用程序和应用程序访问系统服务的数据：这有可能为两个应用程序安排共享相同的Linux用户ID，在这种情况下，它们能够相互访问的文件。为了节约使用相同的用户ID系统资源，应用程序还1 可以安排运行在相同的Linux进程和共享同一个VM。应用程序可以请求访问权限，如用户的联
android系统详细介绍
androｉd Aｎdroid一词的本义指“机器人”,同时也是Googlｅ于２007年11月５日宣布的基于Lｉnu ｘ平台的开源手机操作系统的名称，该平台由操作系统、中间件、用户界面和应用软件组成,号称是首个为移动终端打造的真正开放和完整的移动软件。目前最好的是Andrｏｉd2.０的摩托罗拉Drｏiｄ 目录[显示］ [编辑本段］ 简介 Androiｄ是基于Ｌｉnux内核的软件平台和操作系统，早期由Ｇooglｅ开发，后由开放手机联盟(Open Handset Alliance）开发。它采用了软件堆层(softｗａre ｓt acｋ,又名为软件叠层）的架构，主要分为三部分。底层以Linux内核工作为基础，只提供基本功能;其他的应用软件则由各公司自行开发，以Jａva作为编写程序的一部分。另外，为了推广此技术,Ｇoogｌｅ和其它几十个手机公司建立了开放手机联盟。Ａnｄｒoid在未公开之前常被传闻为Googlｅ电话或gPhone。大多传闻认为Goｏg le开发的是自己的手机电话产品，而不是一套软件平台。到了2０10年1月,Ｇooｇl e开始发表自家品牌手机电话的NexuｓOne。目前最新版本为Anｄｒoid2.１。 对手机行业的影响 已经与HＴC、NTT ＤｏCoＭo、KＤＤI、Motorola等世界移动领域34家公司于免费提供达成一致。今后对于移动通讯的影响势必会进一步体现出来。但是如此广泛公司的同盟是否能够有效运作以及持久,让我们拭目以待。 Ａnｄroiｄ手机 ２0０8年9月22日,美国运营商Ｔ-MobiｌeUSA在纽约正式发布第一款Ｇoｏg ｌe手机——T-Mobiｌe Ｇ1。该款手机为台湾宏达电代工制造,是世界上第一部使用Android操作系统的手机,支持WCDMA/ＨSPＡ网络，理论下载速率７.2Mbps,并支持Wi-Fｉ。 (左图为Aｎdｒｏiｄlogｏ) [编辑本段］
Android系统外文翻译3
Android起航 译 使用XML进行布局 虽然纯粹通过Java代码在activity上创建和添加部件，在技术上是可行的，我们在第4章中做的一样，更常见的方法是使用一种基于XML的布局文件。动态的小部件实例保留更多，情况复杂，小工具在编译时不为人所知（例如，在数据检索了互联网基础上将单选按钮填充柱。 考虑到这一点，现在是时候打破XML来学习如何用此种方式来布置Android activities。 什么是基于XML的布局？ 正如其名称所示，一个基于XML的布局是一个关系到每个规格的小部件，和他们的容器（更多关于此内容的在第7章）编码的XML格式。具体来说，Android 认为基于XML的布局是资源，因此布局文件存储在res /在你的Android项目布局目录中。 每个XML文件包含一个指定的部件和容器布局元素树，一种意见认为构成层次。对XML元素的属性，描述一个部件应如何看或者一个容器应如何运转。例如，如果一个按钮元素。 有一个Android的属性值：文字样式=“bold”，这意味着该文本出现在按钮的表面应该是呈现一个粗体字体样式. Android的SDK中附带一个使用的布局的工具（aapt）。这个工具应自动调用你的Android工具链（例如，Eclipse中，Ant’s build.xml）。作为一个开发人员，尤其重要的是，在您的项目中aapt生成R.java源文件，让您能在那些布局中直接从Java代码中获取布局和部件。 为什么使用基于XML的布局？ 使用XML布局文件做的大部分都可以通过Java代码。例如，你可以使用setTypeface（）命令一个按钮使用粗体文本，而不是在一个XML布局中使用属性。由于XML布局是为你跟踪的另一个文件，所以我们需要好的理由来使用这样的文
相关文档
- 外文翻译---应用程序基础Android Developers
- Android毕设外文资料和译文
- Android手机外文翻译---应用程序基础Android Developers
- 基于Android的智能公交出行系统软件设计外文翻译.doc
- 外文翻译--Android--应用基础
- 毕业设计--基于Android的电子词典软件的设计与实现 (含外文翻译)
- 毕设Android平台 英文翻译
- Android应用架构外文翻译
- 外文翻译---安卓系统的基本描述
- Android外文文献翻译
- 安卓开发外文翻译--安卓应用基础
- (精品文献)Android外文翻译
- Android应用程序API中英文对照外文翻译文献
- Android毕设外文资料和译文
- 安卓系统与IOS系统比较—英文文献翻译(适用于毕业论文外文翻译+中英文对照)
- Android API级别 安卓论文中英文资料对照外文翻译文献综述
- 安卓系统与IOS系统比较—英文文献翻译外文翻译
- Android系统外文翻译
- 基于Android平台的图书管理系统手机客户端开发(含外文翻译)
- Android中英文对照外文翻译文献